String de domínio de nível superior proposto para uso privado: ".internal"

Artigo original ↗ Discussão no Hacker News ↗

O plano da ICANN de reservar o top-level domain “.internal” para redes privadas busca oferecer a organizações um sufixo garantidamente nunca público para DNS interno, evitando problemas passados em que escolhas não oficiais como “.dev” ou “.local” depois entraram em conflito com uso público ou com mDNS. Os comentaristas ponderam os benefícios de um TLD privado claro e padronizado contra preocupações com seu tamanho e com suporte TLS limitado (já que autoridades públicas de certificação não emitirãocertificados para ele), e muitos argumentam que usar subdomínios de domínios reais de sua propriedade, junto com nomes reservados existentes como “home.arpa”, continua sendo mais prático em muitas configurações.

Domínios especiais existentes e conflitos

  • A thread analisa os domínios reservados/de uso especial atuais: .example, .invalid, .localhost, .test, .local, .onion, home.arpa.
  • .localhost tem comportamento de loopback padronizado; alguns resolvedores implementam isso, outros exigem configuração local de DNS.
  • .local é amplamente criticado por entrar em conflito com mDNS/Bonjour e zeroconf; há muitos links e relatos sobre descoberta de serviços quebrada e configurações legadas de AD.
  • O processamento de .corp, .home, .mail foi “adiado indefinidamente” pela ICANN, o que é visto como mais fraco do que uma reserva explícita.

Prós e contras de .internal

  • ICANN/IANA propõem .internal como um TLD de uso privado que “nunca será delegado”.
  • Os defensores gostam da clareza, do escopo mais amplo do que “home” e da segurança da não delegação (sem surpresa posterior no estilo .dev).
  • Os críticos acham o nome longo e estranho de digitar, especialmente em TVs/interfaces de IoT; muitos preferem opções curtas como .lan, .intra ou até .d.
  • Alguns se preocupam com confusão com .int e com possíveis padrões parecidos com phishing, como foo.int/ernal.
  • Há ceticismo de que a ICANN não vá depois monetizar strings curtas alternativas; desconfiança geral devido a .dev, .sucks e controvérsias anteriores.

Padrões de design de DNS interno

  • Conselho forte de vários comentaristas: use um domínio que você realmente controla (por exemplo, internal.example.com) em vez de TLDs inventados.
  • Outros destacam problemas dessa abordagem: exposição de nomes internos via DNSSEC, complexidade de split-DNS, quedas e confusão do usuário sobre o que é interno vs. externo.
  • Muitas implantações legadas usaram .local ou .dev internamente e depois sofreram quando eles se tornaram especiais ou públicos.
  • Alguns evitam DNS totalmente em instalações pequenas/domésticas, usando /etc/hosts ou DNS local alimentado por arquivos hosts.

TLS e problemas com certificados

  • Domínios .internal não podem obter certificados públicos de CA; organizações precisariam de CAs privadas ou certificados autoassinados.
  • Vários apontam problemas de usabilidade e segurança quando dispositivos circulam entre redes e confiam em múltiplas CAs privadas, permitindo colisões no mesmo hostname.
  • Ideias levantadas: melhor suporte de navegador para Name Constraints, registro de domínio apenas interno compatível com Let’s Encrypt (via DNS-01 apenas) e formalização de padrões para HTTPS em redes locais.

Alternativas e usabilidade

  • home.arpa já está padronizado para uso residencial; alguns gostam da clareza, outros acham longo e estranho.
  • Opções ad hoc comuns mencionadas: .lan, .lab, .home, .localnet, .d, hostnames curtos mais domínios de busca, ou domínios específicos de roteador como fritz.box.
  • Uma corrente argumenta que qualquer TLD especial acabará sendo usado indevidamente ou cooptado; portanto, “use apenas um domínio real” continua sendo uma recomendação recorrente.