Resumo

  • O draft do grupo DNSOP propõe um RRSet formado por um único NS com destino vazio para marcar uma zona filha existente em outro namespace, sem indicar servidores públicos utilizáveis.
  • A sinalização evita que uma negação autenticada obtida fora da empresa seja tomada como inexistência universal quando o dispositivo depois entra no DNS privado.
  • Publicação do pai, referral observado, caminho interno, autoridade filha, validação DNSSEC e uso pela aplicação exigem evidências próprias.

A ausência de um destino pode ser informação

Uma delegação comum combina duas mensagens: aqui começa uma zona filha e estes são os servidores que respondem por ela. No split DNS, a primeira pode ser verdadeira enquanto a segunda não é. A empresa publica example.com globalmente, mas corp.example.com só existe para resolvers internos. Inventar um servidor externo seria uma afirmação falsa.

A revisão 00 usa uma forma estrita: um único registro NS cujo NSDNAME é vazio, representado por NS seguido de ponto. O pai reconhece a fronteira, mas informa que seu namespace não fornece servidor autoritativo para o filho. Misturar alvos NS normais com o alvo vazio não tem o significado definido pela proposta.

O padrão tem parentes no DNS. Null MX afirma que não há serviço de e-mail; SRV com alvo ponto declara o serviço indisponível; AliasMode SVCB também emprega o alvo vazio. Isso não comprova implantação do novo mecanismo. Apenas mostra por que um valor vazio pode ser mais correto do que um endereço fictício.

A prova negativa troca de contexto quando o aparelho troca de rede

Fora do escritório, um notebook pode consultar o DNS global por um nome interno. O resolver validador recebe uma negação assinada e a guarda. De volta à rede corporativa, uma autoridade interna devolve resposta positiva. Se a negação pública for tratada como verdade sobre todos os namespaces, a resposta interna legítima pode ser marcada como bogus.

A zone cut to nowhere reduz a pretensão da resposta pública. Em vez de negar qualquer zona inferior, o pai entrega um referral cujos servidores não podem ser resolvidos nem alcançados. O draft diz que não é necessário processamento especial: o comportamento equivale ao de uma delegação com servidores inalcançáveis. A consulta pública continua sem chegar ao filho.

Porém, a razão do fracasso mudou. “Não existe sob esta autoridade” e “existe uma fronteira em outro namespace” produzem decisões diferentes quando o equipamento muda de rede. O cache precisa preservar essa diferença.

Um campo não substitui uma cadeia de recibos

O primeiro recibo é a configuração exata do pai. O segundo é a autenticação DNSSEC daquilo que o pai publicou. Nenhum identifica um servidor privado.

O terceiro é a resposta realmente observada pelo resolver, com TTL e status de validação. Cache antigo, intermediários e bugs podem separar o arquivo de zona da experiência do cliente.

O quarto é a seleção de caminho depois da mudança de rede. O dispositivo precisa adotar um resolver interno ou regra de encaminhamento capaz de chegar ao filho. O alvo público vazio não descobre esse resolver e não autoriza acesso.

O quinto é a resposta da autoridade filha e sua validação. O sexto é a ação da aplicação e o resultado do serviço. Resolver corretamente um nome não mostra que a aplicação o usou, assim como a publicação do pai não mostra que o serviço privado está saudável.

DS vincula uma chave, não abre a rede

Quando o administrador do pai conhece as chaves da zona filha, a proposta permite publicar DS junto do NS vazio. O resolver que mais tarde encontra o filho privado pode preservar uma relação de confiança DNSSEC.

Essa escolha depende de identidade criptográfica comum. Se diferentes views privadas usam chaves diferentes, ou algumas não são assinadas, um único DS público não serve para todas. A revisão 00 recomenda não usar a delegação segura nesse caso.

Mesmo correto, o DS não cria reachability. Ele ajuda a validar dados depois que o caminho interno os entrega. Não escolhe resolver, não concede entrada na rede e não prova disponibilidade da aplicação.

O status do texto limita a conclusão

A revisão 00 é um Internet-Draft Standards Track ativo do DNSOP, datado de 23 de setembro de 2026. Não é RFC nem consenso final. O exemplo de INTERNAL na raiz é explicativo e não orienta operacionalmente a IANA.

Os autores relatam experimentos sem indicação de problemas amplos, mas registram riscos de premissas incompatíveis em software e tráfego nocivo à raiz. Isso sustenta novos testes, não um certificado universal.

Há ainda a exceção ACME DNS-01. Quem publica TXT temporário no lado público abaixo do filho nominalmente privado não pode alegar, sem ajuste, que ali não existe caminho DNS público. A configuração operacional precisa ser tão honesta quanto o marcador.

Fontes