5

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.

Community
  • 1
Quuxplusone
  • 191
  • 1
  • 2
  • 12
  • REFUSED makes it very obvious to the client that there is a problem that needs to be fixed (generally at their end). All the other "alternatives" you list vary in hostility from somewhat annoying to actively trying to break the net. They don't make it clear that a problem exists, and thus potentially allow the problem to exist forever. – Michael Hampton Jan 18 '18 at 01:29
  • NXDOMAIN does not make sense, that would be claiming that you have the knowledge that the name does not exist, while in reality you do not know anything about it. – Håkan Lindqvist Jan 18 '18 at 08:29
  • Standard security best practice today for anonymous and unauthenticated requests is to return REFUSED / DENY / ERROR / etc. with no additional information. The job of the RFCs is to define the interfaces for services and not define the policy of implementations. If you have ever been to an RFC meeting, you will quickly learn that getting an RFC approved is a difficult long process. Adding opinions, policies, attitudes to RFCs would make them impossible to get thru the system. – John Hanley Jan 18 '18 at 23:33
  • @JohnHanley: It sounds like you're talking about replying `REFUSED` in order to avoid running an open resolver (a recursive resolver that responds to "unauthenticated" queries). My question was specifically about authoritative nameservers, which AFAIK don't have the same concept of "authorization" or "authentication" as a recursive resolver. Authoritative nameservers expect queries from "anonymous" machines as a matter of course. — Re "opinions, policies, attitudes," see the definitions of the words "SHOULD" and "RECOMMENDED" in [RFC 2119](https://tools.ietf.org/html/rfc2119). :) – Quuxplusone Jan 18 '18 at 23:47
  • There are numerous cases where SHOULD and RECOMMENDED are used in RFCs. In some cases you cannot design an interface or service without them. However, my point is that unless it is REQUIRED to return a specific value, the RFCs allow implementors to chose their own implementations. One could argue that authoritative DNS server only need to return a response for domain names that it knows about and completely ignore other requests. Yes, I have read the papers where it is recommended to return a response. The real world often has different goals than the RFCs. – John Hanley Jan 18 '18 at 23:52

3 Answers3

5

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.

user9517
  • 114,104
  • 20
  • 206
  • 289
  • 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 Jan 17 '18 at 21:50
  • 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](https://books.google.com/books?id=nFdOG5JxWZoC&pg=PA85&dq=%22everybody's+got+to+be+somewhere%22) 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 Jan 17 '18 at 21:56
5

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.

Community
  • 1
Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • 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... – Quuxplusone Jan 18 '18 at 19:25
  • @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. – Håkan Lindqvist Jan 18 '18 at 19:57
  • 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. :) – Quuxplusone Jan 18 '18 at 20:06
  • 1
    @Quuxplusone Yes, both forms of negative responses (NXDOMAIN and NODATA) have the relevant SOA record in the authority section. – Håkan Lindqvist Jan 18 '18 at 20:10
  • There is an Internet Draft for this (https://tools.ietf.org/html/draft-sullivan-dnsop-refer-down-00) last year (2017) but it didn't get any traction and has expired. – Alex Dupuy Nov 08 '18 at 15:49
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.

Community
  • 1
Quuxplusone
  • 191
  • 1
  • 2
  • 12