Solution 1 :
Utilisez la source, Mike.
Le résolveur utilise une recherche linéaire dans le fichier texte pour localiser les entrées. C'est une base de données sans index. Ainsi, en l'absence de capacité de mise en cache supplémentaire, le coût des recherches sera O(n). Quant à savoir quand cela entraînera une dégradation des performances, c'est une question à laquelle il est impossible de répondre - cela ralentit à chaque enregistrement.
Si vous parlez à un programmeur ou à un administrateur de base de données, vous obtiendrez des chiffres différents pour le point auquel une recherche d'index (O(log2(n)) est moins chère qu'une analyse complète de la table, mais généralement la réponse sera dans la région de 20 jusqu'à 100 enregistrements.
Tout système Linux ayant besoin de résoudre un grand nombre de noms (pas seulement des noms d'hôte). Devrait exécuter nscd ou similaire. La plupart de ces caches indexeront eux-mêmes les données, ce qui annulerait la question des performances, cependant...
Il ne fournit aucun moyen de gérer des ensembles de données complexes/volumineux - si vous avez un hôte avec plusieurs adresses IP, les recherches via le fichier hosts renverront toujours la première entrée.
Solution 2 :
Un peu d'histoire d'Internet - avant le déploiement de DNS en 1984, le fichier hosts était le seul à résoudre les noms, et il n'y avait pas beaucoup d'hôtes sur le réseau - 325 en février 1983 (RFC 847). Il existe des copies de HOSTS.TXT (non lisibles par machine, cependant) de 1982 dans les archives de la liste de diffusion Internet-history. Il y avait même un HOSTS.TXT alternatif (celui de Geoff Goodfellow).
Solution 3 :
Techniquement, il n'y a pas de limite supérieure. Cependant, chaque recherche DNS va toucher ce fichier, alors pourquoi vous laisser ouvert à cela ?
Pour ce que ça vaut, le plus grand /etc/hosts fichier que j'ai distribué dans mes environnements comptait 1 200 lignes. Et cela a bien fonctionné pour l'application que je gérais. Le DNS n'était pas une option dans cet environnement particulier.