RFC que exige que os servidores DNS respondam a solicitações de domínio desconhecido

No momento, meu registrador de domínio e DNS fornecem ignora solicitações de DNS para domínios desconhecidos. Por ignorar, quero dizer buracos negros e nunca responde, o que faz com que meus clientes DNS e bibliotecas de resolvedores tentem novamente, recuem e, finalmente, o tempo limite.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Ao pesquisar outros serviços populares de nomes de domínio, vejo que esse comportamento é bastante exclusivo, já que outros provedores retornam um RCODE 5 (REFUSED):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Todos retornam algo como o seguinte:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

ou

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Retornar REFUSEDou NXDOMAINimediatamente é apropriado IMHO, em vez de apenas soltar a solicitação no andar da sala do servidor.

Quando eu reclamo com o meu provedor sobre seus servidores não responderem, eles me pedem para citar o RFC que seus servidores estão violando. Eu sei que é estranho que eles estejam me pedindo para provar que seus servidores devem responder a todos os pedidos, mas que seja.

Perguntas :

• É minha estipulação de que, a menos que haja IDs de solicitação duplicados ou algum tipo de resposta do DOS, um servidor sempre deve responder à solicitação. Isso está correto?
• Que RFC e seção específica devo citar para apoiar minha estipulação?

Para mim, é ruim não responder a uma consulta DNS. A maioria dos clientes recua e retransmite a mesma consulta para o mesmo servidor DNS ou outro servidor. Eles não apenas diminuem a velocidade dos clientes, mas também fazem com que a mesma consulta seja feita novamente por seus próprios servidores ou por outros servidores, dependendo dos servidores de nomes autoritários e das entradas NS.

Nas RFC 1536 e 2308 , vejo muitas informações sobre cache negativo por motivos de desempenho e para interromper a retransmissão da mesma consulta. Em 4074 , vejo informações sobre o retorno de uma resposta vazia com um RCODE de 0, para que o cliente saiba que não há informações de ipv6 que devam fazer com que o cliente pergunte sobre RRs, que é outro exemplo de resposta vazia.

Mas não consigo encontrar uma RFC que diga que um servidor DNS deve responder a uma solicitação, provavelmente porque está implícita.

O problema específico ocorre quando migro meu domínio (e os registros DNS associados) para seus servidores ou nos primeiros X minutos após registrar um novo domínio em seu serviço. Há um atraso entre o tempo em que os servidores de nomes com autoridade mudam (o que é bem rápido hoje em dia) e seus servidores começam a exibir meus registros DNS. Durante esse período de atraso, os clientes DNS acham que seus servidores têm autoridade, mas nunca respondem a uma solicitação - mesmo com um REFUSED. Entendo o atraso, o que é bom, mas discordo da decisão de não responder às solicitações de DNS. Para o registro, eu entendo como contornar essas limitações em seu sistema, mas ainda estou trabalhando com elas para melhorar seus serviços e estar mais alinhadas com o protocolo DNS.

Obrigado pela ajuda.

Editar:

Alguns meses depois de postar isso e acompanhar o meu provedor, eles mudaram seus servidores para retornar NXDOMAINpara domínios desconhecidos.

O conselho de Shane está correto. A falha na migração de dados de um servidor autoritário para outro antes de iniciar uma transição é um convite para uma interrupção. Independentemente do que acontecer a partir desse momento, essa interrupção é iniciada pela pessoa que balançou os registros do NS. Isso explica por que mais pessoas não estão fazendo essa reclamação ao seu provedor.

Dito isto, essa ainda é uma pergunta interessante a ser respondida, então vou dar uma olhada.

A funcionalidade básica dos servidores DNS é coberta pelos documentos RFC 1034 e RFC 1035 , que formam coletivamente STD 13 . A resposta deve vir dessas duas RFCs ou ser esclarecida por uma RFC posterior que a atualiza.

Antes de continuarmos, há uma enorme armadilha aqui fora do escopo do DNS que precisa ser destacada: ambas as RFCs são anteriores ao BCP 14 (1997), o documento que esclareceu o idioma de MAIO, DEVE, DEVE, etc.

• Padrões que foram criados antes da formalização deste idioma PODEM ter usado linguagem clara, mas em vários casos não. Isso levou a implementações divergentes de software, confusão em massa etc.
• Infelizmente, a DST 13 é culpada de ser interpretativa em várias áreas. Se o idioma não for firme em uma área de operação, é frequentemente necessário encontrar uma RFC esclarecedora.

Com isso fora do caminho, vamos começar com o que a RFC 1034 §4.3.1 tem a dizer:

• O modo mais simples para o servidor é não recursivo, pois ele pode responder a consultas usando apenas informações locais: a resposta contém um erro, a resposta ou uma referência a outro servidor "mais próximo" da resposta. Todos os servidores de nomes devem implementar consultas não recursivas.

...

Se o serviço recursivo não for solicitado ou não estiver disponível, a resposta não recursiva será uma das seguintes:

• Um erro de nome autoritário indicando que o nome não existe.

• Uma indicação de erro temporária.

• Alguma combinação de:

  RRs que respondem à pergunta, juntamente com uma indicação se os dados vêm de uma zona ou estão em cache.

  Uma referência a servidores de nomes que possuem zonas que são ancestrais mais próximas do nome do que o servidor que está enviando a resposta.

• RRs que o servidor de nomes considera úteis para o solicitante.

A linguagem aqui é razoavelmente firme. Não existe "deveria ser", mas um "será". Isso significa que o resultado final deve ser 1) definido na lista acima ou 2) permitido por um documento posterior na faixa de padrões que altera a funcionalidade. Eu não estou ciente de qualquer palavreado existente por ignorar a solicitação e eu diria que o ônus é do desenvolvedor encontrar a linguagem que desaprova a pesquisa.

Dada a freqüente função do DNS em cenários de abuso de rede, não se deve dizer que o software do servidor DNS não fornece os botões para eliminar seletivamente o tráfego no chão, o que tecnicamente seria uma violação disso. Dito isto, esses não são comportamentos padrão ou com padrões muito conservadores; exemplos de ambos seriam o usuário que exige que o software solte um nome específico ( rpz-drop.) ou certos limites numéricos estão sendo excedidos (BINDs max-clients-per-query). É quase inédito na minha experiência que o software altere completamente o comportamento padrão de todos os pacotes de uma maneira que viole o padrão, a menos que a opção seja aquela que aumente a tolerância a produtos antigos que violem um padrão. Esse não é o caso aqui.

Em suma, essa RFC pode e é violada a critério dos operadores, mas geralmente isso é feito com algum tipo de precisão. É extremamente incomum desconsiderar completamente as seções do padrão como conveniente, especialmente quando o consenso profissional (por exemplo: BCP 16 §3.3 ) erra a favor de ser indesejável gerar carga desnecessária no sistema DNS como um todo. Tentativas desnecessárias de descartar todas as solicitações para as quais não existem dados autoritativos são menos do que desejáveis ​​com isso em mente.

Atualizar:

Por mais que seja indesejável soltar consultas no chão, a @Alnitak compartilhou conosco que existe atualmente um Rascunho de BCP abordando esse tópico em detalhes. É um pouco prematuro usar isso como uma citação, mas ajuda a reforçar que o consenso da comunidade está alinhado com o que está sendo expresso aqui. Em particular:

A menos que um servidor de nomes esteja sob ataque, ele deve responder a todas as consultas direcionadas a ele como resultado das seguintes delegações. Além disso, o código não deve assumir que não há uma delegação para o servidor, mesmo que não esteja configurado para atender à zona. Delegações desfeitas são uma ocorrência comum no DNS e o recebimento de consultas para zonas nas quais o servidor não está configurado não é necessariamente uma indicação de que o servidor está sob ataque. Os operadores da zona pai devem verificar regularmente se os registros NS delegantes são consistentes com os da zona delegada e corrigi-los quando não estiverem [RFC1034]. Se isso fosse feito regularmente, as instâncias de delegações interrompidas seriam muito menores.

Esta resposta será atualizada quando o status deste documento for alterado.

Ao mover o DNS autoritativo de um domínio para um novo provedor, você deve sempre (sempre!) Testar explicitamente o novo provedor (e garantir que eles estejam enviando registros precisos e configurados) antes de alterar as informações de registro de domínio (whois) para apontar para os novos servidores DNS autoritativos.

Aproximadamente, as etapas a serem seguidas:

1. Configure tudo no novo provedor DNS. Você deve criar e preencher todas as zonas.

2. Verifique se os novos servidores autorizados estão funcionando corretamente. Consulte-os explicitamente:

   dig @new-ns.example.com mydomain.com
   

   Parece que, com a sua pergunta, eles não estão respondendo a essas consultas? Mas você disse que "domínios desconhecidos", que não deveriam estar neste momento, devem estar totalmente configurados em seus sistemas (e respondendo com os registros que você configurou).

   Mas, se você tiver já configurado o domínio em seu sistema, ele tem que estar respondendo com os registros corretos neste momento. Caso contrário, eles não estão hospedando a zona adequadamente e você deve gritar com eles; se responde ou não a um domínio que não configurou deve ser irrelevante. (Se ainda estiver perdendo o que você está dizendo, entre em contato).

3. Alterne os servidores de nomes com o seu registrador de domínio (whois), deixando o antigo provedor DNS em funcionamento até que o tráfego não seja mais atingido (aguarde pelo menos 24 horas).

Se o novo provedor não puder absolutamente preencher os registros antes de você fazer a troca, a forma como eles responderão realmente não importará - apontar os usuários para uma autoridade que se recusa completamente à consulta resultará em tempo de inatividade para o seu domínio da mesma forma como se você estivesse não obtendo resposta alguma.