Please See Below: Use Only Downward Referrals in the DNS

The Domain Name System (DNS) divides parts of the domain name space "into units called 'zones'" (, Section 2.4). The answers for data in these zones are (ultimately) provided by authoritative servers. In the Internet context, for any given query, there is a set of authoritative servers that can provide an authoritative answer in response to that query. Sometimes, however, a server receives a query for which it is not authoritative. If such a server does not offer recursion, the server might return a response that refers to another set of servers on the Internet. This response is called a "referral". There are two categories of referral response. One of them indicates a delegation in the DNS, and is a basic part of how the DNS functions. Without such delegation responses, the distributed nature of the DNS is impossible. They may be thought of as "downward" referrals because they refer to a zone somewhere beneath the zone for which the server is authoritative. Other referrals are for zones where the server is neither authoritative for the zone of the QNAME, nor for any zone that might be an ancestor of the zone containing the QNAME. These referrals might be thought of as "off-tree" referrals, because the server is not authoritative for any part of the tree containing the QNAME. Historically, authoritative servers that received an off-tree query would reply with an "upward referral", usually to the root zone; these were sometimes called a "root referral". Such referrals have turned out to be undesirable in practice. This memo recommends that servers not provide upward referrals, and instead should respond to such queries in some other way.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Unfamiliar DNS-related terms are likely to be found in RFC 7719 , and the reader is assumed to be familiar with that vocabulary.

Referrals are defined as part of the algorithm for a name server (, section 4.3.2, henceforth "the algorithm"). Referrals only happen when the RD bit is clear in the query or the server does not offer recursion (or both). There are different possible interpretations of the algorithm; one's interpretation will affect which kinds of referral one thinks acceptable. A referral contains an empty answer section. It contains the NS RRset for the referred-to zone in the authority section. It may contain RRs that provide addresses in the additional section. The AA bit is clear.

The first kind of referral is downward, and is uncontroversial. Step 2 of the matching algorithm evaluates whether the name server is authoritative for some zone that is an ancestor for the QNAME. (If the QNAME exactly matches, then that zone is the "ancestor". This is a slightly awkward usage of "ancestor", but makes sense due to the distinction between a zone and the matching owner name inside the zone.) If there is such a zone, then the algorithm moves to step 3; otherwise, it moves to step 4. In step 3, the server matches label by label in the zone until matching terminates. Step 3(b) of the matching algorithm says, "If a match would take us out of the authoritative data, we have a referral. This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone." Such a referral is called "downward" because the referral is of necessity to a part of the namespace beneath the zone for which the server is generating a response. In other words, if the server is authoritative for the zone example.com, the referral needs to be to the NS records of some subordinate zone in the domain name space. Downward referrals are necessary for the DNS to function. They are the mechanism by which delegation happens.

The second kind of referral is often called an "upward" referral, because it is often a referral to the name servers for the root zone (perforce above everything else in the domain name space), though in principle the referral could be elsewhere in the domain name space. Step 4 of the algorithm says, "If there was no delegation from authoritative data, look for the best one from the cache, and put it in the authority section." Returning this kind of referral under normal operational conditions is somewhat more controversial than a downward referral, because it is not clear that it is necessary for the operation of the DNS. There are only two cases where upward referrals are possible: The server offers recursive service, and it cannot provide an authoritative answer or a downward referral, but the query was received with the RD bit clear. The server does not offer recursive service, and it cannot provide either an answer or a downward referral in response to the query. The first of these is plainly required by step 4 of the algorithm, and should therefore be uncontroversial. In normal operation, however, this case appears to be unusual. A resolver that was using such a server for full-service DNS resolution would normally query with the RD bit set. A resolver that did not expect recursion would likely only send a QNAME for which the server could provide an authoritative answer or a downward referral; it is unclear why the query would be sent to the server at all otherwise. Such queries are known to occur sometimes, for example when troubleshooting, but they do not appear to be normal according to the protocol. The second case is controversial because the server, which only provides authoritative answers, must somehow have some data in a cache in order to return anything in the authority section. The controversy arises because of the question of whether the server ought to have such data. This amounts to a question of whether a server that only provides authoritative answers should ever have a cache. On the one hand, it would seem that such a server should not have a cache, because it does not have a resolver side that populates such a cache. Moreover, the SBELT structure (see , section 5.3.2) is defined only for resolvers and not for servers. So a server that only provides authoritative answers has no reason even to have configured in the SBELT structure a list of servers from which to start (in resolvers, this is often the "root hints" file). On the other hand, there is no requirement that a given name server should not provide both authoritative service and recursive service. Moreover, even a server that provides no recursive service to others may need to perform resolution for its own purposes, and therefore might have need of the SBELT structure. So, depending on one's reading of the algorithm, either upward referrals should not be returned from such a server and are a sign of misconfiguration, or else they will be a normal part of operation. Upward referrals, and particularly root referrals, were once regarded as a useful mechanism to indicate lame delegation . That use turned out to create some difficulties (see , below).

Upward referrals have some negative consequences. The most obvious of them is that they are not in-domain records, and therefore they should not be accepted in any case according to RFC 5452 , section 6. This means that an upward referral response is just extra traffic, because the querying resolver will need to find those records from an authoritative source anyway. Moreover, upward referral response messages can be considerably larger than the query message that causes them, making them a useful amplifier when used in reflector attacks . Upward referrals can be part of a referral loop, and the algorithm does not specify how or when to terminate such a loop. The use of upward referrals to indicate lame delegations exhibits this weakness.

It is possible for a server to send some other response than an upward referral, when an upward referral might have been generated under the algorithm. There are several alternatives, each of which has advantages and disadvantages.

A name server that had no information at all in a cache (including the SBELT structure) would complete step 4 of the algorithm having added nothing to the authority section in the response. It would exit step 6 of the algorithm having created an empty response (except for the query that was copied from the original query message). This is a type 3 NODATA response . A disadvantage of returning such a message is that it is unlikely to cause the query source to stop querying the nameserver for that name, because type 3 NODATA responses are not cached (see , section 5).

RCODE 2, Server Failure, indicates that a server cannot process the query due to a problem with the name server. Some operators adopt the position that the name server would normally provide an upward referral, except that it has been configured not to. Therefore, the server can return RCODE 2. Others argue, however, that there is nothing wrong with the server; and that, moreover, the use of RCODE 2 in DNSSEC (see ) means that this RCODE is already overloaded enough. Some interpretations of RCODE 2 by resolvers invites subsequent retries to the same server, which may not always be desirable.

RCODE 3, Name Error or NXDOMAIN, indicates that the domain name does not exist. Some operators use RCODE 3 instead of producing upward referrals. But since RCODE 3 is supposed to be "[m]eaningful only for responses from an authoritative name server" ( section 4.1.1) and since by definition the upward referral can only happen in a case where the name server is not authoritative, this use appears to be inconsistent with the protocol.

RCODE 5, Refused, indicates that the server "refuses to perform the specified operatio for policy reasons." (, section 4.1.1) Some operators adopt a policy of refusing to perform upward referrals, and so return RCODE 5 to queries that would otherwise cause such referrals. There are some resolvers, however, that interpret RCODE 5 to mean that the resolver itself, rather than the query sent, is what causes the Refused response. Those resolvers will not attempt to query the server again (or not for some period of time), running the risk of outages in domains for which the server is authoritative and would provide a response.

A name server that only provides authoritative service SHOULD NOT return upward referrals under any circumstances. Such a name server SHOULD provide either RCODE 2 or RCODE 5 in response. A name server MUST NOT return RCODE 3 except for names for which it can provide authoritative answer that the name does not exist. A name server that provides recursive service MAY provide upward referrals when replying to a query with the RD bit clear, or it MAY refuse to provide upward referrals just as though it provided only authoritative service. Operators should note that upward referrals might provide a modest troubleshooting advantage for recursive servers, but this should be weighed against the advantages of removing upward referrals as one of the available tools of attackers on Internet infrastructure.