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


En nuestra oficina, tenemos una red de área local con una configuración de DNS puramente interna, en la que los clientes reciben el nombre de 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, la cual será Ser accesible desde la LAN. Como resultado, estamos tratando de acordar una convención para el sufijo de dominio / TLD que aplicamos a los invitados en esta nueva red que estamos configurando, pero no podemos encontrar una buena, dado que .vm, .local y .lan Todos tienen connotaciones existentes en nuestro entorno.

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


103
2018-06-01 21:47


origen


No uses .local. Especialmente si tienes algún cliente de Apple. - RainyRat
.test se reserva por esta razón: secure.wikimedia.org/wikipedia/en/wiki/.test - CWSpear
@CWSpear Eso no es lo real razón  .test está reservado, aunque lo convierte en un dominio seguro para usar prueba Redes que no estarán conectadas a internet. - voretaq7
Las prácticas recomendadas de @Otto dictarán que adquiera un nombre de dominio "real" (bajo un TLD reconocido por la ICANN) y cree un subdominio para sus cosas locales (por ejemplo, registro mydomain.comdelegar internal.mydomain.com a un NS interno, y configure adecuadamente 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 la rotura, ya que está bajo su control. - voretaq7
sin embargo: no utilice un nombre de dominio real que ya haya utilizado para los servicios de producción orientados al público. Hay varias interacciones que se permiten entre www.example.com y *.internal.example.com que no se permiten entre www.example.com y *.example.net, sobre todo 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 proporcione cierta entrada a los servicios internos y, a la inversa, de que un servicio interno inseguro podría provocar el uso interno incorrecto de un servicio externo. - bobince


Respuestas:


No utilice un TLD inventado. Si la ICANN lo delegara, estarías 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 los nombres de dominio globalmente únicos.

El estandar, 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 uno ficticio.

Entonces comprar iamthebest.org y úsalo para nombrar tus dispositivos.


85
2018-06-02 07:39



Para estar totalmente seguro, pondría todo en un subdominio del nombre de dominio de mi compañía, como local.company.org, vm.company.org, y así sucesivamente. - drybjed
+1 esto. Presumiblemente su empresa ya tiene un dominio. Solo crea un subdominio a partir de esto. No tiene que ser visible / resoluble fuera de su LAN. - Dan Carley
Bueno, incluso con muy buenos abogados, tendrá problemas para reclamar ".lan" o ".local" al invocar una marca registrada. Y el argumento "es solo interno" es extremadamente débil: las organizaciones se fusionan, configuran redes privadas virtuales con organizaciones asociadas y simplemente cometen errores de tal manera que los nombres "privados" se filtran. - bortzmeyer
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 ocurrido en unos pocos casos de alto perfil) y una parte central de su configuración va a algún ocupante aleatorio. ¿Entonces usas el dominio de tu empresa? Los ejecutivos deciden cambiar de marca o ser comprados, y estás atrapado con un nombre antiguo. .local solía funcionar lo suficientemente bien, pero ahora una empresa determinada lo ha sustituido de manera que se niegan a jugar bien. Realmente me gustaría ver algo así como .lan o .internal formalmente reservado para este propósito, pero hasta entonces esta es la mejor opción. - Joel Coel
De acuerdo con @Joel Coel, usted es un inquilino y nada más. Debe haber dos nombres de TLD reservados Sólo para uso interno Eso debería ser considerado inválido en público y no accesible por las redes públicas. Un nombre sería para uso doméstico interno, el segundo nombre sería para uso interno de negocios. Ambos se considerarían "TLD privados" en el mismo sentido que tenemos "subredes privadas" que no son enrutables (192.168.x.x e ilk). Esto permite a los usuarios domésticos hacer algo además de ser forzados a .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


Use un subdominio del dominio registrado de su compañía para las máquinas internas cuyos nombres no desea que estén disponibles en Internet. (Entonces, por supuesto, solo aloje esos nombres en sus servidores DNS internos). Aquí hay algunos ejemplos para la Corporación de Ejemplo ficticia.

Servidores orientados a internet:
www.ejemplo.com
mail.example.com
dns1.example.com

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

Usé "corp" para indicar que este subdominio describía las máquinas en la red corporativa interna, pero podría usar lo que quiera aquí, como "interno": client1.internal.example.com.

Recuerde también que las zonas y subdominios de 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). A la inversa, puede tener solo una o unas pocas subredes, pero muchos dominios internos o niveles de subdominios de pares para ayudarlo a organizar sus máquinas.


46
2018-06-02 13:03





Otra ventaja es el uso de un subdominio interno: el uso inteligente de los sufijos de búsqueda y solo los nombres de host en lugar del FQDN, puede crear archivos de configuración que funcionen tanto en desarrollo como en control de calidad y producción.

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

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

En el servidor QA, establece 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 "example.com" => servidor de base de datos utilizado: dbserv1.example.com

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


29
2018-06-04 12:00



Eso es genial. - Chris Magnuson
Hasta que alguien confunde erróneamente su estación de trabajo con el sufijo de búsqueda de producción para probar un problema, y ​​luego actualiza inadvertidamente un grupo de registros de producción. - Joel Coel
Eso es bastante burdo, los registros SRV son muy simples de analizar y se pueden colocar dentro de cualquier zona, de manera que el mismo servidor db sirve a 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 el valor del curso que apunta al nombre de host. Nunca me apoyaría en buscar sufijos. También puede ser bastante creativo con los registros TXT, y puede rellenarlos con valores encriptados aes-256 (luego codificados en base64), si son secretos. Puede utilizar registros TXT para todo tipo de cosas. - figtrap
mira, pero lo que quiero es example.com, example.dev y example.stg. Los últimos 2 son solo en una red privada, ¿puedo configurar un servidor DNS local para acceso de configuración cero? Sigo usando una configuración similar aquí para todos los sitios, simplemente moviendo los cambios hasta tld. Fácil para .dev con un archivo hosts, pero cero config ... - DigitalDesignDj


Como ya se dijo, no debe usar un TLD no registrado para su red privada. Especialmente ahora que la ICANN permite que casi cualquier persona registre nuevos TLD. A continuación, debe utilizar un nombre de dominio real

Por otro lado, el RFC 1918 es claro:

Referencias indirectas a dichas direcciones.   debe estar contenido dentro de la   empresa. Ejemplos destacados de tales   las referencias son registros de recursos DNS   y otra información referente 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.


10
2018-06-02 12:41





Tendemos a considerar que no hay diferencia en la denominación virtual de los hosts del físico; de hecho, hemos tomado la decisión de abstraer la configuración del host (software) de la capa física.

Entonces 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 existe un host, el DNS no debe 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 tiene necesidad de consumir costosos ciclos de CPU, virtualizarla , y mantiene su esquema de denominación, todo sigue funcionando.


8
2018-06-01 21:52





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

Sé que hay algunos TLD que simplemente no debes usar, pero aparte de eso, 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 se trataba de un servidor MS / Windows, utilizando Active Directory como la fuente de autenticación, sería .ad, y algunos otros serían .ldap (¿Por qué no solo usaban la misma fuente o los servidores que se replicaban desde el mismo servicio de directorio? No lo sé, fue así cuando llegué)

Buena suerte


-4
2018-02-29 14:28



Amazon ya se ha registrado .aws como un TLD para que puedas comenzar a ver problemas eventualmente: nic.aws - Mark McKinstry
Para información, el .aws está registrado 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 tan importante, al menos no si el sistema completo está cerrado y usa un proxy para comunicarse con Internet en general, ".aws" es una opción realmente mala a menos que no estás en AWS! Hay demasiados escenarios posibles en los que ya no podrá comunicarse con AWS. - figtrap