Resumo

  • draft-levine-dnsextlang-14 propõe descrever RRTYPEs em TXT para que vários tipos novos sejam aceitos como configuração. Continua sendo um Internet-Draft individual, não um RFC nem um serviço IANA já implantado.
  • A opção X informa que o tipo precisa de processamento especial e permite rejeitá-lo quando esse recurso falta. Ela não entrega código nem comprova capacidade.
  • DNSSEC autentica origem e integridade conforme a política do validador. Sem conciliar os dois nomes, registrar caches e overrides, testar limites e ler uma consulta autoritativa, ainda não há prova de execução.

O risco começa numa interface que parece pronta. Um TXT assinado produz campos de formulário e passa na validação. O sistema pode chamar isso de suporte, embora o servidor autoritativo ainda não tenha mostrado o RDATA que realmente servirá. A proposta é valiosa porque remove uma etapa de release; é delicada pelo mesmo motivo.

Hoje, um RRTYPE novo pode exigir alterações no formato de arquivo mestre e nas ferramentas de provisionamento. O rascunho descreve stanzas com nome, número, opções e campos. Um servidor poderia converter texto em representação binária; uma ferramenta poderia reconstruir texto depois de AXFR; formulários poderiam nascer da mesma descrição. A implementação não desaparece: parte dela passa a ser interpretação de dados.

Duas chaves de busca, várias gerações

O desenho publica TXT idênticos sob o número em RRTYPE.ARPA e sob o nome em RRNAME.ARPA; um pode ser CNAME do outro. Variantes de idioma contêm descrições humanas. Entretanto, o texto não diz como arbitrar cópias divergentes. Caches podem reter gerações diferentes e o arquivo local opcional pode sobrepor a fonte central.

Há até uma inconsistência observável: a prosa localiza o diretório em _LIST.RRTYPE.ARPA, enquanto o exemplo usa _LIST.RRNAME.ARPA. Isso deve ser corrigido no documento, não transformado em convenção privada de cada produto.

TTL também não fornece troca atômica. RFC 8767 permite, em condições restritas, servir dados stale quando a atualização autoritativa falha. O rascunho não manda usar esse recurso, mas o recibo precisa distinguir resposta atual, cache válido e fallback vencido. O mesmo vale para o override local: autonomia é útil; override invisível destrói a reconstrução.

DNSSEC não aprova o significado

A seção de segurança cita DNS spoofing e DNSSEC. RFC 4033 limita a garantia a origem e integridade de RRsets, com âncoras e cadeias de autenticação. Uma validação segura mostra quem publicou aqueles bytes e que eles não mudaram sem detecção. Não mostra que os campos fazem sentido, que as duas cópias coincidem, que o parser é robusto ou que o operador autorizou ativação.

Publicação, autenticação e execução são três decisões. Misturá-las sob a palavra “confiança” permite que uma assinatura seja usada como substituta para testes que ela nunca realizou.

X é uma trava, não um módulo

Tipos marcados com X precisam de processamento adicional. O objetivo é que um servidor sem esse comportamento rejeite a zona. I, A, O e E descrevem classes, obsolescência ou condição experimental. São metadados, não implementação.

RFC 3597 já permite preservar tipos desconhecidos com TYPEnn \# comprimento hexadecimal e determina tratamento transparente, sem processamento adicional. O novo idioma melhora sintaxe humana, formulários e conversão orientada por tabela. Não inventa o transporte de RDATA desconhecido, e a forma genérica continua sendo uma saída conservadora.

O recibo liga descrição a comportamento

O próprio rascunho alerta que definições inválidas podem provocar bugs em software que não verifica a entrada e que registros arbitrários podem atravessar restrições de provisionamento. Portanto, guarde revisão e estado do documento; hashes das versões numérica, simbólica e linguística; validação DNSSEC e política; TTL, idade e stale; hash do arquivo local; versões do servidor, parser e backend; módulo para cada X; vetores positivos, negativos e de recursos; bytes do ida e volta texto–wire; carga canário, consulta autoritativa, escopo e rollback.

Esse recibo é a proposta operacional deste artigo, não texto normativo do draft. Sua disciplina impede atalhos: assinatura não substitui teste; teste não substitui carga; carga não substitui resposta; uma resposta não prova convergência.

A falha passa a ter endereço. Divergência entre nomes é conciliação. Token desconhecido é admissão de capacidade. Byte alterado é codec. Canário saudável e produção falha é implantação. Chamar tudo de “suporte RRTYPE” só amplia o raio de rollback.

O mínimo comum preserva escolha local

A camada central precisa de gramática, vínculo nome–número, semântica de campo, idioma, registro e invariantes de interoperabilidade. Backend, limites, tempo de ativação, processamento especial e rollback pertencem a quem opera o serviço.

É a lógica da especificação inicial mínima de Heng Lu: tornar comum apenas o indispensável e deixar decisões futuras perto de quem assume o efeito. A adoção voluntária termina em running code comprovado, não na presença de uma entrada no registro.