Esta questão é muito, muito semelhante a RFC que requer que os servidores DNS respondam a solicitações de domínios desconhecidos , mas imaginei que deveria fazer isso como uma nova pergunta.
Parece que é uma prática padrão para um servidor DNS autoritativo responder com rcode REFUSED a qualquer consulta de um nome de domínio para o qual o servidor não seja autoritativo. Por exemplo:
$ dig @ns1.google.com yahoo.com A | grep status
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53533
Existem alguns comportamentos alternativos que poderiam fazer sentido aqui, a priori:
NXDOMAIN NOERROR (isso é bobo, mas eu o menciono por completo) Existe um RFC ou documento semelhante que diz "você devolverá REFUSED neste caso"?
Eu esperaria ver alguma discussão sobre essa situação em RFC 1034 seção 4.3.1 e 4.3. 2 , mas não sei.
É realmente simples, RFC1035 Seção 4.1.1 RCODE 5
Refused - The name server refuses to perform the specified operation
for policy reasons. For example, a name server may not wish to
provide the information to the particular requester, or a name server
may not wish to perform a particular operation (e.g., zone transfer)
for particular data.
Os administradores do sistema decidiram configurar seu sistema para retornar uma resposta REFUSED ao invés de fazer qualquer outra coisa.
Eu não acredito que exista uma declaração completa nos documentos de padrões (pelo menos não nos RFCs de DNS originais) de como lidar com esse cenário específico.
Dito isso, ao longo dos anos, o consenso tornou-se mais ou menos de que REFUSED é a melhor opção dentre as ferramentas que temos disponíveis.
Vou descrever algumas ideias sobre algumas das diferentes opções abaixo:
Isso é ruim para o operador do servidor autoritativo, pois essa abordagem faria o servidor parecer inoperante, abrindo para cenários em que os servidores recursivos o observaram repetidamente, não respondendo às suas consultas e desistindo completamente, independentemente do QNAME .
Também é ruim do ponto de vista do cliente, pois pode levar à espera até que algum tempo limite expire, em vez de ocorrer rapidamente um erro.
(Eu consideraria essa a pior opção.)
NXDOMAIN não autoritativa Isso não está de acordo com a forma como NXDOMAIN é usado. NXDOMAIN é usado para indicar que você sabe que um nome não existe , não que você não sabe nada sobre o nome .
NOERROR (isso é bobagem, mas eu o menciono por completo) Em primeiro lugar, observarei que a alternativa "referência à raiz" é um caso especial desta.
O argumento contra NXDOMAIN se aplica a NODATA ( NOERROR + SOA na seção de autoridade), bem como com apenas ajustes menores; é um status que é usado para indicar que você sabe que não há tal RRset , não que você não tenha conhecimento .
Além disso, NODATA sugere que você saiba que esse nome existe em algum formato ou forma (por exemplo, pode ter registros de outros tipos ou pode ser um não terminal vazio).
NOERROR indica que a consulta foi considerada válida e respondível, portanto, deve haver alguma forma de resposta. Se esta for uma consulta que não pode ser respondida, NOERROR parece ser um ajuste inadequado.
Esta foi uma maneira muito comum de lidar com isso no passado. O conteúdo da resposta não é útil em si, mas é uma resposta de referência formada de forma válida que pelo menos deixa claro que o servidor consultado não sabe sobre esse nome.
(acho que esta é provavelmente a forma menos boba de NOERROR use neste contexto.)
REFUSED
REFUSED é geralmente considerado a melhor abordagem, indica que o servidor está configurado para não responder a essa consulta. Em geral, um bom ajuste, se não está explicitamente determinado que deve ser usado neste caso particular.
SERVFAIL
Também usado por algumas implementações de servidores.
Menos claro que REFUSED em que não indica claramente que a não resposta é deliberada; SERVFAIL é normalmente usado para erros inesperados encontrados ao processar consultas válidas.
Aqui está uma resposta parcial, começando com esta postagem de blog do DynDNS eu encontrei.
From the nameserver’s perspective, it is being asked to answer a question outside of its configured response-ability (DNS pun!). It has no zone file for that domain name and, therefore, it has nothing to respond with. Following RFC 1035, a conforming nameserver should issue an RCODE 5 (REFUSED) response. This is a refusal because the “the nameserver refuses to perform the specified operation for policy reasons”.
In principle, it should be really strange that a nameserver receives a query for a name for which it is not authoritative. After all, the very act of delegating a nameserver from a parent involves claiming (authoritatively) that the nameservers named by the NS records are the right nameservers. So, historically, many nameservers responded with a referral to the root.
It appears today that this answer is widely scorned by DNS operators (partly because it can be used in amplification attacks), and many nameservers these days will return an error. The error is often RCODE 5 (REFUSED), on the grounds that the nameserver refuses to perform the specified operation for policy reasons. Sometimes, you will see an RCODE 2 (SERVFAIL), for the same reason you see that when a zone is in process of being loaded by a nameserver: the server can’t actually answer the query yet, and does not know whether it ever will be able to do so.
Pesquisando "referência à raiz" apareceu uma publicação do DNS-OARC intitulada "Referências ascendentes consideradas prejudiciais" :
Recently the hosting company ISPrime became the victim of a DNS-based DDoS attack using spoofed source addresses. Some are calling it an amplification attack because the query ". IN NS" is quite small (47 octets) while an upward referral response is a bit larger (256 octets). ... The attack brings an old debate back into the light: What is an authoritative nameserver's appropriate response to a query that cannot be answered? The configuration and/or implementation of some authoritative nameservers causes them to return an upward referral to the root zone. We recommend against this behavior for a number of reasons:
- Upward referrals are generally useless. The resolver that is iterating through the space already knows where to start.
- A proper iterative resolver should consider the upward referral "out of bailiwick" and ignore the data anyway.
- The authoritative nameserver's root zone "hints" may become stale over time if not properly maintained, causing delivery of queries to decommissioned root server addresses.
- Upward referrals are known to cause "referral loops" that result in hundreds of useless queries.
We feel that a REFUSED response code is better than an upward referral. ...
Além disso, no RFC 7719 (publicado em dezembro de 2015), encontramos:
Historically, many authoritative servers answered with a referral to the root zone when queried for a name for which they were not authoritative, but this practice has declined.
Então, "encaminhamento para a raiz" é claramente uma idéia horrível - mas, para ser justo, essa já era minha alternativa "mais tola". Eu ainda não descobri o que seria errado com um NXDOMAIN não autoritativo ou algo semelhante. Eu posso atualizar esta resposta mais tarde.