Solusi 1:
Gunakan sumbernya, Mike.
Resolver menggunakan pencarian linier melalui file teks untuk menemukan entri. Ini adalah database tanpa indeks. Jadi, dengan tidak adanya kemampuan caching tambahan, biaya pencarian akan menjadi O(n). Mengenai kapan hal itu akan mengakibatkan penurunan kinerja, itu adalah pertanyaan yang mustahil untuk dijawab - semakin lambat di setiap rekaman.
Jika Anda berbicara dengan programmer atau admin database, Anda akan mendapatkan angka yang berbeda untuk titik di mana pencarian indeks (O(log2(n)) lebih murah daripada pemindaian tabel lengkap, tetapi umumnya jawabannya berada di wilayah 20 hingga 100 rekaman.
Sistem linux apa pun yang perlu menyelesaikan banyak nama (bukan hanya nama host). Harus menjalankan nscd atau serupa. Sebagian besar cache tersebut akan mengindeks datanya sendiri yang akan meniadakan pertanyaan kinerja, namun...
Ini tidak menyediakan cara untuk mengelola kumpulan data yang kompleks/besar - jika Anda memiliki host dengan lebih dari satu alamat IP, pencarian melalui file host akan selalu menampilkan entri pertama.
Solusi 2:
Sedikit riwayat Internet -- sebelum DNS digunakan pada tahun 1984, file host adalah satu-satunya untuk menyelesaikan nama, dan tidak banyak host di jaringan -- 325 pada Februari 1983 (RFC 847). Ada salinan HOSTS.TXT (meskipun tidak dapat dibaca mesin) dari tahun 1982 di arsip daftar surat riwayat internet. Bahkan ada HOSTS.TXT alternatif (Geoff Goodfellow's).
Solusi 3:
Secara teknis, tidak ada batas atas. Namun, setiap pencarian DNS akan menemukan file ini, jadi mengapa membiarkan diri Anda terbuka untuk itu?
Untuk apa nilainya, /etc/hosts terbesar file yang saya distribusikan di lingkungan saya adalah 1.200 baris. Dan itu bekerja dengan baik untuk aplikasi yang saya kelola. DNS bukanlah pilihan di lingkungan tertentu itu.