What RFC encourages DNS servers to reply REFUSED to queries for unknown domains?

13,114

Solution 1

It's simple really, RFC1035 Section 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.

The administrators of the system have decided to configure their system to return a REFUSED response rather than do anything else.

Solution 2

I do not believe that there is a outright statement in the standards documents (at least not the original DNS RFCs) of how to deal with this particular scenario.
That said, over the years the consensus has more or less become that REFUSED is the best option out of what tools we have available.

I'll outline some thoughts on some of the different options below:

The options outlined in the question

Blackhole the query entirely

This is bad for the operator of the authoritative server as this approach would make the server appear to be down, opening for scenarios where recursing servers have observed it repeatedly not answering their queries and give up on it entirely, regardless the QNAME.

It's also bad from the client perspective as it may lead to waiting until some timeout expires rather than quickly getting an error.

(I would consider this the worst option.)

Return a non-authoritative NXDOMAIN response

This is not in line with how NXDOMAIN is otherwise used. NXDOMAIN is used to indicate that you know that a name does not exist, not that you do not know anything about the name.

Return a non-authoritative NOERROR response (this is silly, but I mention it for completeness)

First of all, I'll note that the "referral to the root" alternative is a special case of this one.

The argument against NXDOMAIN applies to NODATA (NOERROR + SOA in authority section) as well with only minor adjustment; it's a status which is used to indicate that you know that there is no such RRset, not that you lack knowledge.
Additionally, NODATA suggests that you know that this name exists in some shape or form (eg, it may have records of other types or it may be an empty non-terminal).

NOERROR indicates that the query was considered valid and answerable, so there should be some form of answer. If this a query that cannot be answered, NOERROR seems like a bad fit.

Return a canned referral to the root nameservers (this is even sillier)

This was a very common way of dealing with this in the past. The contents of the answer are not useful per se but it is a validly formed referral response that at least makes it clear that the queried server doesn't know about that name.

(I think this is probably the least silly form of NOERROR use in this context.)

Other options

Status REFUSED

REFUSED is generally considered the best approach, indicates that the server is configured not to answer this query. Overall a good fit, whether or not it's not explicitly mandated that it must be used in this particular case.

Status SERVFAIL

Also used by some server implementations.
Less clear than REFUSED in that it doesn't clearly indicate that the non-answer is deliberate; SERVFAIL is normally used for unexpected errors encountered when processing valid queries.

Solution 3

Here's a partial answer, starting with this DynDNS blog post I found.

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.

Googling for "referral to the root" turned up a publication of the DNS-OARC titled "Upward Referrals Considered Harmful":

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. ...

Also, in RFC 7719 (published December 2015) we find:

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.

So, "referral to the root" is clearly a horrible idea — but in fairness, that was already my "silliest" alternative. I have not yet figured out what would be wrong with a non-authoritative NXDOMAIN or the like. I might update this answer later.

Share:
13,114

Related videos on Youtube

Quuxplusone
Author by

Quuxplusone

Updated on September 18, 2022

Comments

  • Quuxplusone
    Quuxplusone almost 2 years

    This question is very very similar to RFC that requires DNS servers to respond to unknown domain requests but I figured I ought to ask it as a new question.

    It appears that it is standard practice for an authoritative DNS server to respond with rcode REFUSED to any query for a domain name for which the server is not authoritative. For example:

    $ dig @ns1.google.com yahoo.com A | grep status
    ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53533
    

    There are a few alternative behaviors that could make sense here, a priori:

    • Blackhole the query entirely
    • Return a non-authoritative NXDOMAIN response
    • Return a non-authoritative NOERROR response (this is silly, but I mention it for completeness)
    • Return a canned referral to the root nameservers (this is even sillier)

    Is there an RFC or similar document that says "thou shalt return REFUSED in this case"?

    I'd expect to see some discussion of this situation in RFC 1034 section 4.3.1 and 4.3.2, but I don't.

  • Quuxplusone
    Quuxplusone over 6 years
    Yes, I know that the system is configured to reply REFUSED to out-of-zone domain names! What I want to know is, what RFC suggests or mandates this behavior? RFC 1035 doesn't say anything about it as far as I can tell. Where is this behavior recommended, and/or why do authoritative-server vendors implement it by default (as opposed to one of the alternatives I listed in my question)?
  • Quuxplusone
    Quuxplusone over 6 years
    To elaborate/carp even further... Your answer is "Because the system has decided to do this, rather than do anything else." That's not an answer, it's just a paraphrase of the old joke about the guy found hiding in the closet who says "Hey, everyone's got to be somewhere..." The point of the husband's question in that case was to know why the guy is in the closet instead of any of the infinite number of other places he could be. "Everyone's got to be somewhere" is a non-answer.
  • Quuxplusone
    Quuxplusone over 6 years
    Thanks! By "non-authoritative NOERROR response," I meant what is also called a NO DATA response — no answer and no referral but also no error. It would be like saying, "I don't have any such RRs for that name (but notice that I didn't set the AA bit, so there's some reason you shouldn't trust me, whatever that means)." From this answer and your comment on the question, I am beginning to infer that the AA bit is not as relevant as I had originally been thinking...
  • Håkan Lindqvist
    Håkan Lindqvist over 6 years
    @Quuxplusone I added NODATA, even though it's rather close to the NXDOMAIN answer. As for the AA flag, it is relevant in one way, but it doesn't change the meaning of the status codes.
  • Quuxplusone
    Quuxplusone over 6 years
    Ah, NODATA requires that the response contain an appropriate SOA record? Well, in this scenario, we're assuming that the server isn't authoritative for the qname, which implies that it doesn't have any such SOA record to begin with. I'll have to study further the subtle distinctions between these various "NO" responses, just to find out what kinds of responses would even be possible in this scenario. :)
  • Håkan Lindqvist
    Håkan Lindqvist over 6 years
    @Quuxplusone Yes, both forms of negative responses (NXDOMAIN and NODATA) have the relevant SOA record in the authority section.
  • Alex Dupuy
    Alex Dupuy over 5 years
    There is an Internet Draft for this (tools.ietf.org/html/draft-sullivan-dnsop-refer-down-00) last year (2017) but it didn't get any traction and has expired.