Em nosso escritório, temos uma rede local com uma configuração de DNS puramente interna, na qual todos os clientes são nomeados como 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 pode ser acessada pela nossa rede local, mas estamos configurando uma rede de produção para a qual migrar essas máquinas virtuais, que poderá ser acessada pela LAN. Como resultado, estamos tentando estabelecer uma convenção para o sufixo de domínio/TLD que aplicamos aos convidados nesta nova rede que estamos configurando, mas não conseguimos chegar a uma boa, já que .vm, .locale .lantodos têm conotações existentes em nosso ambiente.
Então, qual é a melhor prática nesta situação? Existe uma lista de TLDs ou nomes de domínio em algum lugar que seja seguro para uso em uma rede puramente interna?
Não use um TLD inventado. Se a ICANN delegar isso, você estaria em apuros. A mesma coisa se você fundir com outra organização que usa o mesmo TLD fictício. É por isso que os 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 único que não há uma boa razão para usar um um manequim.
Portanto, compre
iamthebest.orge use-o para nomear seus dispositivos.Desde que as respostas anteriores a esta pergunta foram escritas, houve algumas RFCs que alteram um pouco a orientação. A 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 Multicast DNS (o tópico principal da RFC), o Apêndice G. Espaços de nomes privados do DNS recomenda os seguintes TLDs:
A IANA parece reconhecer ambas as RFCs , mas não incorpora (atualmente) os nomes listados no Apêndice G.
Em outras palavras: você não deve fazer isso. Mas quando você decidir fazê-lo de qualquer maneira, use um dos nomes acima.
Use um subdomínio do domínio registrado de sua empresa para máquinas internas cujos nomes você não deseja disponíveis na Internet. (Então, é claro, hospede apenas esses nomes em seus servidores DNS internos.) Aqui estão alguns exemplos da 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 descrevia máquinas na rede corporativa interna, mas você pode usar o que quiser aqui, como "interno": client1.internal.example.com.
Lembre-se também de que as zonas e subdomínios DNS não precisam se alinhar com o esquema de numeração de sua rede. Minha empresa, por exemplo, tem 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 internos de pares ou níveis de subdomínios para ajudá-lo a organizar suas máquinas.
Há outra vantagem de usar um subdomínio interno: usando sufixos de pesquisa de forma inteligente e apenas nomes de host em vez de FQDN, você pode criar arquivos de configuração que funcionam tanto em desenvolvimento, controle de qualidade e produção.
Por exemplo, você sempre usa "database = dbserv1" em seu arquivo de configuração.
No servidor de desenvolvimento, você define o sufixo de 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 de 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 de 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.
Como sempre, existem padrões de jure e de facto.
Enquanto a ICANN "sem fins lucrativos" joga com política e dinheiro, nós, pessoas comuns, sofremos. O IETF foi introduzido uma vez
.home(RFC 7788) para intranets domésticas pessoais, mas eles não têm poder sobre os players IANA apenas para pofit e reintroduziram o domínio sob.home.arpa(RFC 8375), pois o IETF controla apenas.arpa.O Apêndice G de https://www.rfc-editor.org/rfc/rfc6762 menciona:
para uso se você realmente deseja um TLD interno.
Grandes players (Google, Amazon) usam
.internalpara intranets virtuais:ip-private-ipv4-address.ec2.internalpara aus-east-1região eip-private-ipv4-address.region.compute.internalpara outras regiões (onde private-ipv4-address é o endereço IP de pesquisa inversa).[INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internalpara todas as organizações ou projetos independentes que ativaram a Compute Engine API após 6 de setembro de 2018.Essas empresas podem comprar a Internet. Portanto, é de fato seguro usar
.internalo TLD internamente))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 então usar um nome de domínio real.
Por outro lado, a RFC 1918 é clara:
Portanto, seu servidor de nomes também deve usar visualizações para evitar que os registros privados sejam transmitidos na Internet.
Nós tendemos a não considerar nenhuma diferença na nomenclatura virtual dos hosts do físico - na verdade, nós começamos a abstrair a configuração do host (software) da camada física.
Então, compramos itens de hardware e criamos itens de host em cima deles (e usamos um relacionamento simples para mostrar isso em nossa documentação).
O objetivo é que, quando um host existe, o DNS não deve ser o fator determinante - já que temos máquinas que se movem de um espaço para outro - por exemplo, um webapp de baixo desempenho não precisa consumir ciclos de CPU caros - virtualize-o , e mantém seu esquema de nomenclatura, tudo continua funcionando.
Um Projeto de Internet expirado intitulado Domínios de primeiro nível para Internets privadas teria sancionado o uso dos 42 "elementos de código atribuídos pelo usuário" de duas letras como TLDs para uso privado.
AAQMparaQZXAparaXZZZEntão poderíamos ter usado
aaaaaa.aaaaaaaaaa.aagg.qqtired.zzwindows.xpe assim por diante.
Embora este rascunho tenha expirado e, portanto, não se torne um padrão proposto, na IETF-111 o grupo dnsop teve uma atualização sobre a proposta: minutos vídeo slides1 slides2
A atualização termina com (ênfase minha):
Então, lendo nas entrelinhas, e no espírito de inovação sem permissão...
Mas falando sério, assista o vídeo ou pelo menos leia os minutos antes de usar qualquer um desses!
A resposta real de acordo com a especificação do IETF é:
Estou surpreso com todas as respostas agressivas, quando uma orientação específica real existe desde 1999.
Não posso dizer se isso sempre ignorará o HSTS. Isso ainda pode ser uma questão em aberto.
Não tenho certeza se isso irá ajudá-lo, mas para DNS interno dentro da minha conta da AWS, eu uso
.awscomo o tld e parece funcionar perfeitamente.Eu sei que existem alguns TLDs que você deve simplesmente não usar, mas além desses, não acho que seja muito rigoroso.
Trabalhei em algumas empresas maiores, onde eles usariam a fonte de autenticação como o TLD, ou seja, se fosse um servidor MS/Windows, usando o Active Directory como fonte de autenticação, seria
.ad, e alguns outros seriam.ldap(Por que eles foram não apenas usando a mesma fonte? ou servidores replicando do mesmo serviço de diretório? Não sei, era assim quando cheguei lá)Boa sorte