Solución 1:
Usa la fuente, Mike.
El resolutor utiliza una búsqueda lineal a través del archivo de texto para localizar las entradas. Es una base de datos sin índices. Por lo tanto, en ausencia de capacidad de almacenamiento en caché adicional, el costo de las búsquedas será O(n). En cuanto a cuándo eso dará como resultado una degradación en el rendimiento, esa es una pregunta imposible de responder:se vuelve más lento con cada registro.
Si habla con un programador o administrador de base de datos, obtendrá diferentes cifras para el punto en el que una búsqueda de índice (O (log2 (n)) es más barata que una exploración de tabla completa, pero generalmente la respuesta estará en la región de 20 a 100 registros.
Cualquier sistema Linux que necesite resolver muchos nombres (no solo nombres de host). Debería estar ejecutando nscd o similar. La mayoría de estos cachés indexarán los datos, lo que anularía la pregunta de rendimiento, sin embargo...
No proporciona ningún medio para administrar conjuntos de datos complejos/grandes:si tiene un host con más de una dirección IP, las búsquedas a través del archivo de hosts siempre devolverán la primera entrada.
Solución 2:
Un poco de historia de Internet:antes de que se implementara el DNS en 1984, el archivo de hosts era el único para resolver nombres, y no había muchos hosts en la red:325 en febrero de 1983 (RFC 847). Hay copias de HOSTS.TXT (aunque no legibles por máquina) de 1982 en el archivo de la lista de correo del historial de Internet. Incluso había un HOSTS.TXT alternativo (de Geoff Goodfellow).
Solución 3:
Técnicamente, no hay límite superior. Sin embargo, todas las búsquedas de DNS encontrarán este archivo, entonces, ¿por qué dejarse abierto a eso?
Por lo que vale, el /etc/hosts más grande archivo que he distribuido en mis entornos era de 1.200 líneas. Y eso funcionó bien para la aplicación que estaba administrando. El DNS no era una opción en ese entorno en particular.