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

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.

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.