Dominio de nivel superior / sufijo de dominio para red privada?

115

En nuestra oficina, tenemos una red de área local con una configuración de DNS puramente interna, en la que todos los clientes se denominan whatever.lan. También tengo un entorno VMware, y en la red solo para máquinas virtuales, nombro las máquinas virtuales whatever.vm.

Actualmente, esta red para las máquinas virtuales no es accesible desde nuestra red de área local, pero estamos configurando una red de producción para migrar estas máquinas virtuales, a las que se podrá acceder desde la LAN. Como resultado, estamos tratando de establecer una convención para el sufijo de dominio / TLD que aplicamos a los invitados en esta nueva red que estamos configurando, pero no podemos llegar a una buena, dado eso .vm, .localy .lanTodos tienen connotaciones existentes en nuestro entorno.

Entonces, ¿cuál es la mejor práctica en esta situación? ¿Existe una lista de TLD o nombres de dominio en algún lugar que sea seguro de usar para una red puramente interna?

domain-name-system local-area-network hostname best-practices Otón
fuente
2
No uses .local. Especialmente si tienes clientes de Apple.
RainyRat
2
.test se reserva por esta razón: secure.wikimedia.org/wikipedia/en/wiki/.test
CWSpear
1
@CWSpear Esa no es la razón real por la que.test está reservada, aunque lo convierte en un dominio seguro para usar en redes de prueba que no estarán conectadas a Internet.
voretaq7
10
Las mejores prácticas de @Otto dictarán que adquiera un nombre de dominio "real" (bajo un TLD reconocido por ICANN) y cree un subdominio de ese para sus cosas locales (por ejemplo mydomain.com, regístrese , delegue internal.mydomain.comen un NS interno y configure correctamente el DNS de horizonte dividido ( "vistas" en BIND) para que no filtre nombres / direcciones internas a Internet. No es tan bonito como un TLD / pseudo-TLD, pero es menos propenso a romperse ya que está bajo su control.
voretaq7
99
Sin embargo : no use un nombre de dominio real que ya haya usado para servicios de producción públicos. Hay varias interacciones que están permitidas entre www.example.comy *.internal.example.comque no están permitidas entre www.example.comy *.example.net, especialmente la configuración de cookies entre sitios. La ejecución de servicios internos y externos en el mismo dominio aumenta el riesgo de que un compromiso de un servicio público genere cierto ingreso a los servicios internos y, a la inversa, que un servicio interno inseguro pueda provocar un mal uso interno de un servicio externo.
bobince

Respuestas:

94

No use un TLD inventado. Si ICANN lo delegara, estaría en un gran problema. Lo mismo si se fusiona con otra organización que utiliza el mismo TLD ficticio. Es por eso que se prefieren nombres de dominio globalmente únicos.

El estándar, RFC 2606, reserva nombres para ejemplos, documentación, pruebas, pero nada para uso general, y por buenas razones: hoy en día, es tan fácil y barato obtener un nombre de dominio real y único que no hay una buena razón para usar un uno ficticio

Entonces, cómprelo iamthebest.orgy úselo para nombrar sus dispositivos.

bortzmeyer
fuente
53
Para estar totalmente seguro, pondría todo en un subdominio del nombre de dominio de mi empresa, como local.company.org, vm.company.org, etc.
drybjed
44
+1 esto. Presumiblemente su empresa ya tiene un dominio. Simplemente cree un subdominio a partir de esto. No tiene que ser visible / resoluble fuera de su LAN.
Dan Carley
3
Bueno, incluso con muy buenos abogados, tendrá problemas para reclamar ".lan" o ".local" invocando una marca registrada. Y el argumento "es solo interno" es extremadamente débil: las organizaciones se fusionan, establecen redes privadas virtuales con organizaciones asociadas y simplemente cometen errores de manera que se filtren los nombres "privados".
bortzmeyer 02 de
8
Mi único problema con esto es que realmente no puedes "comprar" un dominio: solo puedes alquilar uno. Algunos bozo se olvidan de pagar una factura (y esto ha sucedido en algunos casos de alto perfil) y una parte central de su configuración va a un okupa aleatorio. ¿Entonces usas el dominio de tu empresa? Los ejecutivos deciden renombrar o comprar, y estás atrapado con un nombre antiguo. .local solía funcionar lo suficientemente bien, pero ahora ha sido reemplazado por cierta compañía en formas que se niegan a jugar bien. Realmente me gustaría ver algo como .lan o .internal formalmente reservado para este propósito, pero hasta entonces esta es la mejor opción.
Joel Coel
66
De acuerdo con @ Joel Coel, eres un inquilino, y nada más. Debería haber dos nombres de TLD reservados solo para uso interno que deberían considerarse inválidos en público y no accesibles por redes públicas. Un nombre sería para uso doméstico interno, el segundo nombre sería para uso comercial interno. Ambos se considerarían "TLD privados" en el mismo sentido que tenemos "subredes privadas" que no son enrutables (192.168.xx e ilk). Esto permite a los usuarios domésticos hacer algo además de verse obligados a usar .local y mDNS. Lo mismo ocurre con las pequeñas empresas que ejecutan una LAN interna detrás de un NAT sin dominio.
Avery Payne
49

Utilice un subdominio del dominio registrado de su empresa para máquinas internas cuyos nombres no desee que estén disponibles en Internet. (Entonces, por supuesto, solo aloje esos nombres en sus servidores DNS internos). Estos son algunos ejemplos de la ficticia Example Corporation.

Servidores con conexión a Internet:
www.example.com
mail.example.com
dns1.example.com

Máquinas internas:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

Utilicé "corp" para indicar que este subdominio describía máquinas en la red corporativa interna, pero podría usar cualquier cosa que desee aquí, como "internal": client1.internal.example.com.

Recuerde también que las zonas y subdominios DNS no tienen que alinearse con su esquema de numeración de red. Mi empresa, por ejemplo, tiene 37 ubicaciones, cada una con su propia subred, pero todas las ubicaciones usan el mismo nombre de dominio (interno). Por el contrario, podría tener solo una o algunas subredes, pero muchos dominios internos o niveles de subdominios para ayudarlo a organizar sus máquinas.

Jay Michaud
fuente
32

Hay otra ventaja de usar un subdominio interno: usando inteligentemente sufijos de búsqueda y solo nombres de host en lugar de FQDN, puede crear archivos de configuración que funcionen tanto en desarrollo, control de calidad y producción.

Por ejemplo, siempre usa "database = dbserv1" en su archivo de configuración.

En el servidor de desarrollo, establezca el sufijo de búsqueda en "dev.example.com" => servidor de base de datos utilizado: dbserv1.dev.example.com

En el servidor de control de calidad, establezca el sufijo de búsqueda en "qa.example.com" => servidor de base de datos utilizado: dbserv1.qa.example.com

Y en el servidor de producción, establece el sufijo de búsqueda en "ejemplo.com" => servidor de base de datos utilizado: dbserv1.example.com

De esa manera, puede usar la misma configuración en todos los entornos.

geewiz
fuente
2
Eso es genial
Chris Magnuson
19
Hasta que alguien configure mal su estación de trabajo con el sufijo de búsqueda de producción para probar un problema, y ​​más tarde, sin darse cuenta, actualice un montón de registros de producción.
Joel Coel
1
Eso es bastante burdo, los registros SRV son muy fáciles de analizar y se pueden colocar dentro de cualquier zona, de modo que el mismo servidor db sirve en varias zonas. En este caso, un poco de código estaría completando el valor dentro de sus archivos de configuración. Y puede usar el nombre de la base de datos como la clave SRV y, por supuesto, el valor que apunta al nombre de host. Nunca confiaría en los sufijos de búsqueda. También puede ser bastante creativo con los registros TXT, y puede rellenarlos con valores cifrados aes-256 (luego codificados en base64), si son secretos. Puede usar registros TXT para todo tipo de cosas.
figtrap
vea, pero lo que quiero es example.com, example.dev y example.stg. Los últimos 2 solo están en una red privada, ¿puedo configurar un servidor DNS local para acceso de configuración cero? Todavía estoy usando una configuración similar aquí para todos los sitios, solo moviendo los cambios hasta tld. Fácil para .dev con un archivo hosts, pero cero configuración ...
DigitalDesignDj
15

Desde que se escribieron las respuestas anteriores a esta pregunta, ha habido un par de RFC que alteran un poco la orientación. RFC 6761 analiza los nombres de dominio de uso especial sin proporcionar una guía específica para redes privadas. RFC 6762 todavía recomienda no usar TLD no registrados, pero también reconoce que hay casos en los que se hará de todos modos. Dado que el .local comúnmente utilizado entra en conflicto con el DNS de multidifusión (el tema principal del RFC), el Apéndice G. Espacios de nombres de DNS privados recomienda los siguientes TLD:

  • intranet
  • interno
  • privado
  • corp
  • casa
  • lan

IANA parece reconocer ambos RFC pero no (actualmente) incorpora los nombres enumerados en el Apéndice G.

En otras palabras: no deberías hacerlo. Pero cuando decida hacerlo de todos modos, use uno de los nombres anteriores.

blihp
fuente
El Apéndice G tiene antes de la lista que usted cita: "No recomendamos el uso de dominios de nivel superior no registrados en absoluto". Este es más el punto clave. Los nombres dados no son "recomendados" para usar, solo son nombres observados que funcionarán mejor de lo .localque está reservado para MulticastDNS, que es la discusión en el Apéndice G.
Patrick Mevzek
2
No estaría de acuerdo. El punto clave es lo absurdo del consejo: 'no lo hagas ... pero cuando lo hagas ...' La expectativa de que las redes domésticas / pequeñas empresas / no públicas deben registrar un TLD no es realista. La gente se va a utilizar dominios de nivel superior no registrados hasta el momento mejor para ayudar a todo el mundo y decir 'OK, aquí está una lista de dominios de nivel superior no registrados se pueden utilizar internamente' en vez de pretender todo el mundo va a seguir el consejo de línea dura.
blihp
Seguiremos en desacuerdo entonces. El hecho de que algunas personas usaran TLD como si fueran internas (por ejemplo, se .MAIL encuentran en muchas documentaciones) es exactamente la razón por la cual no fue posible delegar estos TLD y ahora están indefinidamente muertos. Por lo tanto, seguir recomendando a las personas que utilicen TLD de esa manera es un mal servicio para la comunidad global de Internet. El consejo dice que, dado que algunos TLD ya se abusan de esa manera, si las personas tienen que abusar, deberían reutilizarlos en lugar de abusar de otros nuevos. RFC2606 es claro para que los TLD lo utilicen internamente y funcionarán:.EXAMPLE .TEST .INVALID
Patrick Mevzek,
12

Como ya se dijo, no debe usar un TLD no registrado para su red privada. Especialmente ahora que ICANN permite que casi cualquier persona registre nuevos TLD. Entonces deberías usar un nombre de dominio real

Por otro lado, el RFC 1918 es claro:

Las referencias indirectas a tales direcciones deben estar contenidas dentro de la empresa. Ejemplos prominentes de tales referencias son los registros de recursos DNS y otra información que se refiere a direcciones privadas internas. Por lo tanto, su servidor de nombres también debe usar vistas para evitar que los registros privados se transmitan en Internet.

Benoit
fuente
10

Tendemos a no considerar ninguna diferencia en el nombre virtual de los hosts de lo físico; de hecho, nos hemos dedicado a abstraer la configuración del host (software) de la capa física.

Así que compramos elementos de hardware y creamos elementos de host encima de ellos (y usamos una relación simple para mostrar eso en nuestra documentación).

El propósito es que cuando exista un host, el DNS no debería ser el factor determinante, ya que tenemos máquinas que se mueven de un espacio a otro; por ejemplo, una aplicación web de bajo rendimiento no necesita consumir costosos ciclos de CPU, virtualícela , y conserva su esquema de nombres, todo sigue funcionando.

Mike Fiedler
fuente
-4

No estoy seguro de que esto lo ayude, pero para el DNS interno dentro de mi cuenta de AWS, lo uso .awscomo tld, y parece funcionar perfectamente bien.

Sé que hay algunos TLD que simplemente no debes usar, pero aparte de esos, no creo que sea demasiado estricto.

Trabajé en algunas compañías más grandes, donde usarían la fuente de autenticación como TLD, lo que significa que si fuera un servidor MS / Windows, usaría Active Directory como fuente de autenticación, lo sería .ad, y algunas otras serían .ldap(¿Por qué no? ¿No estoy usando la misma fuente o servidores que se replican desde el mismo servicio de directorio? No sé, fue así cuando llegué allí)

Buena suerte

Justin
fuente
2
Amazon ahora se ha registrado .awscomo un TLD, por lo que podría comenzar a ver problemas eventualmente: nic.aws
Mark McKinstry
1
Para información, el .aws se registró recientemente "25 de marzo de 2016" => newgtlds.icann.org/en/program-status/delegated-strings
Bruno Adelé
Si bien no creo que usar un TLD falso sea un gran problema, al menos no si todo el sistema está cerrado y usa un proxy para comunicarse con Internet en general, ".aws" es una muy mala opción a menos que usted NO estás en AWS! Hay demasiados escenarios imaginables en los que ya no podrá comunicarse con AWS.
figtrap