Não há problema em usar app.mycoolname.local para URLs particulares / internos?
Temos vários aplicativos baseados na web, mas eles são aplicativos particulares e não estão expostos ao público.
Temos usado o ".net" para alguns deles, o que não faz sentido, já que eles poderiam ser colecionados com um URL real na internet. Isso ainda não foi um problema.
Mas agora tenho um novo grupo de aplicativos e quero nomeá-los usando um nome "popular" que irá colidir definitivamente com uma URL na Internet.
Devo usar app.mycoolname.local ? Eu tenho isso configurado agora e parece estar funcionando. Eu li alguns lugares onde foi encorajado, mas então eu vi alguns lugares onde não estava funcionando (algum problema no Mac, mas nós não temos esses, então NBD).
Não use .local. Não use qualquer coisa que você tenha feito. Nem use os TLDs reservados. Use um domínio ou subdomínio real e apenas não permita que ele fique visível para o mundo externo. A principal razão para isso é quando você trabalha para a empresa A que usa .local (ou example.com) e eles compram a empresa B que também usa .local (ou example.com). Não é muito divertido juntar os dois namespaces.
Não use um TLD inventado. Se ICANN fosse delegar, você estaria em apuros. A mesma coisa se você se fundir com outra organização que use o mesmo TLD simulado. É 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á uma boa razão para usar um modelo falso.
Então, compre iamthebest.org e use-o para nomear seus dispositivos. Outra solução: local.yourdomain.org .
Eu não usaria o .local a menos que você entenda como funciona o zeroconf, já que ele se tornará um negócio maior quando você começar a ver o IPv6 entrar no mainstream.
No passado, usei:
OMI, qualquer uma das últimas opções são ideias melhores.
Tecnicamente, você não deveria usá-lo. É usado pelo DNS multicast / rede de configuração zero para endereços locais de link. Na prática, não parece importar muito. Eu tenho usado um laptop Mac (que usa zeroconf) em uma rede interna com um sufixo .local nos últimos dois anos sem problemas.
Como Gerald Combs apontou .local é um domínio reservado e não deve ser usado além do pretendido.
Como Gerald Combs apontou, o domínio .local é usado por muitos softwares da Apple (e outros) e, portanto, usá-lo de outra maneira poderia causar problemas com este software.
Por que não usar um subdomínio do seu site público? Algo como app.internal.mycompany.com seria apropriado e não colidiria com o seu site público.
.local é usado pelo Small Business Server da Microsoft e pelo MDNS em Macs (ou seja, Bonjour). Acho que o fato de ser usado tanto pela Apple quanto pela Microsoft torna pouco provável que a ICANN o delegue, mas não é reservado e, teoricamente, ainda é possível que eles o façam.
Eu usaria algo como server.internal.yourcompany.com
Se você quis saber mais algumas informações sobre .local e por que isso pode ou não ser um problema para você para usá-lo. Não parece haver nenhuma zona reservada para uso interno
Uma boa solução de compromisso é usar um subdomínio interno em conjunto com um caminho de pesquisa DNS.
Como exemplo real, um aplicativo em que estou trabalhando pode ser abordado integralmente como some-app.beta.internal.mycompany.com , mas como internal.mycompany.com está no caminho de pesquisa do DNS para estações de trabalho, conforme retornado pelo servidor DHCP, posso acessar como some-app.beta . Ainda existe a possibilidade de colisão se esses nomes forem escolhidos incorretamente, mas, nesse caso, uma colisão pode ser resolvida usando um FQDN. (Ou, se você quiser se proteger, sempre usando FQDNs para as coisas importantes - embora o ponto final nos nomes DNS seja tristemente negligenciado.)
leia o link e escolha seu nome de domínio local. resumo: não invente o seu, compre um domínio real ou use .1 - .9
Como apontado por muitos; Em geral, uma má idéia é usar um TLD não registrado para intranets. No entanto, [0] afirma que existem alguns nanmes comumente usados (embora não aprovados apenas para uso na intranet). [0] ainda desencoraja usar o TLD mencionado para redes locais e local. não deve ser usado em qualquer outra situação que não seja um DNS multicast.
[0] RFC6762, apêndice G: link
Eu sempre fui um grande fã do TLD .lan interno.
Nós usamos .local o tempo todo com macs e pcs. Aproveite