Cómo hacer que el DNS de Windows Server use el archivo de hosts para resolver nombres de host específicos

[NOTA: La solución de esta pregunta es perfecta, por algo alejado de lo que indica el título.]

Estoy enfrentando un pequeño problema con Windows Server 2003 DNS service. En mi empresa, estoy ejecutando el servidor DNS de Microsoft ( 172.16.0.12) para hacer la resolución de nombres en la intranet de mi empresa (el nombre de dominio termina en la dev.nlsresolución IP 172.16 .. ), Y también está configurado como un reenviador de DNS para reenviar otros nombres de dominio ( por ejemplo, * .google.com, * .sf.net) a Internet real DNS servers. Este servidor DNS interno nunca tiende a servir a usuarios del mundo exterior.

Y, estamos ejecutando un servidor de correo (que sirve el correo entrante para un dominio real de Internet @nlscan.com) dentro del firewall de la compañía al que se puede acceder de cualquier manera:

1. conectando 172.16.0.10desde dentro de la intranet.
2. conectándose mail.nlscan.com(resuelto a 202.101.116.9) desde Internet.

Tenga en cuenta que 172.16.0.10y 202.101.116.9no es la misma máquina física. El 202uno es una máquina de servidor de seguridad que hacen el reenvío de puertos del puerto 25y 110de la dirección de Intranet 172.16.0.10.

Ahora mi pregunta: si los usuarios dentro de la LAN corporativa quieren resolver mail.nlscan.com, lo resuelve 202.101.116.9. Eso es correcto y factible, PERO NO BUENO, porque el tráfico de correo va a la máquina del firewall y luego rebota 172.16.0.10. Espero que internal DNS serverpodamos interceptar el nombre mail.nlscan.comy resolverlo en 172.16.0.10. Entonces, espero poder escribir una entrada en el archivo "hosts" 172.16.0.12para hacer esto. Pero, ¿cómo puede Microsoft DNS serverreconocer este archivo "hosts"?

Quizás sugiera, ¿por qué no usar el usuario de la intranet 172.16.0.10para acceder a mi servidor de correo? Debo decir que es inconveniente, supongamos que un usuario (empleado) trabaja en su computadora portátil, durante el día en la oficina y durante la noche en casa. Cuando está en casa, no puede usar 172.16.0.10.

No es posible crear una zona para nlscan.comnuestro interno DNS server, porque el servidor de nlscan.comnombres para el dominio está en nuestro ISP, y es responsable de resolver otros nombres de host y subdominios en nlscan.com.

[EDITAR]

Como WesleyDavidsugerí, sigo la solución de simplemente crear una zona con nombre mailserver.nlscan.comy colocar un registro A sin nombre en esa zona . El tiempo prueba que esto funciona bien.

La última parte de esta publicación está mal. Tenía la impresión, en base a algunas cosas que había leído en la web (si está en la web, ¡debe ser cierto!) De que parte de las tareas del Servicio de Servidor DNS de Windows para crear su caché era cargar también su archivo host en caché junto con sus datos de zona local. Busqué alrededor y no pude encontrar pruebas contundentes de esto. Probé la teoría en mi propia máquina Server 2008 R2 y descubrí que el archivo de hosts no se usaba para construir la caché del servidor DNS.

Sin embargo, creo que tengo una solución un poco más elegante que Massimo. En lugar de crear una zona autorizada para toda la zona nlscan.com, simplemente cree una zona llamada mailserver.nlscan.com y coloque un registro A sin nombre en esa zona. El registro A sin nombre tendrá el mismo nombre que la zona en sí y puede darle la dirección IP que desee. Todos los demás dominios debajo de nlscan.com, así como nlscan.com, se resolverán mediante DNS público.

Acabo de probar esto en mi propio servidor DNS Server 2008 R2 y pude resolver el sitio web de mi amigo (nessus.nl) a través de servidores DNS públicos, pero el subdominio específico (blog.nessus.nl) se resolvió en una dirección IP de Apple.com . Inténtalo, y ve si funciona para ti.

La publicación anterior más incorrecta comienza:

Si mi comprensión es correcta (EDITAR: y no lo es), cuando el caché de DNS se construye en la máquina Server 2003, extrae entradas del archivo de hosts, así como sus datos de zona. Colocar 172.16.0.10 mailserver.nlscan.comen el archivo hosts de su máquina Server 2003 debería resolver el problema. Reinicie sus servicios DNS después de cambiar su archivo de hosts.

Use ipconfig / displaydns en cualquier máquina con Windows (específicamente, su máquina DNS Server 2003) para ver las entradas de su archivo host. También tenga en cuenta que las respuestas negativas se almacenan en caché en sus clientes, por lo que siempre ejecute ipconfig / flushdns en los clientes con los que está experimentando. De lo contrario, terminarás abusando de varios objetos duros mientras te preguntas por qué tus clientes no pueden resolver un nombre que acabas de ingresar en un archivo de zona / host. =)

¿Has probado esto y has fallado?

El deseo de que los usuarios internos obtengan IP internas para los recursos, mientras que los usuarios externos obtienen IP externas para esos mismos recursos es común. Se conoce como DNS de cerebro dividido. Tiene un servidor DNS que mira a Internet y otro servidor DNS interno para usuarios locales. Los usuarios internos usan DHCP en su red y en su servidor DHCP anuncian el servidor DNS interno. Cuando sus usuarios están fuera de la oficina, su servidor DHCP los asignará a un servidor DNS que solo conocerá la zona externa.

Parece que quiere un DNS de cerebro dividido sin alojar realmente la zona internamente. Sugiere que alojar la zona internamente es problemático porque no desea que los usuarios obtengan la IP interna cuando trabajan desde su casa, pero eso no tiene sentido porque cuando están en casa obtienen su IP de un servidor DHCP diferente eso no va a anunciar su servidor DNS interno. Va a anunciar el servidor DNS de su ISP, que solo sabrá acerca de su zona externa y, por lo tanto, solo les proporcionará direcciones IP externas.

Finalmente, no creo que tenga éxito al pedirle a un servidor DNS que sirva registros del archivo de hosts en el servidor DNS. Un servidor DNS sirve registros de sus archivos de zona. El archivo de hosts locales en ese servidor DNS propaga entradas en la caché de resolución del cliente local, que es aplicable solo a las búsquedas en esa máquina. Esas entradas no son atendidas por el servidor DNS, que es un mecanismo diferente.

Lea sobre el DNS de cerebro dividido: es la forma normal de manejar esta situación.

Wes: No estoy seguro de quién lo criticó, pero me gustaría aclarar el uso del archivo de hosts: el componente de resolución del cliente DNS, no el componente del servidor DNS, utiliza el archivo de hosts. El servidor DNS utilizará una entrada en el archivo hosts en un servidor DNS cuando actúe como cliente DNS. Por ejemplo, una entrada en el archivo de hosts de mi servidor DNS W2K8 como esta:

1.1.1.1 test.test.com

se carga en el caché del cliente DNS del servidor DNS (no es el caché del servidor). Si hago ping a test.test.com desde mi servidor DNS, devuelve 1.1.1.1 como se esperaba. Si luego ejecuto nslookup en el servidor DNS y le solicito test.test.com, devuelve la dirección IP pública correcta registrada para test.test.com ya que el componente del cliente DNS en el servidor DNS ahora está pidiendo resolución al componente del servidor DNS (tal como lo haría cualquier otro cliente DNS). Es una idea confusa, pero el servidor DNS también es un cliente DNS y cuando se activa el componente del cliente DNS, actúa como cualquier otro cliente DNS al mirar su propio caché de cliente DNS, incluidas las entradas previas. -cargado desde el archivo de hosts. Solo cuando el componente del cliente DNS utiliza el componente del servidor DNS (al consultar los servidores DNS configurados en él '

Cualquier cliente DNS que consulte al servidor DNS siempre obtendrá la respuesta "real" y no la entrada de los hosts porque el servidor DNS (como cliente DNS) utiliza el caché del cliente DNS del servidor DNS y no el componente del servidor DNS.

Hasta donde yo sé, no hay forma de hacer que Windows DNS use el hostsarchivo para manejar la resolución de nombres; Pero esto no es necesario.

Puede crear de forma segura una zona en su servidor DNS interno con el mismo nombre que una zona de Internet pública; lo que sucederá es que su servidor manejará las solicitudes de nombres en esa zona utilizando sus propios datos, en lugar de reenviar esas solicitudes a los servidores de nombres autorizados para esa zona; esto a veces se llama "sombreado", porque hace que la zona pública "real" no esté disponible para el cliente interno, respondiendo en su lugar con datos "falsos".

Lo que debe tener cuidado es que debe llenar esta zona interna con todos los nombres que necesitará, incluso utilizando direcciones IP públicas cuando sea necesario; de lo contrario, los clientes internos no podrán resolver esos nombres.

Digamos que su zona pública se ve así:

www.nlscan.com    202.101.116.8
mail.nlscan.com   202.101.116.9

Desea que los clientes internos resuelvan mail.nlscan.com como 172.16.0.10; está bien, así que crea una zona "nlscan.com" en su servidor DNS interno y coloca "mail.nlscan.com -> 172.16.0.10" en ella.
Pero ahora sus clientes internos no pueden resolver "www.nlscan.com", porque el servidor cree que tiene autoridad para esa zona, por lo que no responderá la consulta (porque no conoce ese host), pero también no se lo reenviará a nadie.
Para resolver esto, debe poner "www.nlscan.com" también dentro de su zona interna; puede apuntar a su dirección IP pública real si desea que sus clientes accedan a ella de esa manera, o puede utilizar la misma redirección que está utilizando para "mail.nlscan.com", si "www" su firewall también lo reenvía a algún servidor interno.
El mismo principio se aplica a cualquier nombre en la zona.

Esta configuración no tendrá ningún impacto en los clientes externos, ni en ninguno de sus usuarios que esté temporalmente fuera de su red, porque esa zona de "sombra" interna nunca será visible desde Internet.

No importa el archivo host, solo agregue una nueva zona en el DNS mail.domain.com y agregue un host en la zona. deje el nombre en blanco (usará automáticamente el nombre de la zona) e ingrese la dirección IP del servidor de correo local ;-)