Resumo

  • A RFC 3123 criou o RR APL para uma lista ordenada de prefixos IPv4 e IPv6, com bit de negação, mas exigiu que cada aplicação definisse lista vazia, múltiplos RRs, famílias desconhecidas e o sentido de !.
  • Um APL válido ou autenticado registrava a publicação de certos bytes. Não provava controle do prefixo, autoridade de política, instalação de ACL, match de pacote ou resultado do serviço.

O DNS recebeu uma representação sem receber um mandato

Em 2001, o DNS já carregava muito além da associação entre host e endereço. O modelo das RFCs 1034 e 1035 publicava servidores, rotas de correio e outros dados de infraestrutura. A RFC 1101 descrevera redes de organizações. Versões antigas do BIND haviam usado faixas em TXT como forma fraca de limitar acesso aos dados da zona.

Essas práticas podiam misturar como descrever uma faixa com o que o software deveria fazer ao lê-la. Publicada como Experimental em junho de 2001, a RFC 3123 separou as camadas. O tipo 42, APL, continha família, comprimento de prefixo, bit N, tamanho e parte dependente da família. Família 1 era IPv4; família 2, IPv6. Um RR podia conter as duas.

O documento não definiu finalidade universal. Declarou que APL era um framework sem significado particular para a lista. Publicar faixas, descrever zona reversa classless ou fornecer material a um controle de acesso eram possibilidades dependentes de especificação própria. Os exemplos não criavam aplicações nem provavam deployment.

Nome, tipo e payload mostram onde uma declaração foi encontrada. Não mostram qual principal pode obrigar o operador, qual regra local vale ou qual ação realmente ocorreu.

O sinal de exclamação ainda precisava de uma regra

Na zona, um item podia começar por !; o wire format guardava isso no bit N. Traduzir imediatamente esse sinal por “negar”, “excluir” ou “sem autorização” acrescentaria semântica. A RFC mandou a especificação da aplicação definir o significado exato da negação.

RDATA vazio era válido e produzia lista vazia. Mas vazio podia ser ninguém, todos, ausência de opinião ou herança. Um RRset com vários APL também era permitido e sua combinação não vinha pronta.

A aplicação precisava declarar famílias esperadas e o tratamento de uma família nova ou estranha. Ignorar um item, rejeitar o RRset e preservá-lo para leitor futuro são escolhas incompatíveis. Parser capaz de ler o campo não recebeu autoridade para escolhê-las.

O shared layer permaneceu mínimo: apenas fatos de representação verificáveis localmente. Decisões futuras ficaram com quem executava código e adotava a aplicação.

Ordem e repetição não eram sujeira

Servidor e resolver não podiam “arrumar” APL. Duplicatas eram legais e não deveriam ser fundidas. A ordem devia ser mantida, sem reordenar ou agregar. Isso só parece desperdício se a lista for considerada um conjunto matemático. A RFC não fez essa promessa: posição e repetição poderiam ser relevantes para uma aplicação futura.

O intermediário transportava a declaração sem alegar compreendê-la. Juntar prefixos vizinhos ou apagar a segunda ocorrência poderia alterar prioridade ou exceção de uma política desconhecida.

No nível de bytes, havia uma canonicalização limitada. Octetos zero finais sem informação de prefixo deviam ser omitidos. Prefixos equivalentes recebiam uma única codificação, necessária ao modelo DNSSEC citado na época.

Canonical bytes resolvem qual objeto comparar ou assinar. Não resolvem o que esse objeto autoriza. Representação determinística e consequência política são registros diferentes.

Autenticação protegia a declaração, não criava autoridade

A seção de segurança dizia para tratar dados DNS como inseguros sem as técnicas DNSSEC ou TSIG referidas. Também alertava que publicar ranges podia revelar topologia e que construir ACLs a partir de APL podia comprometer segurança.

DNSSEC ajuda a verificar origem e integridade de dados assinados. TSIG autentica mensagem ou transação entre partes configuradas. Nenhum deles determina se o gestor da zona podia comandar o firewall, se o consumidor consultou a versão atual, se a compilação terminou, se a regra foi anexada à interface correta ou se o pacote passou por ela.

A cadeia operacional precisa de consulta e horário, RRset exato, validation state, contrato e versão da aplicação, configuração local, policy compilada, acknowledgement do enforcement e observação do tráfego. Pular da resposta DNS ao outcome inventa control onde havia publication.

Delegação e cache tornavam o DNS um canal econômico. Mas distribuir statement não distribui decision authority. O publisher publica; o operator receptor decide adotar.

Tipo 42 não era contador de uso

Os exemplos mostram ranges de uma organização, zona reversa, restrição AXFR e multicast. São ilustrações em domínios reservados. O texto diz que não especificam aplicação nem implicam que uma aplicação APL exista ou vá existir.

Experimental é categoria documental, não recibo de field trial. A RFC 3597 posteriormente tratou unknown RR types, sem medir APL. A RFC 4034 detalhou DNSSEC e canonical form, sem atribuir significado universal ao conteúdo assinado.

A história sustentada pelas fontes é de design: um container compacto, extensível e fiel a família, comprimento, ordem, duplicata e negação declarada. Deployment, fracasso e sucesso exigem código, zonas ou medições adicionais.

A fronteira preservada foi a conquista

O formato comum resolveu apenas a troca sem corrupção. Aplicação definia owner convention, vazio, múltiplos RR, famílias e negação. Operador decidia adoção. Policy engine instalava. Pacote encontrava — ou não — o enforcement point.

Separar não garantia acerto, mas permitia atribuir erro. RR autêntico podia estar stale; spec correta podia ser mal configurada; ACL instalada podia estar na interface errada; receipt positivo podia coexistir com outro path.

O mesmo prefixo textual em DNS, modelo, ACL e log não era um único fato. Tempos, atores e autoridades mudavam.

A RFC 3123 não fez do DNS um soberano. Deu-lhe uma linguagem precisa para carregar prefixos e manteve a decisão fora do record, onde ela precisava ser provada.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt