Domínio de nível superior / sufixo de domínio para rede privada?

Em nosso escritório, temos uma rede local com uma configuração de DNS puramente interna, na qual todos os clientes são nomeados whatever.lan. Também tenho um ambiente VMware e, na rede somente de máquina virtual, nomeio as máquinas virtuais whatever.vm.

Atualmente, essa rede para as máquinas virtuais não está acessível a partir da nossa rede local, mas estamos configurando uma rede de produção para a qual migrar essas máquinas virtuais, que estará acessível a partir da LAN. Como resultado, estamos tentando estabelecer uma convenção para o sufixo de domínio / TLD que aplicamos aos convidados nessa nova rede que estamos montando, mas não podemos criar uma boa, considerando isso .vm, .locale .lantodos têm conotações existentes em nosso ambiente.

Então, qual é a melhor prática nessa situação? Existe uma lista de TLDs ou nomes de domínio em algum lugar seguro para usar em uma rede puramente interna?

Não use um TLD inventado. Se a ICANN delegasse, você estaria com um grande problema. A mesma coisa se você se fundir com outra organização que por acaso usar o mesmo TLD fictício. É por isso que nomes de domínio globalmente exclusivos são preferidos.

O padrão, RFC 2606 reserva nomes para exemplos, documentação, testes, mas nada para uso geral e por boas razões: hoje, é tão fácil e barato obter um nome de domínio real e exclusivo que não há um bom motivo para usar um manequim.

Portanto, compre iamthebest.orge use-o para nomear seus dispositivos.

Use um subdomínio do domínio registrado da sua empresa para máquinas internas cujos nomes você não deseja que estejam disponíveis na Internet. (Então, é claro, hospede apenas esses nomes nos servidores DNS internos.) Aqui estão alguns exemplos para a fictícia Example Corporation.

Servidores voltados para 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

Usei "corp" para significar que esse subdomínio descreveu máquinas na rede corporativa interna, mas você pode usar o que quiser aqui, como "internal": client1.internal.example.com.

Lembre-se também de que as zonas e subdomínios DNS não precisam se alinhar ao seu esquema de numeração de rede. Minha empresa, por exemplo, possui 37 locais, cada um com sua própria sub-rede, mas todos os locais usam o mesmo nome de domínio (interno). Por outro lado, você pode ter apenas uma ou algumas sub-redes, mas muitos domínios ou níveis internos de pares para ajudá-lo a organizar suas máquinas.

Há outra vantagem do uso de um subdomínio interno: usando inteligentemente sufixos de pesquisa e apenas nomes de host em vez do FQDN, é possível criar arquivos de configuração que funcionem tanto no desenvolvimento, no controle de qualidade e na produção.

Por exemplo, você sempre usa "database = dbserv1" no seu arquivo de configuração.

No servidor de desenvolvimento, você define o sufixo da pesquisa como "dev.example.com" => servidor de banco de dados usado: dbserv1.dev.example.com

No servidor de controle de qualidade, você define o sufixo da pesquisa como "qa.example.com" => servidor de banco de dados usado: dbserv1.qa.example.com

E no servidor de produção, você define o sufixo da pesquisa como "example.com" => servidor de banco de dados usado: dbserv1.example.com

Dessa forma, você pode usar as mesmas configurações em todos os ambientes.

Desde que as respostas anteriores a essa pergunta foram escritas, existem algumas RFCs que alteram um pouco as orientações. O RFC 6761 discute nomes de domínio de uso especial sem fornecer orientações específicas para redes privadas. A RFC 6762 ainda recomenda não usar TLDs não registrados, mas também reconhece que há casos em que isso será feito de qualquer maneira. Como o .local comumente usado entra em conflito com o DNS multicast (o tópico principal da RFC), o Apêndice G. Namespaces DNS privados recomenda os seguintes DPNs:

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

A IANA parece reconhecer os dois RFCs, mas atualmente não incorpora os nomes listados no Apêndice G.

Em outras palavras: você não deve fazê-lo. Mas quando você decidir fazer isso de qualquer maneira, use um dos nomes acima.

Como já foi dito, você não deve usar um TLD não registrado para sua rede privada. Especialmente agora que a ICANN permite que quase qualquer pessoa registre novos TLDs. Você deve usar um nome de domínio real

Por outro lado, a RFC 1918 é clara:

Referências indiretas a esses endereços devem estar contidas na empresa. Exemplos proeminentes de tais referências são os Registros de Recursos DNS e outras informações referentes aos endereços privados internos. Portanto, seu servidor de nomes também deve usar visualizações para impedir que os registros particulares sejam transmitidos na Internet.

Nós tendemos a considerar nenhuma diferença na nomeação virtual de hosts do físico - na verdade, passamos a abstrair a configuração do host (software) da camada física.

Portanto, adquirimos itens de hardware e criamos itens de host sobre eles (e usamos um relacionamento simples para mostrar isso em nossa documentação).

O objetivo é que, quando existe um host, o DNS não deve ser o fator determinante - já que temos máquinas movendo-se de um espaço para o outro - por exemplo, um webapp de baixo desempenho não precisa consumir ciclos de CPU caros - virtualize-o e mantém seu esquema de nomeação, tudo continua funcionando.

Não sei se isso ajudará você, mas, para o DNS interno da minha conta da AWS, eu uso .awscomo tld e parece funcionar perfeitamente bem.

Eu sei que existem alguns TLDs que você simplesmente não deve usar, mas, além desses, não acho que seja muito rigoroso.

Eu trabalhei em algumas empresas maiores, onde elas usariam a fonte de autenticação como o TLD, ou seja, se fosse um servidor MS / Windows, usando o Active Directory como a fonte de autenticação .ad, e outras seriam .ldap(por que não está apenas usando a mesma fonte? ou servidores replicando do mesmo serviço de diretório? Eu não sei, era assim quando cheguei lá)

Boa sorte