RFC que requer que os servidores DNS respondam a solicitações de domínio desconhecidas

Question

Meu registrador de domínio e DNS fornecem atualmente ignora as solicitações de DNS para domínios desconhecidos. Por ignorar eu quero dizer buracos negros e nunca responde o que faz com que meus clientes DNS e resolva as bibliotecas para tentar novamente, voltar 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 é bem único, já que outros provedores retornam um RCODE de 5 (RECUSADO):

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
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Retornar REFUSED imediatamente é o IMHO apropriado, em vez de simplesmente descartar a solicitação no chão da sala do servidor.

Quando eu reclamo para o meu provedor sobre seus servidores não estarem respondendo, 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 assim seja.

Perguntas :

• É minha estipulação que, a menos que haja ids de solicitação duplicados ou algum tipo de resposta do DOS, um servidor deve sempre responder à solicitação. Isso está correto?
• Qual 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 fará o backoff e retransmitirá a mesma consulta para o mesmo servidor DNS ou outro servidor. Não só eles estão diminuindo a velocidade dos clientes, mas eles estão fazendo com que a mesma consulta seja feita novamente por seus próprios servidores ou outros, dependendo dos servidores de nomes oficiais e das entradas NS.

Em RFC 1536 e 2308 Eu vejo muitas informações sobre armazenamento em cache negativo por motivos de desempenho e para parar a retransmissão da mesma consulta. Em 4074 eu vejo informações sobre como retornar uma resposta vazia com um RCODE de 0, para que o cliente saiba que não há informações de ipv6 o que deve fazer com que o cliente pergunte sobre A RRs, que é outro exemplo de uma resposta vazia.

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

O problema específico acontece quando eu migro meu domínio (e os registros DNS associados) para seus servidores ou os primeiros X minutos depois que eu registro um novo domínio com o serviço deles. Há uma defasagem entre o tempo em que os servidores de nomes oficiais mudam (o que é muito rápido atualmente) e seus servidores começam a servir meus registros DNS. Durante esse tempo de atraso, os clientes DNS pensam que seus servidores são autoritativos, mas nunca respondem a uma solicitação, mesmo com REFUSED . Eu entendo o atraso que é bom, mas não concordo com a decisão de não responder aos pedidos de DNS. Para o registro, eu entendo como contornar essas limitações em seu sistema, mas ainda estou trabalhando com eles para melhorar seus serviços para estarem mais alinhados com o protocolo DNS.

Obrigado pela ajuda.

    

Answer 1

O conselho de Shane está correto. Não migrar dados de um servidor autoritativo para outro antes de iniciar uma transição é um convite para uma interrupção. Independentemente do que acontece a partir desse momento, esta é uma interrupção iniciada pela pessoa que fez os registros de NS. Isso explica por que mais pessoas não estão fazendo essa reclamação ao seu provedor.

Dito isto, esta ainda é uma pergunta interessante para responder, então vou dar uma olhada nisso.

A funcionalidade básica dos servidores DNS é coberta pelos documentos RFC 1034 e RFC 1035 , que coletivamente formam DST 13 . A resposta deve vir desses dois RFCs ou ser esclarecida por um RFC posterior que o atualize.

Antes de continuarmos, há uma grande armadilha aqui fora do escopo do DNS que precisa ser chamado: ambos os RFCs são anteriores BCP 14 (1997), o documento que esclareceu a linguagem de MAIO, DEVE, DEVE, etc.

• Padrões que foram criados antes desta linguagem ser formalizada podem ter usado linguagem clara, mas em vários casos não. Isto levou a implementações divergentes de software, confusão em massa, etc.
• STD 13 é, infelizmente, culpado de ser interpretativo em vários áreas. Se a linguagem não for firme em uma área de operação, é frequentemente necessário para encontrar um RFC esclarecedor.

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

• The simplest mode for the server is non-recursive, since it can answer queries using only local information: the response contains an error, the answer, or a referral to some other server "closer" to the answer. All name servers must implement non-recursive queries.

...

If recursive service is not requested or is not available, the non- recursive response will be one of the following:

• An authoritative name error indicating that the name does not exist.

• A temporary error indication.

• Some combination of:

  RRs that answer the question, together with an indication whether the data comes from a zone or is cached.

  A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply.

• RRs that the name server thinks will prove useful to the requester.

A linguagem aqui é razoavelmente firme. Não há "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 Standards Track, que altera a funcionalidade. Eu não estou ciente de qualquer palavreado existente para ignorar o pedido e eu diria que o ônus do desenvolvedor é encontrar uma linguagem que refute a pesquisa.

Dado o papel frequente do DNS em cenários de abuso de rede, não se diga que o software de servidor DNS não fornece os botões para diminuir o tráfego no local, o que seria tecnicamente uma violação disto. Dito isto, estes não são comportamentos padrão ou com padrões muito conservadores; exemplos de ambos seriam o usuário exigindo que o software descartasse um nome específico ( rpz-drop. ) ou que certos limites numéricos estivessem sendo excedidos ( max-clients-per-query do BIND). É quase inédito na minha experiência que o software altere completamente o comportamento padrão de todos os pacotes de uma forma que viola o padrão, a menos que a opção aumente a tolerância para produtos mais antigos que violem um padrão. Esse não é o caso aqui.

Em suma, este RFC pode e é violado a critério dos operadores, mas geralmente isso é feito com alguma precisão. É extremamente incomum completamente desconsiderar as seções do padrão conforme seja conveniente, especialmente quando o consenso profissional (exemplo: BCP 16 §3.3 ) erra a favor do fato de ser indesejável gerar carga desnecessária no sistema DNS como um todo. Tentativas desnecessárias de eliminar todas as solicitações para as quais nenhum dado autoritativo está presente são menores do que o desejável com isso em mente.

Atualização:

Por não ser desejável abandonar as consultas no local, o @Alnitak compartilhou conosco que atualmente existe um Esboço do BCP abordando este tópico em detalhes. É um pouco prematuro usar isso como uma citação, mas ajuda a reforçar que o consenso da comunidade se alinha com o que está sendo expresso aqui. Em particular:

Unless a nameserver is under attack, it should respond to all queries directed to it as a result of following delegations. Additionally code should not assume that there isn't a delegation to the server even if it is not configured to serve the zone. Broken delegations are a common occurrence in the DNS and receiving queries for zones that the server is not configured for is not necessarily an indication that the server is under attack. Parent zone operators are supposed to regularly check that the delegating NS records are consistent with those of the delegated zone and to correct them when they are not [RFC1034]. If this was being done regularly, the instances of broken delegations would be much lower.

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

    

por 08.03.2016 / 00:14

3

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

Grosso modo, os passos que você vai dar:

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

2. Verifique se os novos servidores autoritativos estão funcionando corretamente. Consultá-los explicitamente:

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

   O que parece, a partir de sua pergunta, é que eles não estão respondendo a essas perguntas? Mas, você disse "domínios desconhecidos" que não deveria estar neste momento, ele deve estar totalmente configurado em seu sistema (e responder com os registros que você configurou).

   Mas, se você já tiver configurado o domínio em seu sistema, ele deve estar respondendo com os registros corretos neste momento. Se não for, então eles não estão hospedando a zona corretamente, e você deve gritar com eles; se ele responde ou não a um domínio que não tenha configurado, deve ser irrelevante. (Se ainda estou de alguma forma sentindo falta do que você está dizendo, por favor me avise).

3. Troque os servidores de nomes autoritativos por seu registrador de domínio (whois), deixando o antigo provedor de DNS em funcionamento até que o tráfego não esteja mais ocorrendo (dê pelo menos 24 horas).

Se o novo provedor absolutamente não puder ter os registros preenchidos antes de você fazer a mudança, a forma como eles respondem realmente não importará - apontar os usuários para uma autoridade que recusa completamente a consulta acarretará inatividade para seu domínio da mesma forma que se você não obtivesse resposta alguma.

    

por 07.03.2016 / 21:59

Tags protocol domain-name-system rfc

Comando Powershell Switch com vários valores Em um sistema moderno, usar a compactação de disco me proporcionará melhor desempenho geral?

user contributions licensed under cc by-sa 3.0 with attribution required.

SobreLinux

Answer 2

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

Grosso modo, os passos que você vai dar:

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

2. Verifique se os novos servidores autoritativos estão funcionando corretamente. Consultá-los explicitamente:

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

   O que parece, a partir de sua pergunta, é que eles não estão respondendo a essas perguntas? Mas, você disse "domínios desconhecidos" que não deveria estar neste momento, ele deve estar totalmente configurado em seu sistema (e responder com os registros que você configurou).

   Mas, se você já tiver configurado o domínio em seu sistema, ele deve estar respondendo com os registros corretos neste momento. Se não for, então eles não estão hospedando a zona corretamente, e você deve gritar com eles; se ele responde ou não a um domínio que não tenha configurado, deve ser irrelevante. (Se ainda estou de alguma forma sentindo falta do que você está dizendo, por favor me avise).

3. Troque os servidores de nomes autoritativos por seu registrador de domínio (whois), deixando o antigo provedor de DNS em funcionamento até que o tráfego não esteja mais ocorrendo (dê pelo menos 24 horas).

Se o novo provedor absolutamente não puder ter os registros preenchidos antes de você fazer a mudança, a forma como eles respondem realmente não importará - apontar os usuários para uma autoridade que recusa completamente a consulta acarretará inatividade para seu domínio da mesma forma que se você não obtivesse resposta alguma.