Bosque de Active Directory con el mismo nombre que la zona DNS raíz y navegando al sitio con el mismo nombre

Relacionado con esta pregunta mía anterior sobre por qué es una mala idea usar el nombre de dominio raíz como el nombre del bosque de Active Directory ...

Tengo un empleador, a quien me referiré como ITcluelessinc, para fines de simplicidad (y honestidad). Este empleador tiene un sitio web alojado externamente, www.ITcluelessinc.com , y algunos dominios de Active Directory. Al no tener idea acerca de TI, hace muchos años, se instalaron en un bosque de Active Directory llamado ITcluelessinc.prvy realizaron atrocidades indescriptibles contra él. Estas atrocidades indescriptibles finalmente los alcanzaron, y con todo colapsando a su alrededor, decidieron pagarle a alguien una gran cantidad de dinero para "arreglarlo", que incluía emigrar del ITcluelessinc.prvbosque horriblemente roto .

Y, por supuesto, al no tener idea sobre TI, no sabían buenos consejos cuando lo escucharon, aceptaron la recomendación de nombrar su nuevo bosque de AD ITcluelessinc.com, en lugar del consejo sensato que también recibieron, y comenzaron a ponerle cosas. Avancemos rápidamente hasta hace unas horas, y tenemos una compañía con la mayoría de sus cosas unidas y usando el antiguo ITcluelessinc.prvbosque de Active Directory, con una buena cantidad de cosas nuevas unidas y / o usando el ITcluelessinc.combosque. Para que esto funcione de manera relativamente fluida, he usado reenviadores condicionales en DNS para enviar el ITcluelessinc.comtráfico ITcluelessinc.prvy viceversa.

ingrese la descripción de la imagen aquí

(Los dominios corp.ITcluelessinc.comy eval.ITcluelessinc.comse denominan correctamente dominios en los que ingresé y configuré más tarde, y aún no son relevantes).

Hace unas horas, y un empleado no técnico de ITcluelessinc se dio cuenta de que no puede navegar hasta www.ITcluelessinc.com desde su estación de trabajo (dentro de la red corporativa de ITcluelessinc) y decidió que esto es un problema, por lo que se pone en contacto Empleado VIP de ITcluelessinc, quien decide que esto debe resolverse con la mayor parte de Ricky-tick. Por lo general, no es un gran problema, agregue un registro A wwwen la zona DNS para ITcluelessinc.com, y puede navegar por el sitio, siempre que no intente el enlace desnudo.

ingrese la descripción de la imagen aquí

Entonces, parece que todo está configurado correctamente. Los reenviadores, la wwwentrada de host en DNS y, sin embargo, los clientes que usan el ITcluelessinc.prvcontrolador de dominio como servidores DNS obtienen un tiempo de espera de conexión cuando intentan navegar a www.ITcluelessinc.com , en lugar de la página web que obtengo de mi red doméstica.

¿Alguien tiene alguna idea sobre cómo puedo permitir que los clientes internos del ITcluelessinc.prvdominio naveguen en www.ITcluelessinc.com , dada la presencia del ITcluelessinc.combosque de Active Directory y los reenviadores condicionales que necesita? O, alternativamente, ¿alguien [más] está convencido de que la única forma de hacerlo funcionar es deshacerse del ITcluelessinc.combosque de Active Directory?

No hace parecer como la configuración que tengo ahora debe trabajar, pero no es clara, y no tengo ni idea de dónde me procurar un entorno de pruebas esta en mal estado a experimentar. Y para lo que vale, he sugerido cortésmente que la única forma de solucionar esto es migrar a los bosques con el nombre apropiado que configuré, y cuando esa no sea una respuesta lo suficientemente buena, planee alojar un espejo del sitio web en todos nuestros ITcluelessinc.comcontroladores de dominio hasta que eso lo rompa todo .

domain-name-system active-directory

— HopelessN00b
fuente

Eso debería funcionar: refleja la configuración que tenía en un trabajo anterior (un dominio tan malo para usar en su bosque, tiene mi simpatía), menos los dos espacios de nombres y reenviadores. ¿Están los sistemas cliente recibiendo una respuesta DNS de NXDomain tratando de resolver el wwwnombre, o están obteniendo una dirección incorrecta? O, alternativamente, ¿están obteniendo la dirección correcta pero no pueden conectarse a esa dirección (el sitio web está alojado en servidores dentro de la red, lo que causa un problema de horquilla NAT)?

— Shane Madden

@ShaneMadden: Mis pensamientos exactamente y discutidos en una conversación privada. Debería funcionar, pero no funciona, y no tengo idea de por qué no. Lo único que sugeriría en este momento sería iniciar una captura de paquetes en un cliente .prv y ver qué sucede cuando intentan buscar www.

— joeqwerty

@ShaneMadden Parece que obtienen la dirección correcta con un nslookup, y no debería haber ninguna horquilla NAT involucrada, ya que el sitio web está alojado externamente. (Cliente -> .prv DC -> .com DC -> firewall -> interwebs). He visto este trabajo antes cuando las máquinas en el dominio rootdnsname intentaban acceder al nombre rootdnsname, pero aún no han visto clientes unidos a un dominio diferente que necesiten acceder al sitio web rootdnsname y rootdnsname. ... Así que eso es lo que creo que debe ser el problema.

— HopelessN00b

Estoy de acuerdo con Evan. Relacionado a la mitad, y después de haber trabajado para otra compañía que se ha involucrado en tonterías de cerebro dividido, un truco que vale la pena mencionar es que puede hacer que sus servidores DNS públicos controlen un registro (o subdominio) insertando NSregistros. Siempre que el cortafuegos permita la comunicación de los DC al servidor DNS externo, esto alivia un poco la pesadilla y los registros públicos se pueden administrar en el servidor público.

— Andrew B

@AndrewB Historia real, ITcluelessinc ha externalizado su DNS a un proveedor externo, pero no sabe cuál, y no puede resolverlo, por lo tanto, no hay trucos NS en los servidores de nombres externos. Pero lo tendré en cuenta por $ next_job, gracias.

— HopelessN00b

Si los clientes están resolviendo el nombre de host correctamente, entonces tienes otro problema. DNS está fuera de la imagen una vez que el cliente resuelve el nombre de host.

Algunas cosas para pensar:

¿Los clientes utilizan algún tipo de proxy HTTP para acceder a Internet? ¿El proxy tiene la información de DNS correcta disponible?
¿Cómo se ve el caché DNS en el cliente después de un intento de acceso fallido? ¿Está viendo la dirección IP correcta en caché para el nombre de host?
¿Qué está pasando realmente en el cliente? ¿Ves una conexión atascada en el estado SYN_SENT a la dirección IP correcta del servidor, el puerto TCP 80?
¿Hay alguna regla de firewall que pueda estar relacionada con el bloqueo de acceso a la dirección del sitio web?

Esto huele a un problema de firewall / proxy / caché / filtro, no un problema de DNS.

Desafortunadamente, no hay nada realmente convincente que pueda decir sobre deshacerse del mal llamado dominio de Active Directory. Es lamentable que hayan elegido hacer esa ruta, pero técnicamente esto puede funcionar. (Odio este tipo de mala práctica de nombres, también ... "vil", creo, es como me he referido a él en el pasado ... Ojalá tuviera un buen consejo para enviarle un argumento de cambio de nombre de dominio ...)

— Evan Anderson
fuente

If the clients are resolving the hostname properly then you've got another problem. Maldición Si ese es el caso, probablemente sea nuestro astuto webproxy. Me sentí mucho más feliz cuando pensé que podría no ser técnicamente solucionable, y finalmente tendrían que arreglar su desorden $ # @ ^% ing. :(

— HopelessN00b

Realice la prueba con un servidor o computadora interna que omita cualquier proxy web, etc. y vuelva a realizar la prueba. Como dijeron Evan y Shane, definitivamente es factible con un registro www. Lo que no es factible es solo un registro predeterminado como itcluessinc.com que se resuelve en el sitio web en este caso.

— TheCleaner

Sí, ¿adivina qué sucede cuando TI no administra los sitios web y el departamento que decide cambiar las empresas de alojamiento? Así es, el viejo wwwregistro A no funciona, el administrador de sistemas se enoja y agrava su cirrosis.

— HopelessN00b