Soluzione 1:
Usa la fonte, Mike.
Il resolver utilizza una ricerca lineare attraverso il file di testo per individuare le voci. È un database senza indici. Pertanto, in assenza di capacità di memorizzazione nella cache aggiuntive, il costo per le ricerche sarà O(n). Riguardo a quando ciò comporterà un degrado delle prestazioni, questa è una domanda a cui è impossibile rispondere:diventa più lento con ogni record.
Se parli con un programmatore di database o un amministratore otterrai cifre diverse per il punto in cui una ricerca dell'indice (O(log2(n)) è più economica di una scansione completa della tabella, ma generalmente la risposta sarà nella regione di 20 a 100 record.
Qualsiasi sistema Linux che necessita di risolvere molti nomi (non solo nomi host). Dovrebbe essere in esecuzione nscd o simile. La maggior parte di tali cache indicizzerà i dati stessi, il che annullerebbe la domanda sulle prestazioni, tuttavia...
Non fornisce mezzi per la gestione di set di dati complessi/di grandi dimensioni:se si dispone di un host con più di un indirizzo IP, le ricerche tramite il file hosts restituiranno sempre la prima voce.
Soluzione 2:
Un po' di storia di Internet -- prima che il DNS venisse implementato nel 1984, il file hosts era l'unico per risolvere i nomi, e non c'erano molti host sulla rete -- 325 nel febbraio 1983 (RFC 847). Ci sono copie di HOSTS.TXT (non leggibili dalla macchina, però) dal 1982 nell'archivio della maillist della storia di Internet. C'era anche un HOSTS.TXT alternativo (di Geoff Goodfellow).
Soluzione 3:
Tecnicamente, non esiste un limite superiore. Tuttavia, ogni ricerca DNS raggiungerà questo file, quindi perché lasciarti aperto?
Per quello che vale, il più grande /etc/hosts file che ho distribuito nei miei ambienti era di 1.200 righe. E questo ha funzionato bene per l'applicazione che stavo gestendo. Il DNS non era un'opzione in quel particolare ambiente.