Nombrar un nuevo bosque de Active Directory: ¿por qué no se recomienda DNS de horizonte dividido?

Con suerte , todos sabemos cuáles son las recomendaciones para nombrar un bosque de Active Directory , y son bastante simples. Es decir, se puede resumir en una sola oración.

Use un subdominio de un nombre de dominio registrado existente y elija uno que no se vaya a usar externamente. Por ejemplo, si tuviera que incorporar y registrar el hopelessn00b.comdominio, mi bosque AD interno debería llamarse internal.hopelessn00b.comor ad.hopelessn00b.como corp.hopelessn00b.com.

Hay razones abrumadoramente convincentes para evitar el uso de dominios de primer nivel "falsos" o nombres de dominio de etiqueta única , pero estoy teniendo un tiempo difícil encontrar razones convincentes de manera similar a evitar el uso del dominio raíz ( hopelessn00b.com) ya que mi nombre de dominio y utilizar un subdominio como corp.hopelessn00b.comlugar . Realmente, la única justificación que puedo encontrar es que el acceso al sitio web externo desde el interno requiere un A nameregistro DNS y escribir www.frente al nombre del sitio web en un navegador, que es bastante "meh" en lo que respecta a los problemas.

Entonces, ¿qué me estoy perdiendo? ¿Por qué es mucho mejor usar ad.hopelessn00b.comcomo mi nombre de bosque de Active Directory hopelessn00b.com?

Solo para que conste, es realmente mi empleador el que necesita convencerse: el hombre jefe está vendiendo atrasados, y después de darme el visto bueno para crear un nuevo bosque de AD llamado corp.hopelessn00b'semployer.compara nuestra red interna, quiere quedarse con un bosque de AD llamado hopelessn00b'semployer.com( lo mismo que nuestro dominio registrado externamente). Espero poder obtener alguna razón convincente o razones por las que la mejor práctica es la mejor opción, así puedo convencerlo de eso ... porque parece más fácil que la ira dejar de fumar y / o encontrar un nuevo trabajo, al menos para el momento. En este momento, "las mejores prácticas de Microsoft" y el acceso interno al sitio web público de nuestra empresa no parecen estar reduciéndolo, y realmente , realmente , realmente espero que alguien aquí tenga algo más convincente.

Tanta reputación para tener. Ven a mí preciosa.

De acuerdo, Microsoft ha documentado bastante bien que no debes usar un horizonte dividido o un TLD inventado como lo has vinculado muchas veces (¡grita en mi blog!). Hay algunas razones para esto.

1. El wwwproblema que has señalado anteriormente. Molesto, pero no es un factor decisivo.

2. Te obliga a mantener registros duplicados para todos los servidores públicos que también son accesibles internamente, no solo www. mail.hopelessnoob.comEs un ejemplo común. En un escenario ideal, tendría una red perimetral separada para cosas como mail.hopelessnoob.como publicwebservice.hopelessnoob.com. Con algunas configuraciones, como un ASA con interfaces internas y externas , de todos modos necesita un NAT interno o un DNS de horizonte dividido, pero para las organizaciones más grandes con una red perimetral legítima donde sus recursos orientados a la web no están detrás de un límite de NAT. Esto provoca trabajo innecesario.

3. Imagina este escenario: eres hopelessnoob.cominterna y externamente. Tiene una corporación con la que se está asociando example.comy hace lo mismo: dividir el horizonte internamente con su AD y con su espacio de nombres DNS de acceso público. Ahora, configura una VPN de sitio a sitio y desea autenticación interna para que la confianza atraviese el túnel mientras tiene acceso a sus recursos públicos externos para salir a través de Internet. Es casi imposible sin un enrutamiento de políticas increíblemente complicado o tener su propia copia de su zona DNS interna: ahora acaba de crear un conjunto adicional de registros DNS para mantener. Entonces tienes que lidiar con la horquilla al final ysu fin, política de enrutamiento / NAT, y todo tipo de otros trucos. (En realidad estaba en esta situación con un AD que heredé).

4. Si alguna vez implementa DirectAccess , simplifica drásticamente sus políticas de resolución de nombres; esto probablemente también sea cierto para otras tecnologías VPN de túnel dividido.

Algunos de estos son casos extremos, otros no, pero todos se evitan fácilmente . Si tiene la capacidad de hacer esto desde el principio, bien podría hacerlo de la manera correcta para que no se encuentre con uno de estos en una década.

Esta afirmación: "Realmente, la única justificación que puedo encontrar es que acceder al sitio web externo desde el interno requiere un registro DNS SRV y escribir www. Delante del nombre del sitio web en un navegador" no es cierto.

Significa que necesita mantener una copia de todos sus registros públicos en sus servidores DNS de AD, lo que podría causar problemas, especialmente si no lo hace correctamente, omita algunos, etc. Si alguien quiere llegar a ftp.company. com pero se olvida de crear el alias en el DNS interno (o no lo automatizó correctamente), la gente interna no puede acceder al sitio FTP público en absoluto.

Esto está bastante bien desarrollado en la pregunta a la que se vinculó: ¿ Mejores prácticas de nomenclatura de Windows Active Directory?

Si mantener múltiples copias de sus zonas DNS es un problema fácil de resolver para siempre, entonces supongo que puede hacer lo que quiera. Hasta que la EM cambie algo que lo rompa. Usted podría simplemente seguir sus recomendaciones.

No me importa lo suficiente el representante para crear una respuesta larga hoy ... así que lo mantendré breve.

Solía ​​estar bien con split-dns y lo implementé varias veces hasta que Evan y Mark me convencieron de lo contrario. Sinceramente, NO es que no se pueda hacer ... se puede, y algunos podrían estar bien con eso (a pesar de los gastos generales y el trabajo realizado para ello).

Hace 2 años surgieron 2 cosas específicas para mí que solidificaron NO usarlo:

1. Como señaló en su pregunta, simplemente no puede permitir que los usuarios internos accedan a su sitio web externo solo con el nombre de dominio. No pregunte por qué eso fue tan importante, pero teníamos usuarios internos que se enfurecerían al escribir solo el nombre de dominio en un navegador sin wwwque aparezca el sitio web real, ya que el registro de dominio corresponde al dominio AD y no es un todo para llegar wwwy NO PUEDE SER internamente.
2. Problemas de Exchange: Exchange AutoDiscover puede no obtener los certificados y generará un error. Esto puede suceder tanto interna como externamente. Esto se hizo aún más evidente cuando comenzamos a tener "Buzones de correo externos del bosque" en nuestra organización de Exchange y no veían el mismo DNS interno que nosotros.

Espero que ayude.