Los profesionales de seguridad durante décadas han aconsejado a las personas que limiten las consultas de DNS en sus servidores DNS para que solo usen el puerto UDP 53. La realidad es que las consultas DNS también pueden usar el puerto TCP 53 si no se acepta el puerto UDP 53. Ahora, con el inminente despliegue de DNSSEC y la eventual adición de IPv6, necesitaremos permitir que nuestros firewalls reenvíen paquetes TCP y UDP de puerto 53.

DNS puede ser utilizado por los atacantes como una de sus técnicas de reconocimiento., La información pública contenida en los servidores de un objetivo es valiosa para un atacante y le ayuda a enfocar sus ataques. Los atacantes pueden utilizar una variedad de técnicas para recuperar información de DNS a través de consultas. Sin embargo, los hackers a menudo intentan realizar una transferencia de zona desde sus servidores DNS autorizados para obtener acceso a aún más información. Puede usar el comando dig para recopilar información de un servidor para un archivo de zona específico.,

dig @192.168.11.24 example.org -t AXFR

Las transferencias de zona se realizan a través del puerto TCP 53 y, para evitar que nuestros servidores DNS divulguen información crítica a los atacantes, el puerto TCP 53 suele estar bloqueado. Si el firewall de la organización que protege el servidor DNS autoritativo permite los paquetes del puerto TCP 53 y el servidor DNS está configurado para permitir transferencias de zona a cualquier persona, este comando dig se ejecutará correctamente. Sin embargo, la mayoría de las organizaciones han configurado sus servidores DNS para evitar transferencias de zona de servidores DNS no deseados., Esto se puede configurar en el archivo BIND zone usando cualquiera de estas formas del comando allow-transfer como se muestra a continuación.

allow-transfer {"none";}; allow-transfer { address_match_list }; allow-transfer {192.168.11.11;};

Además, la mayoría de las organizaciones también han utilizado firewalls para bloquear el puerto TCP 53 hacia y desde sus servidores DNS e Internet. Esta es una doble protección en caso de que el servidor DNS permita accidentalmente transferencias.

configurar sus servidores DNS para permitir transferencias de zona solo a servidores DNS legítimos siempre ha sido y sigue siendo una práctica recomendada., Sin embargo, la práctica de negar el puerto TCP 53 hacia y desde los servidores DNS está empezando a causar algunos problemas. Hay dos buenas razones por las que nos gustaría permitir conexiones de puerto TCP y UDP 53 a nuestros servidores DNS. Uno es DNSSEC y el segundo es IPv6.

DNSSEC crea respuestas DNS más grandes

Me encanta leer el IP Journal y lo he leído desde el primer número en 1998.

en la reciente edición del IP Journal había un artículo de un amigo mío, Stephan Lagerholm, de Secure64 y el grupo de trabajo IPv6 de Texas, titulado «desafíos operativos al implementar DNSSEC»., Este artículo cubrió muchas de las advertencias que las organizaciones encuentran a medida que se mueven para implementar DNSSEC.

una de las cuestiones clave mencionadas es que DNSSEC puede hacer que las respuestas DNS sean mayores de 512 bytes. DNSSEC (definido en RFC 4033, RFC 4034 y RFC 4035) requiere la capacidad de transmitir mensajes DNS más grandes debido a la información clave adicional contenida en las respuestas de consulta. El puerto TCP 53 se puede usar en los casos en que el DNS responda más de 512 bytes., Sin embargo, el uso de mensajes UDP es preferible al uso de TCP para mensajes DNS grandes debido al hecho de que las conexiones TCP pueden consumir recursos informáticos para cada conexión. Los servidores DNS obtienen numerosas conexiones por segundo y el uso de TCP puede agregar demasiada sobrecarga. Para abordar este problema, el IETF RFC 2671 «Extension Mechanisms for DNS (EDNS0)» define un método para extender el tamaño del búfer UDP a 4096 bytes para permitir DNSSEC y respuestas de consulta más grandes., Para habilitar EDNS0 en su configuración BIND 9 puede usar la siguiente declaración de operaciones BIND

edns-udp-size 4096 ;

el conocimiento de DNSSEC ha aumentado debido a las vulnerabilidades reveladas hace 2 años y con noticias recientes sobre el Gobierno de EE. Muchas organizaciones han estado planeando sus implementaciones de DNSSEC. DNSSEC se está implementando más ampliamente ahora que se están firmando dominios clave de Nivel Superior (TLDs). El TLD. org ya ha sido firmado. La zona raíz de Internet se firmó hace solo 2 meses en una ceremonia en Virginia., VeriSign ha declarado su deseo de apoyar DNSSEC para. com y. Net para 2011. Comcast ha creado un sitio del centro de información DNSSEC que puede ayudarlo a mantenerse al día sobre el estado más reciente de DNSSEC.