Kevin Darcy 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.
after re- and rere-reading the draft paragraph An example is the entity that accepts recursive queries, issues iterative queries as necessary to resolve the initial recursive query, caches responses it receives, and which is also able 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. I stand corrected. (editorial nit: is also able [to] answer questions) Terminology confusion is indeed ugly. There's an agreed upon list in draft-ietf-dnsext-dnssec-intro. > 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. Sure, sorry for being unclear in my remark. Debugging is of course out of scope. > >not necessary and shouldn't be introduced. > > > 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. It doesn't outlaw them but it also doesn't necessarily imply them since the NS RRs can also be learned from the authority section of a response to a query for another QTYPE, e.g. SOA. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
