Resumo

  • A RFC 5625, escrita por Ray Bellis, assume que um proxy DNS simples não conseguirá implementar todas as extensões atuais e futuras. Por isso, flags, rótulos, tipos e classes desconhecidos devem passar; a resposta completa, EDNS, TC, TCP e bytes protegidos por autenticação devem ser preservados; mensagens realmente malformadas e políticas ativas devem falhar de modo explícito.
  • Publicada em 2009 como BCP 152, a orientação não prova conformidade atual nem adoção universal. Encaminhamento transparente também não é validação DNSSEC. A contribuição duradoura é uma divisão de competência: especificações e pontas definem o sentido; o proxy administra estado, exposição de interfaces e escolhas locais claramente delimitadas.

O firmware que ganhou poder sobre o futuro

Quando o roteador saiu da fábrica, certo bit no cabeçalho DNS era reservado e deveria permanecer zero. Anos depois, a especificação atribui uma função a ele. O aplicativo entende a função, o resolvedor recursivo também. O proxy continua aplicando sua regra antiga, descarta a consulta e não envia erro.

Não houve incompatibilidade entre as pontas. O calendário de atualização do intermediário virou, sem anúncio, o calendário de evolução do protocolo.

A RFC 5625, DNS Proxy Implementation Guidelines, foi publicada em agosto de 2009 como Best Current Practice 152. Ray Bellis, na época ligado à Nominet UK, é o único autor. O texto parte de condições comuns em gateways: hardware limitado, ciclos longos de firmware e nenhuma possibilidade de adivinhar as futuras extensões do DNS.

A resposta não é transformar todo aparelho num resolvedor completo. É restringir a função do proxy. Ele recebe uma consulta na LAN, encaminha a mensagem sem alteração para um resolvedor recursivo conhecido e devolve a resposta inteira ao cliente que a originou. Ainda correlaciona estado, escolhe upstream e protege interfaces, mas não recebe autoridade semântica só por estar no caminho.

Uma medição histórica com limites claros

O resumo executivo do SAC035 e o relatório completo registram testes controlados de 24 roteadores residenciais ou firewalls para pequenos escritórios realizados em julho e agosto de 2008.

Todos os 24 conseguiam rotear consultas DNSSEC diretamente para um resolvedor externo. Vinte e dois ofereciam modo proxy; seis deles apresentaram problemas com flags relacionadas a DNSSEC ou respostas validadas. Dezoito limitavam respostas UDP a 512 bytes ou a um tamanho relacionado ao MTU; somente quatro devolviam respostas de até 4096 bytes, e apenas um encaminhava DNS por TCP. Seis equipamentos eram plenamente compatíveis na configuração padrão; outros nove permitiam reconfiguração para contornar o proxy incompatível.

Esses números não podem ser usados como retrato dos dispositivos atuais. A amostra tinha 24 unidades, testadas em 2008, e produtos, firmware e práticas mudaram. O valor do estudo é demonstrar um mecanismo real: uma função disponível nas pontas podia desaparecer dentro de um intermediário que o usuário nem percebia como filtro.

O registro de aprovação no IETF descreve consenso forte no grupo DNS Extensions e interesse de fornecedores e compradores. Isso documenta o processo e a demanda pela orientação, não o grau de implementação no mercado.

Desconhecido não é sinônimo de inválido

O corte decisivo da RFC 5625 fica entre uma semântica que o proxy desconhece e uma mensagem impossível de ser válida. Uma flag de cabeçalho desconhecida deve ser ignorada para a lógica interna do proxy, mas o pacote deve seguir. O mesmo se aplica a formas de rótulos, QTYPE, QCLASS, TYPE e CLASS de registros.

Se um parser antigo tratar cada novo valor como erro, nenhuma extensão funcionará antes de todos os intermediários serem substituídos. A RFC 3597 oferece a regra mais ampla para tipos de registro desconhecidos: tratar o RDATA como binário não estruturado, armazenar e transmitir sem alteração. Preservar não significa compreender; significa não impedir que um componente competente compreenda depois.

Uma referência de compressão inválida ou contagens de seções que não podem corresponder ao conteúdo são casos diferentes. A RFC permite rejeitar a mensagem malformada. Ainda assim, quando seguro, recomenda devolver SERVFAIL em vez de silêncio. O cliente encerra a tentativa e a operação recebe evidência de onde ocorreu a recusa.

Uma política ativa de segurança ou rede também pode intervir. Mas deve ser uma escolha intencional e atribuível. Um bloqueio acidental causado por um parser incompleto não vira política legítima só porque os dois produzem perda de pacote.

Tamanho, TC e TCP preservam a completude

Quando um proxy corta uma resposta UDP acima de 512 bytes sem marcar TC, ele não apenas remove registros. Faz a parte restante parecer a resposta inteira. Se apagar o TC vindo do servidor, remove a instrução para repetir em TCP.

A RFC 5625 diz que o proxy não deve truncar apenas porque o pacote passou do limite antigo. Se uma limitação local tornar o corte inevitável, TC precisa ser definido; o TC recebido do upstream nunca deve desaparecer. O cliente consegue reagir a um limite declarado. Não consegue recuperar o que foi escondido como sucesso.

O proxy também deve receber e encaminhar DNS por TCP. Se o cliente já usou TCP, a consulta para o upstream deve continuar em TCP em vez de ser rebaixada a UDP. A RFC 7766, coescrita depois por Bellis e mais quatro autores, tornou o suporte a TCP um requisito de implementações DNS. Ela reforça a fronteira de transporte, sem provar que todos os gateways a respeitam.

EDNS carrega extensibilidade pelo registro OPT. Sua presença não pode causar rejeição. A RFC 6891 afirma que middleboxes conformes não devem impor o teto UDP de 512 bytes e que encaminhadores simples não devem modificar nem apagar o conteúdo OPT em nenhuma direção. A recomendação de 4096 bytes na RFC de 2009 pertence ao contexto técnico daquele período, não é um máximo permanente.

A área de controle que continua local

Um proxy transparente não é um cabo passivo. Ele associa a resposta ao cliente certo, mantém estado por algum tempo, escolhe o resolvedor e pode alterar o Query ID de saída. Decide também em quais interfaces escuta e qual endereço o DHCP anuncia.

Para reduzir a exposição a respostas forjadas, a RFC 5625 remete à RFC 5452, que inclui identificadores de consulta e portas de origem aleatórios. A aleatoriedade aumenta a resistência; não autentica a resposta e não substitui DNSSEC.

TSIG deixa o limite da reescrita ainda mais evidente. Alterar conteúdo DNS autenticado, salvo o tratamento especificamente admitido para o identificador, faz a verificação falhar. O proxy precisa preservar o pacote ou implementar integralmente a autenticação. Um meio-termo que reescreve só o que entende é corrupção detectável.

A exposição de interfaces também pertence à operação. Um proxy destinado à LAN não deveria ficar acessível por padrão na WAN, onde pode participar de reflexão. A RFC 5358 fornece o contexto de ataques com servidores recursivos abertos. Transparência para clientes autorizados não exige abertura pública.

Resta a saída. Na ausência de uma política explícita em contrário, o usuário deve poder consultar um resolvedor especificado e contornar o proxy. Capturar obrigatoriamente toda alternativa transforma uma facilidade de configuração num ponto de veto semântico.

O teste de Bellis começa no que não consta da lista

O perfil de Ray Bellis no IETF lista dez RFCs, incluindo a 5625. A página da equipe do ISC o identifica hoje como Director of DNS Operations. O documento reflete essa perspectiva operacional: avalia o comportamento diante do inesperado, não a quantidade de recursos declarados.

O teste de aceitação deve perguntar se uma nova flag passa, se um tipo desconhecido conserva os mesmos bytes, se TC e OPT chegam completos e se TCP continua TCP. Deve ainda distinguir, por evidência, uma política deliberada de uma deficiência do firmware.

A posterior RFC 8906, de Mark Andrews e Ray Bellis, transforma campos, tipos, versões, opções e flags EDNS inesperados, além de truncamento e TCP, em casos explícitos de teste. O problema antigo deixa de produzir apenas silêncio e passa a gerar comparações reproduzíveis.

A transparência da RFC 5625 não oferece, sozinha, validação, privacidade ou disponibilidade. O operador continua escolhendo upstream, protegendo interfaces e aplicando regras declaradas. O que o proxy não recebe é jurisdição sobre cada significado futuro. Ele cuida do caminho, não possui o protocolo que atravessa esse caminho.

Fontes