¿Por qué querría ejecutar servidores DNS externamente?

6

Algo que nunca tuvo mucho sentido para mí es cuando los entornos tienen servidores de DNS a los que se puede acceder públicamente (en Internet). Esto parece más a menudo que no los deja vulnerables a los ataques Cache Poisoning / Snooping / Amplified DoS.

Los únicos tipos de clientes que se me ocurren que usan servidores DNS externos por cualquier buena razón serían los ISP y similares. ¿Cuál es el razonamiento detrás de querer exponer su servidor DNS públicamente?

Saludos,

    
pregunta NULLZ 27.02.2013 - 01:05
fuente

3 respuestas

5

Cuando se habla de servidores DNS, es importante distinguir entre resolutores recursivos (aquellos servidores que brindan a los clientes servicios de resolución de nombres) y servidores de nombres autorizados (aquellos servidores que responden las consultas finales de los archivos de la zona local).

Si está hablando de resolutores recursivos (servidores de almacenamiento en caché de DNS), entonces, por supuesto, si una organización tiene una intranet, los resolutores recursivos deben estar allí, no en Internet. Y si la organización no tiene una Intranet segregada o una red interna, los solucionadores recursivos que permiten consultas de un conjunto restringido de fuentes son sin duda una buena idea. Como usted dice, un ISP puede tener un caso para una resolución de problemas abierta, en parte porque no se espera que las consultas de nombres no públicos sean manejadas por dicho servidor, en parte debido a la dificultad de enumerar grandes cantidades de direcciones IP permitidas , y en parte por razones históricas (es la forma en que siempre se hizo en el pasado).

Si está hablando de servidores de nombres autorizados, entonces una buena razón para tener esos servidores en Internet es el excelente tiempo de respuesta. Cada cliente que quiera acceder a su sitio web, su servidor de correo electrónico, su servidor SIP o cualquier otra cosa que se le ocurra ofrecer por su nombre bajo su nombre de dominio, tarde o temprano generará una consulta en contra de su servidor de nombres autorizado (excepto si la respuesta ya ha sido almacenada en caché). El tiempo de respuesta de este servidor afectará el tiempo de respuesta de cada servicio que ofrezca. Desea que la consulta vaya a un servidor receptivo en un centro de alojamiento bien conectado, si es posible. Si no tiene servidores propios en esos lugares, probablemente sea una buena idea subcontratar el servicio de nombres autorizado a un proveedor de DNS. En estos días, casi todos los registradores de dominios también ofrecen servicios de nombres autorizados si lo desean. Exagero un poco la importancia de un servidor de nombres autoritario muy sensible, pero recibes el mensaje.

Aún sobre el tema de los servidores de nombres autorizados, debo señalar que al menos una de las amenazas que menciona, el envenenamiento de la memoria caché, no es aplicable: un servidor de nombres autorizado está configurado para no responder a las consultas de la memoria caché. En cuanto a los ataques de amplificación (cuando los paquetes falsificados se envían con una pregunta, la respuesta es mayor que la pregunta y esta respuesta se dirige a una víctima), la ubicación del servidor de nombres (detrás de un servidor de seguridad o no) no se realizará. una diferencia. Hasta cierto punto, el servidor de nombres tiene que responder a esas consultas sin importar qué, de lo contrario, los clientes no encontrarán los servicios bajo su dominio.

Una configuración común para organizaciones con intranets es DNS dividido: hay dos conjuntos de servidores DNS autorizados. Un juego tiene la versión pública de la zona y pertenece a Internet. El otro conjunto tiene la versión interna (que probablemente tiene un superconjunto de los contenidos de la versión pública) y pertenece a la intranet. Este caso es bastante simple. Los servidores públicos autorizados no pueden filtrar accidentalmente ninguna información de DNS privada porque no tienen una copia del archivo de zona interna y no pueden obtener una, ya que están en Internet. (Obviamente, esto supone que el proceso de implementación del archivo de zona no enviará un archivo de zona sin autorización a la versión pública del servidor durante una actualización).

    
respondido por el Celada 27.02.2013 - 01:56
fuente
2

Si tiene direcciones IP de acceso público en su red interna y desea que las personas de la red pública puedan acceder a esos recursos, necesitan acceso a su servidor DNS. Obviamente, la mayoría de las cosas deben estar en la zona DMZ, pero puede haber una conexión de socio o extranet dentro de la red que se permita a través de un firewall a una red interna aislada. Sería una cuestión de querer que la información sea pública; También es posible que sea una mala configuración.

    
respondido por el Eric G 27.02.2013 - 02:28
fuente
0

Además de la respuesta de Celada, los servidores de correo electrónico que utilizan DNS para realizar operaciones AntiSpam (SPF, etc.) no deben usar el mismo conjunto de servidores que utiliza el sistema de resolución recursivo interno.

Muchas personas que utilizan el correo electrónico externo, como Postini, Microsoft Office 365, PoD alojado en Proofpoint, etc. están aisladas debido a la externalización.

Si aloja un correo electrónico interno, debe considerar los relés SMTP de punta (cualquier cosa que haga una verificación de SPF o DKIM) a cualquier servidor DNS que no sea el resolutor recursivo interno.

    
respondido por el random65537 27.02.2013 - 05:45
fuente

Lea otras preguntas en las etiquetas