Peter Koch wrote:
No, this sentence describes a DNS entity that is (in the historical terminology) master or slave for one or more zones (i.e. an "authoritative name server"), yet supports recursive querying (i.e. an "iterative resolver"). It's a combination of two different roles in a single entity. I think the wording is fine as it stands.Please clearly state to the mailing list whether you support or oppose
this draft going to the IESG.
While I consider this a very valuable document which could serve implementers of resolvers and the stability of the DNS as a whole, here are some remarks and questions, which make me think the document is not yet ready for publication.
domain (TLD) name servers. In some cases we recommend minor
additions to the DNS protocol specification and corresponding changes
in iterative resolver implementations to alleviate these unnecessary
This promise would probably not warrant the BCP but instead the standards track. However, as far as I understood the recommendations they are all guidelines for resolver implementors and (recursive) server operators, so BCP is OK. However, I'd suggest the wording be changed to reflect that the standard itself, i.e. the on-the-wire protocol, remains unchanged. These are guidelines.
rate. Some of the changes recommended affect the core DNS protocol
specification, described principally in RFC 1034 [2], RFC 1035 [3]
and RFC 2181 [4].
Since I may have missed those changes, could they please be clearly identified?
answer questions about certain zones authoritatively. Often called a
"recursive name server" or a "caching name server", it is in fact an
iterative resolver combined with an authoritative name server.
Shouldn't that read 'a non-authoritative name server', since the cache fed by the iterative resolver serves non-auth data?
There's nothing wrong with doing explicit type NS queries in the course of troubleshooting. Please make sure that any language deprecating explicit NS type queries makes clear that it only applies to the generation of such queries as part of the regular resolution process.2.1 Aggressive requerying for delegation information
There can be times when every name server in a zone's NS RRset is
unreachable (e.g., during a network outage), unavailable (e.g., the
name server process is not running on the server host) or
... or the host does not exist (name doesn't resolve) ...
For this query of the parent zone to be useful, the target zone's
entire set of name servers would have to change AND the former set of
name servers would have to be deconfigured or decommissioned AND the
delegation information in the parent zone would have to be updated
with the new set of name servers, all within the TTL of the target
zone's NS RRset. We believe this scenario is uncommon:
administrative best practices dictate that changes to a zone's set of
name servers happen gradually when at all possible, with servers
removed from the NS RRset left authoritative for the zone as long as
possible. The scenarios that we can envision that would benefit from
the parent requery behavior do not outweigh its damaging effects.
Explicit "NS" queries should never happen (there were some implicit assumptions in this direction during the discussion of wildcard NS RRs), but there are situations where some requery can be justified:
1) When the NS-RRset in the parent zone is larger than that sent authoritatively from within the zone, additional information may be discovered. This is a configuration problem, of course, but is not too uncommon.
2) More importantly, consider a cache content like this:
example.com. NS dns.example.com. NS dns.example.net. dns.example.net. A 192.0.2.42
The dns.example.com A RR has expired. Now, if dns.example.net is not available, the zone is 'non-responsive'. To learn the address of dns.example.com. there's no other way than to make use of the necessary glue RR present in the COM zone, so there is justification for going one step up. Another recommendation following from this could be that the address records of nameservers in or below the zone served should not have TTLs lower than the NS RRs.
2.1.1 Recommendation
An iterative resolver MUST NOT send a query for the NS RRset of a
non-responsive zone to any of the name servers for that zone's parent
zone. For the purposes of this injunction, a non-responsive zone is
defined as a zone for which every name server listed in the zone's NS
RRset:
1. is not authoritative for the zone (i.e., lame), or,
2. returns a server failure response (RCODE=2), or,
3. is dead or unreachable according to section 7.2 of RFC 2308 [5].
This recommendation now can be adjusted accordingly. Explicit NS type queries can be recommended against reagrdless of the responsiveness of the zone. They have no place in the resolution process, do they?
Strongly agreed. SOA and zone apex are *not* interchangeable terms. This is one of my pet peeves and I'm surprised I didn't notice it in my previous readings of this ID.2.2.1 Recommendation
Iterative resolvers SHOULD cache name servers that they discover are
s/cache name servers/cache the status of name servers/;
not authoritative for zones delegated to them (i.e. lame servers).
Lame servers MUST be cached against the specific query tuple <zone
name, class, server IP address>. Zone name can be derived from the
owner name of the NS record that was referenced to query the name
server that was discovered to be lame. Implementations that perform
lame server caching MUST refrain from sending queries to known lame
servers based on a time interval from when the server is discovered
to be lame. A minimum interval of thirty minutes is RECOMMENDED.
In general I support this recommendation. Here's a corner case:
dns.example.com is delegated (and detected) lame example.com but
is authoritative for sub.example.net
During resolving www.sub.example.net dns.example.com must be skipped but upon receipt of the referral containing the reference to dns.example.com it should be eligible again. The problem is that one cannot tell in advance whether www.sub.example.net is part of the example.net zone. The recommendation could be given more precisely:
old: MUST refrain from sending queries to known lame servers
new: MUST refrain from sending queries whose QNAME is likely to be in the lame zone (i.e. equals the zone name or is below the zone name and not positively identified to belong to a distinct zone) to known lame servers
2.3 Inability to follow multiple levels of out-of-zone glue
In this paragraph the term glue is used where 'additional data' would be more precise.
new gTLDs will use name servers in other gTLDs, increasing the amount
of inter-zone glue.
Again, that's not glue then. s/glue/additional data/
2.4 Aggressive retransmission when fetching glue
implementations take this address inclusion a step further with a
feature called "glue fetching". A name server that implements glue
While at least one popular implementation called this 'fetch-glue', it's actually just additional section processing. Glue is just there (or it isn't), it can't be fetched. That should have been clarified by the AXFR draft, but that's unfortunately in some indetermined state. Sorry for the nitpicking here, but fuzzy or changing use of wording is extremely counterproductive in educating DNS operators. And yes, that does matter since they are part of our target audience here. So please let's use 'additional data processing' in favor of 'glue'.
The overall recommendation is fine, though.
2.6.1 Recommendation
An authoritative server can detect this situation. A trailing dot
missing from an NS record's RDATA always results by definition in a
name server name that exists somewhere under the SOA of the zone the
I'd prefer the term 'zone apex' over SOA, since the latter is just an RR type.
See Section 4 of RFC 2136. A Dynamic Update requestor is assumed to "be able to determine the nameservers for th[e] zone" and to be able to match an SOA MNAME with an NS NSDNAME. Such statements imply the issuance of NS record type queries.NS record appears in. Note that further levels of delegation are
possible, so a missing trailing dot could inadvertently create a name
server name that actually exists in a subzone. But in any case, the
address record must still be present in this zone, either as
authoritative data or glue.
I disagree with this analysis. Given the zone
example.net. NS dns.example.net -> dns.example.net.example.net.
Now, if a delegation at example.net.example.net. or net.example.net. exists, there's no need that dns.example.net.example.net. be one of the authoritative servers, so the absence of a glue A RR does not indicate that the name dns.example.net.example.net. does not exist. So, not only doesn't it have to exist in the zone, it also need not be part of the zone file (using the AXFR draft logic).
An authoritative name server SHOULD report an error when one of a
zone's NS records references a name server below the zone's SOA when
s/zone's SOA/zone apex/
a corresponding address record does not exist in the zone.
First, I'd suggest that any slave server only issue a warning but still load the zone. A master should report an error if the target of the NS RR is below the zone apex and an address record does not exist (because the name is within the zone and neither A nor AAAA RRsets exist or because the name doesn't exist) and a warning if the domain name belongs to a child zone (regardless of any glue RR).
2.7.1 Recommendation
Because of the additional load placed on a zone's parent's
authoritative servers resulting from a zero TTL on a zone's NS RRset,
under such circumstances authoritative name servers SHOULD issue a
warning when loading a zone or refuse to load the zone altogether.
A warning is OK at both a master and a slave, otherwise a slave should not refuse a zone on these grounds. Causing harm sometimes heals, but the slave administrator can't do much about this problem. Also, the recommendation should be clear in what to do (warning vs error), and a warning seems less invasive here. Also, refusing to load a 0 TTL zone while silently accepting TTLs of 1 second is probably hard to sell. This is registry policy, though, and could already be implemented there ...
2.8.1 Recommendation
Dynamic update agents SHOULD send SOA or NS queries to progressively
higher-level zones to find the closest enclosing zone for a given
s/zones/names/, since there's no need to send the query to higher zones. The actual problem is that you don't know what zone the name belongs to.
name to update. Only after the appropriate zone is found should the
client send an UPDATE message to one of the zone's authoritative
I'd restrict this recommendation to SOA queries only. NS queries are currently
not necessary and shouldn't be introduced.
I support this draft going to the IESG, with the exception of the SOA -> zone apex editorial change mentioned above.
- Kevin
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
