Resumo

  • O perfil de Ray Bellis no IETF Datatracker listava dez RFCs em 5 de agosto de 2026, incluindo o RFC 10029, publicado em julho de 2026. Na mesma consulta, o perfil não listava Internet-Drafts ativos. Esse registro é um índice de autoria e atividade documental, não uma prova de invenção exclusiva ou de implantação generalizada. [1]
  • O RFC 5966, publicado em 2010 com Bellis como autor, foi substituído pelo RFC 7766, assinado por cinco autores em 2016. O texto mais recente tornou TCP uma exigência para uma implementação DNS completa de propósito geral e o tratou como transporte válido, não apenas como último recurso depois de UDP. [3] [4]
  • Os RFCs 7828 e 8490 trataram do estado que surge quando conexões DNS persistem. Eles deram nomes e sinais a tempo ocioso, estabelecimento de sessão, rejeição, timeout, encerramento e limites de recursos. Esses mecanismos coordenam comportamento; não garantem capacidade em todos os servidores. [5] [6]
  • O RFC 8906 descreveu a ausência de resposta como um problema operacional. Silêncio pode esconder perda de pacote, filtragem, falta de suporte, limitação de taxa ou erro de implementação. Em condições comuns, uma resposta explícita reduz a adivinhação do cliente. [7]
  • O RFC 9619 preservou a regra prática de uma pergunta principal em uma consulta DNS comum. O RFC 10029, publicado como Proposed Standard em julho de 2026, acrescentou uma opção EDNS para pedir tipos adicionais, informar quais foram processados por completo e voltar a consultas separadas quando necessário. [8] [9]

Uma consulta curta depende de muitas responsabilidades independentes

DNS significa Domain Name System, o sistema que relaciona nomes legíveis por pessoas a informações que máquinas usam para se conectar. Quando um aplicativo precisa abrir um serviço, ele pode pedir um registro A, usado para endereço IPv4, um registro AAAA, usado para endereço IPv6, ou outros dados, como registros HTTPS, que ajudam a preparar uma conexão moderna.

Esse pedido normalmente passa primeiro por um resolvedor. O resolvedor é o componente que procura a resposta em nome do aplicativo. Um resolvedor recursivo pode consultar várias camadas até chegar a servidores autoritativos. Servidor autoritativo, nesse contexto, não significa um governo do DNS inteiro. Significa o servidor que publica os dados oficiais de uma zona específica. Caches podem responder antes de uma nova consulta. Proxies, firewalls, tradutores de endereço, balanceadores de carga e redes de trânsito podem ficar no caminho.

Essa divisão é normal na Internet. O operador do domínio cuida de delegações e dados autoritativos. O operador do resolvedor decide como buscar, repetir e encerrar tentativas. Fabricantes implementam bibliotecas, gateways e servidores. Aplicativos escolhem quanto tempo uma pessoa pode esperar antes de mostrar erro. Nenhum desses participantes controla a rota inteira.

Por isso uma mensagem clara tem valor operacional. Se o servidor responde que o nome não existe, o resolvedor recebeu uma conclusão. Se responde que uma operação não foi implementada, o cliente pode escolher outro método. Se a resposta veio truncada, o cliente entende que precisa de um transporte capaz de carregar mais dados. Mesmo uma negativa pode ser útil, porque preserva uma causa.

O silêncio não preserva causa. Ele obriga o cliente a escolher entre esperar, repetir a mesma tentativa, mudar de servidor, retirar uma extensão, trocar de transporte ou entregar um erro ao aplicativo. Cada escolha consome parte do tempo do usuário e também pode esconder a falha inicial. O resultado final talvez seja uma página carregada, mas a rota pode ter sido lenta, fraca ou dependente de várias correções invisíveis.

O trabalho público associado a Bellis aparece justamente nessas fronteiras. Os documentos não tentam centralizar a operação do DNS. Eles descrevem o que uma parte deve enviar, aceitar, rejeitar, sinalizar, completar ou tentar em seguida, para que sistemas independentes consigam continuar interoperando.

Essa é também uma diferença importante entre registro e soberania operacional. Um RFC registra comportamento comum e oferece uma referência para implementadores. Ele não opera zonas, não abre portas de firewall, não aloca memória e não decide limites locais. A continuidade real nasce quando o registro público encontra código em execução, delegações coerentes, capacidade suficiente e respostas que podem ser classificadas.

TCP deixou de ser apenas um caminho excepcional

Muita gente aprende DNS por uma regra simples: DNS usa UDP, e TCP entra quando a resposta é grande ou quando há transferência de zona. UDP, ou User Datagram Protocol, envia mensagens sem estabelecer uma conexão persistente. Isso pode ser eficiente para perguntas pequenas. TCP, ou Transmission Control Protocol, estabelece uma conexão e permite transportar respostas maiores com controle de entrega, mas exige mais estado, memória e gerenciamento.

A regra simples ajuda a começar, mas pode criar um erro de operação. Se uma equipe trata TCP como um detalhe raro, talvez teste apenas consultas pequenas por UDP. A infraestrutura parece saudável até aparecer uma resposta assinada, maior, truncada, filtrada ou dependente de retransmissão mais confiável.

O RFC 5966 foi publicado em agosto de 2010 como Proposed Standard, com R. Bellis como autor, e tratou de requisitos de implementação para DNS sobre TCP. [3] Ele não deve ser apresentado como a última palavra atual. Em março de 2016, John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin e Duane Wessels publicaram o RFC 7766, que substituiu o RFC 5966. [4]

Essa substituição importa. Um documento anterior pode ter sido necessário para tornar uma prática testável e, ainda assim, ser superado por um texto mais amplo. O fato de RFC 5966 ter sido tornado obsoleto não apaga o registro de Bellis. Também não permite dizer que o texto antigo continua sendo a referência vigente sem mencionar o sucessor.

O RFC 7766 exige que uma implementação DNS completa de propósito geral suporte UDP e TCP. Ele também trata TCP como uma alternativa válida que um resolvedor pode escolher por razões operacionais locais, e não apenas como uma tentativa depois que UDP falha. Quando uma conexão TCP adequada já está aberta, o documento recomenda sua reutilização. [4]

Para um leitor não especialista, o efeito pode ser visto como uma fila de atendimento. UDP é como uma pergunta rápida no balcão. TCP é como abrir uma conversa identificável que pode carregar mais informação. Se a conversa longa é exigida em algumas situações, o serviço não está completo quando só o balcão rápido funciona.

O problema aparece em caminhos intermediários. Um servidor pode aceitar TCP, mas um firewall na frente pode descartar conexões sem avisar. Um resolvedor pode tentar uma resposta grande por UDP, receber uma marcação de truncamento, trocar para TCP e ficar preso em espera. O nome, os dados e o servidor autoritativo podem estar corretos; a experiência do usuário ainda falha porque a rota não preserva o transporte exigido.

O RFC não prova que todos os servidores e produtos cumprem a exigência. Ele oferece uma base para teste. A equipe pode enviar a mesma consulta por UDP e TCP, medir conexão estabelecida, resposta completa, reutilização, encerramento e motivo de falha. A diferença entre rejeição explícita e timeout precisa ficar visível, porque cada uma orienta uma correção diferente.

Esse é um exemplo de continuidade operacional sem comando central. O documento define comportamento esperado. Operadores escolhem capacidade, proteção e políticas de conexão. O valor do padrão está em tornar a escolha verificável por quem opera código real.

Um proxy pode encaminhar a consulta e ainda mudar o sentido

Um proxy DNS recebe perguntas de clientes locais e as encaminha a outro resolvedor. Ele aparece em roteadores domésticos, redes corporativas e equipamentos que tentam simplificar configuração. Para o aplicativo, pode parecer que o proxy é o próprio serviço DNS. Na prática, ele é uma camada que precisa preservar campos, tamanhos, códigos, flags, extensões e transportes.

O RFC 5625, publicado em 2009 com Ray Bellis como autor, oferece diretrizes de implementação para proxies DNS. [2] A fonte sustenta essa autoria e esse escopo. Ela não mostra que todos os gateways seguem as diretrizes nem fornece um ranking de conformidade.

A importância do proxy fica clara quando a consulta deixa de ser trivial. Uma caixa intermediária pode responder corretamente a um A simples e falhar com uma resposta assinada, um tipo desconhecido, uma opção EDNS ou uma conexão TCP. EDNS é um mecanismo de extensão que permite acrescentar capacidades e opções ao DNS sem substituir a pergunta principal. Se o proxy remove o que não entende, troca um erro válido por silêncio ou suporta UDP mas não TCP, o resolvedor pode culpar o servidor errado.

Essa falha não é apenas técnica no sentido estreito. Ela afeta suporte, atendimento e confiança. O usuário diz que o site não abriu. A equipe de aplicação verifica que o servidor web está ativo. O operador de domínio olha a zona e encontra os registros corretos. O problema estava no meio, em uma camada que apagou evidências.

Um teste sério, portanto, não troca apenas nomes. Ele varia tipos conhecidos e desconhecidos, mensagens comuns e EDNS, UDP e TCP, respostas pequenas e truncadas. O objetivo não é obrigar todo equipamento antigo a entender qualquer novidade imediatamente. O objetivo é distinguir "não suportado" de "a informação desapareceu no caminho".

Essa distinção protege o registro de delegação. Delegação é o ato de indicar quais servidores respondem por uma zona. Se a pergunta atravessa um proxy que muda ou perde a resposta, a cadeia de responsabilidade fica turva. A zona pode estar correta, o servidor autoritativo pode estar pronto e, mesmo assim, a rede local pode entregar ao cliente apenas uma espera.

A contribuição atribuível a Bellis aqui deve ficar limitada ao documento público. Fabricantes implementam. Operadores configuram. Redes reais testam. A continuidade depende de todos esses atos, não de uma assinatura isolada no RFC.

Manter conexões abertas é uma negociação sobre recursos

Quando DNS usa TCP com mais frequência, surge uma pergunta que UDP escondia melhor: por quanto tempo uma conexão deve permanecer aberta? Abrir uma conexão para cada consulta pode desperdiçar tempo. Manter todas abertas por tempo indefinido pode esgotar sockets, memória e filas de um servidor movimentado.

O RFC 7828, escrito por Paul Wouters, Joe Abley, Sara Dickinson e Ray Bellis, define a opção edns-tcp-keepalive. [5] O cliente pode informar que deseja manter uma conexão TCP. O servidor pode responder com um tempo ocioso variável, adequado aos seus recursos. Se estiver sem recursos para preservar conexões ociosas, pode sinalizar zero e pedir que o cliente feche depois do trabalho pendente.

O zero é importante porque não é a mesma coisa que desaparecer. Um servidor que sinaliza zero está dizendo algo sobre sua política ou sua condição naquele momento. Um cliente pode encerrar, abrir outra conexão quando precisar e registrar a causa. Uma conexão que simplesmente cai sem sinal cria outra investigação.

O padrão não escolhe uma duração universal. Um pequeno servidor autoritativo, um grande resolvedor público, um site anycast e um servidor sob ataque vivem em ambientes diferentes. O documento define o campo e a interpretação. A decisão de capacidade continua com o operador.

Anycast merece explicação. Nessa técnica, vários locais anunciam o mesmo endereço, e o roteamento escolhe para qual deles o tráfego vai. Ela pode melhorar proximidade e resiliência, mas conexões longas sofrem quando a rota muda e passa a apontar para outro local. O RFC 7828 reconhece que mudanças de topologia podem interromper sessões TCP longas com servidores anycast. [5]

Medi-las exige mais do que contar conexões. Uma equipe deve registrar tempo de estabelecimento, taxa de reutilização, duração ociosa, lado que fechou, valor keepalive anunciado, requisições pendentes, resets e diferenças entre locais. Não é necessário guardar todos os nomes consultados por usuários para entender estados de protocolo. Agregados podem preservar privacidade e ainda mostrar onde o sistema gasta tempo.

Aqui aparece uma linha de realidade operacional. O padrão torna o sinal visível, mas não cria capacidade. Se o servidor anuncia um valor alto e não sustenta a memória correspondente, usuários pagam em falhas. Se anuncia zero de forma permanente por subdimensionamento, a melhoria de reutilização talvez nunca apareça. O registro comum ajuda a nomear o problema; a operação precisa corrigi-lo.

DSO separa conexão, sessão e encerramento

Uma conexão TCP aberta não significa que as duas pontas concordaram com todas as operações de sessão. Para essa camada, o RFC 8490 definiu DNS Stateful Operations, ou DSO, um conjunto de operações DNS com estado sobre sessões persistentes. [6]

O documento tem seis autores, incluindo Bellis. Ele distingue estabelecimento de conexão, estabelecimento de sessão, falha, timeout, operação estabelecida e encerramento. Também define operações iniciais como keepalive, retry delay e preenchimento para privacidade. Cada pedido comunica uma operação primária, e o código de resposta informa sucesso ou falha.

Essa máquina de estados evita uma confusão comum. "A conexão abriu" não quer dizer "a sessão DSO foi aceita". O cliente pode estar conectado e ainda negociando. O servidor pode rejeitar com código. A tentativa pode ultrapassar o tempo limite. O cliente pode continuar com DNS comum em uma conexão sem sessão DSO, dependendo da resposta. [6]

Timeout, em português operacional, é o momento em que um sistema para de esperar porque atingiu um limite definido. Ele não explica sozinho a causa da ausência. No estabelecimento de DSO, porém, ele indica em qual etapa a espera estourou e leva o cliente a abortar a conexão. Esse detalhe muda o diagnóstico.

O RFC não demonstra implantação ampla de DSO. Ele oferece nomes para estados. Esses nomes podem aparecer em logs, testes e revisões de incidente. Uma equipe que vê "sessão rejeitada" tem uma evidência diferente daquela que vê apenas "DNS falhou".

A distinção também protege a responsabilidade local. O IETF pode definir como a sessão é sinalizada. O operador decide limites, política de encerramento, proteção contra abuso e monitoramento. O fabricante decide como o estado é implementado. A continuidade nasce quando essas escolhas são registradas de modo reproduzível.

O silêncio transforma falhas diferentes em uma mesma espera

O RFC 8906, escrito por Mark Andrews e Ray Bellis e publicado em setembro de 2020, aborda diretamente um problema comum em servidores DNS: a falta de comunicação. [7]

Uma consulta bem formada pode ficar sem resposta por várias razões. O pacote pode ter se perdido. Um servidor pode não entender uma opção EDNS. Um firewall pode descartar a mensagem. Um servidor sob ataque pode limitar respostas. Uma implementação quebrada pode ignorar um tipo ou uma flag desconhecida. Do lado do cliente, tudo isso pode parecer apenas relógio correndo.

O documento recomenda que, fora de condições de ataque, servidores de nomes respondam a consultas bem formadas. Ele identifica respostas esperadas para tipos, flags, códigos de operação e consultas TCP desconhecidas ou não suportadas. Também reconhece que um servidor atacado pode precisar descartar pacotes ou limitar respostas. [7]

Essa exceção é essencial. Nenhum padrão útil exige que um operador sacrifique disponibilidade para responder a tudo durante um ataque. O problema é transformar silêncio rotineiro em comportamento normal. Quando isso acontece, clientes legítimos não conseguem distinguir proteção deliberada de falha acidental.

Fallback, ou caminho de retorno, é a alternativa usada quando a opção preferida não funciona. Depois de uma consulta EDNS sem resposta, um resolvedor pode retirar EDNS e tentar de novo. Isso pode proteger o usuário, mas também pode impedir DNSSEC, o mecanismo de assinaturas do DNS, ou alguma extensão recente. A página abre; a capacidade moderna ficou bloqueada e invisível.

O RFC 8906 também liga resposta explícita à delegação. Os registros NS na zona pai indicam quais servidores devem responder pela zona delegada, e a própria zona delegada publica seus NS. O documento recomenda que operadores pais comparem as duas visões. [7] Uma lista desatualizada pode enviar clientes para servidores que não falam mais pela zona.

Esse ponto traz a dimensão de registro. O DNS depende de delegações precisas. O registro, nesse sentido, deve funcionar como livro de referência operacional: quem responde por qual zona, sob quais dados e por quais caminhos. Ele não deve substituir a rede em funcionamento nem transformar uma instituição documental em soberana sobre a disponibilidade local. Se a delegação aponta para um servidor que silencia, o registro deixou de ajudar o resolvedor a localizar responsabilidade.

Uma resposta explícita protege o orçamento de tentativas do cliente. Erro de formato, "não implementado", resposta negativa normal, truncamento claro, recusa TCP limpa e sinal de encerramento por recurso não são equivalentes. Nenhum deles garante sucesso, mas todos carregam mais informação do que ausência total.

Esse benefício alcança equipes de suporte e usuários. Quando tudo se reduz a timeout, cada camada precisa investigar todas as hipóteses. Quando a resposta indica o motivo, a equipe pode decidir se corrige configuração, aumenta capacidade, ajusta firewall, remove delegação obsoleta ou apenas registra que a função não é suportada.

Uma pergunta principal pode pedir dados adicionais sem virar ambiguidade antiga

Mensagens DNS possuem campos de contagem. QDCOUNT é o campo que conta perguntas. O formato histórico parecia permitir mais de uma pergunta, mas os programas não desenvolveram comportamento comum e confiável para consultas com várias perguntas independentes.

O RFC 9619, escrito por Ray Bellis e Joe Abley e publicado em julho de 2024, esclareceu que uma consulta DNS comum normalmente tem uma pergunta. [8] Essa regra estreita a interpretação e reduz uma ambiguidade antiga.

Aplicativos modernos, porém, frequentemente precisam de mais de um tipo para o mesmo nome. Para preparar conexão, um cliente pode querer A, AAAA e HTTPS. Enviar uma consulta separada para cada tipo custa mais idas e vindas e mais trabalho de servidor.

O RFC 10029, escrito por Bellis e publicado em julho de 2026 como Proposed Standard, definiu DNS Multiple QTYPEs. [9] Proposed Standard é um estágio do processo IETF em que uma especificação está publicada para implementação e revisão, mas não deve ser confundida com prova de implantação universal. O mecanismo preserva uma pergunta principal e usa uma opção EDNS para listar tipos adicionais desejados.

A resposta também tem uma opção. Um servidor conforme retorna essa opção para uma solicitação válida, mesmo quando a resposta DNS geral vem truncada. A opção informa quais tipos adicionais foram processados por completo. Se um tipo não coube, teve incompatibilidade de código ou não foi respondido integralmente, ele não deve ser marcado como completo. [9]

O cliente então tem fallback explícito. Se a extensão não é suportada, se há erro de formato ou se algum tipo necessário ficou fora da lista completa, o cliente envia consultas independentes para o que falta. O caminho antigo permanece disponível.

Essa eficiência potencial tem custo. Uma única pergunta combinada pode aumentar trabalho de servidor e tamanho de resposta. DNS também pode ser usado em ataques de amplificação quando o endereço de origem é falsificado. Por isso o RFC 10029 pede limites configuráveis pelo operador, com valores adequados ao ambiente. [9]

A continuidade aqui está em dois lados ao mesmo tempo. O cliente ganha uma tentativa de reduzir consultas. O servidor mantém controle sobre limites. A resposta preserva quais tipos foram completos. O fallback evita excluir servidores antigos. Nada disso prova que a novidade já esteja comum na Internet em 2026; prova apenas que há uma especificação pública para testar.

O registro público mostra revezamento, não propriedade privada

O perfil do IETF Datatracker listava dez RFCs para Ray Bellis na data de consulta. [1] Esse número deve ficar dentro da sua fonte: é uma listagem oficial de documentos associados a ele naquele momento, não uma biografia completa nem uma medida de impacto.

A autoria varia entre os documentos. RFC 5625 e RFC 5966 trazem Bellis como autor. RFC 7766, RFC 7828, RFC 8490, RFC 8906 e RFC 9619 são documentos coletivos. RFC 10029 volta a trazer Bellis como autor, mas continua sendo uma especificação dentro do processo de consenso do IETF. [2] [3] [4] [5] [6] [7] [8] [9]

Essa sequência mostra revezamento. Um texto é substituído por outro. Um mecanismo de transporte recebe experiência acumulada. Um modelo de sessão se conecta ao debate sobre conexões persistentes. Uma regra sobre a quantidade de perguntas prepara o caminho para uma opção que pede tipos adicionais sem ressuscitar ambiguidades antigas.

Essa forma de crédito é mais precisa do que uma narrativa de herói único. Bellis pode ser descrito como autor ou coautor onde os registros o nomeiam. Os documentos também envolvem coautores, grupos de trabalho, revisores, implementadores e operadores. Nenhuma fonte revisada aqui sustenta afirmações sobre motivação privada, emprego atual, resultados comerciais, participação em implantações específicas ou controle individual do DNS.

Também é importante não transformar a publicação de um RFC em prova de resultado. Um requisito normativo é alvo de teste. Um código de resposta é evidência recebida. Uma sessão persistente é estado coordenado. Uma opção Multiple QTYPEs é possibilidade de intercâmbio mais eficiente. A rede real ainda decide se suporta, limita, mede e opera esses comportamentos.

O objeto durável é o registro aberto. Outro engenheiro pode recuperar o texto, comparar versões, ver qual documento substituiu qual, implementar, questionar e medir. Essa abertura combina com a ideia de código em execução como disciplina: a especificação orienta, mas o sistema vivo confirma.

A última palavra fica nos sistemas em funcionamento

Publicar uma especificação não atualiza automaticamente um roteador antigo, não abre TCP em firewall, não adiciona memória a servidor e não conserta delegação fora de sincronia. Também não garante que um resolvedor preserve métricas de fallback ou que um caminho anycast mantenha a mesma sessão por tempo longo.

Novos mecanismos trazem decisões novas. DSO cria estado que precisa ser protegido e monitorado. Multiple QTYPEs pode reduzir várias consultas, mas aumenta o trabalho de uma mensagem única. Limites conservadores protegem o servidor e deixam tipos pendentes. Fallback preserva compatibilidade e pode esconder baixa adoção quando a organização mede apenas sucesso final.

Essas reservas não diminuem o valor dos documentos. Elas mantêm a fronteira correta entre coordenação pública e operação local. O RFC oferece nomes, campos, respostas e estados. A equipe que opera o serviço precisa testar UDP, TCP, EDNS, truncamento, keepalive, DSO, tipos adicionais, delegação e comportamento de erro no caminho real.

Esse é o ponto de continuidade operacional. O serviço continua confiável não porque uma sala ou um registro central declara autoridade, mas porque dados permanecem coerentes, servidores respondem por suas zonas, caminhos exigidos funcionam, limites são visíveis e alternativas foram ensaiadas. O registro comum ajuda a manter unicidade e clareza; a rede em execução revela se a promessa foi cumprida.

Em termos simples, o fio condutor do trabalho documentado de Bellis é uma pergunta: quando uma parte não entende, não completa, limita, encerra ou precisa redirecionar uma operação DNS, a outra parte recebe um fato utilizável ou apenas perde tempo no silêncio? Os RFCs não eliminam todas as falhas. Eles tornam algumas falhas menos idênticas e, portanto, mais corrigíveis.

Fontes

  1. IETF Datatracker, perfil de Ray Bellis.
  2. RFC Editor, RFC 5625: DNS Proxy Implementation Guidelines.
  3. RFC Editor, RFC 5966: DNS Transport over TCP — Implementation Requirements.
  4. RFC Editor, RFC 7766: DNS Transport over TCP — Implementation Requirements.
  5. RFC Editor, RFC 7828: The edns-tcp-keepalive EDNS0 Option.
  6. RFC Editor, RFC 8490: DNS Stateful Operations.
  7. RFC Editor, RFC 8906: A Common Operational Problem in DNS Servers: Failure to Communicate.
  8. IETF Datatracker, RFC 9619: In the DNS, QDCOUNT Is (Usually) One.
  9. IETF Datatracker, RFC 10029: DNS Multiple QTYPEs.