Some comments on draft-hoffman-dns-terminology
> NODATA -- This is not an actual response code, but instead is the
> combination of an RCODE of 0 (NOERROR) and an Answer section that is
> empty. That is, it indicates that the response is no answer, but
> that there was not supposed to be one. [72]Section 1 of [RFC2308]
> defines it as "a pseudo RCODE which indicates that the name is valid,
> for the given class, but are no records of the given type."
I don't think this definition is precise enough. Under this stated
definition, "referral responses" from authority servers qualify to be
called NODATA responses, because they also have a combination of
RCODE 0 and an empty answer section. Referrals can be excluded from
this definition by adding the constraint that NODATA responses from
authority servers have the AA bit set.
I'd also recommend starting the definition with a clear statement of
what it means first, followed by how it is represented in terms of packet
attributes. The current definition is in the reverse order which is
more difficult to read (at least for me). Here's my suggested rewrite:
NODATA -- This is not an actual response code, but is a particular
type of response from a server that indicates that the queried domain
name exists for the given class, but the resource record type being
queried for doesn't exist. They are a combination of an RCODE of 0
(NOERROR) and an Answer section that is empty. In addition, NODATA
responses from authoritative servers have the authoritative answer
(AA bit) set to one. Section 1 of [RFC2308] defines it as "a pseudo
RCODE which indicates that the name is valid, for the given class,
but are no records of the given type.
Should we also mention that NODATA responses usually include a SOA record
in the authority section to indicate to resolvers how long to do negative
caching for?
> [73]5. Resource Records
>
> RR -- A short form for resource record. ([74]RFC 1034, section 3.6.)
>
> RRset -- A set of resource records with the same label, class and
> type, but with different data. (Definition from [75]RFC 2181) Also
> spelled RRSet in some documents. As a clarification, "same label" in
> this definition means "same owner name".
I think the 'same TTL' constraint is important enough to restate
specifically
as part of this definition. I suggest adding:
In addition, RFC 2181 states that "the TTLs of all RRs in an RRSet
must be the same."
> SOA field names -- DNS documents, including the definitions here,
> often refer to the fields in the RDATA an SOA resource record by
> field name. Those fields are defined in [78]Section 3.3.13 of RFC
1035.
> The names (in the order they appear in the SOA RDATA) are MNAME,
> RNAME, SERIAL, REFRESH, RETRY, and EXPIRE, MINIMUM. Note that the
> meaning of MINIMUM field is updated in [79]Section 4 of RFC 2308; the
new
> definition is that the MINIMUM field is only "the TTL to be used for
> negative responses".
"Negative responses" is used here without a clear definition anywhere
earlier (or later) in the document. I think that definition needs to be
added. Is it only NXDOMAIN and NODATA responses? Or does it also include
failure responses (SERVFAIL, NOTIMP, or any of the extended response codes)?
The "Negative Caching" definition provided later in the document, quoting
RFC 2308 ("The storage of knowledge that something does not exist, cannot
give an answer, or does not give an answer") seems to imply that negative
responses include SERVFAIL, NOTIMP, etc.
> [80]6. DNS Servers
"DNS Servers and Clients" - immediately below we state that the
section talks about both.
> This section defines the terms used for the systems that act as DNS
> clients, DNS servers, or both. Some terms about servers describe
> servers that do and do not use DNSSEC; see [81]Section 8 for those
> definitions.
>
> [[ There is a request to "first describe the iterative and recursive
> resolution processes, and mention the expected values of the RD,RA,AA
> bits. Then you can describe the distinctions between recursive and
> iterative clients, and between recursive and authoritative servers,
> in terms of the roles they play in the different resolution
> processes." This would require the section to be quite different
> than the other sections in the document. ]]
That is one approach. I agree this section probably needs a significant
rewrite for clarity and precision. I find the current definitions of
the family of resolvers to be quite convoluted.
[...]
> Authoritative server -- A system that responds to DNS queries with
> information about zones for which it has been configured to answer
> with the AA flag in the response header set to 1. It is a server
> that has authority over one or more DNS zones. Note that it is
> possible for an authoritative server to respond to a query without
> the parent zone delegating authority to that server.
Missing from this definition is the fact that Authoritative Servers
also provide "referrals" (with AA=0 and referral data) to child zones
delegated from them.
> Slave -- An authoritative server which uses zone transfer to retrieve
> the zone. (Quoted from [88][RFC1996], section 2.1)
Is this the only definition? I believe it's possible for there to be
slave servers which transfer a copy of the zone data in some other
manner (i.e. not using the DNS zone transfer protocol).
Is "Secondary Server" (also fairly commonly used) a synonym for this?
> DNS forwarder -- A system receives a DNS query, possibly changes the
> query, sends the resulting query to a recursive resolver, receives
> the response from a resolver, possibly changes the response, and
> sends the resulting response to the stub resolver. Section 1 of
[94]RFC
> [95]2308 describes a forwarder as "a nameserver used to resolve queries
> instead of directly using the authoritative nameserver chain". RFC
> further says "The forwarder typically either has better access to the
> internet, or maintains a bigger cache which may be shared amongst
> many resolvers."
>
> [RFC5625] does not give a specific definition for DNS forwarder, but
> describes in detail what features they need to support. The protocol
> interfaces for DNS forwarders are exactly the same as those for
> recursive resolvers (for interactions with DNS stubs) and as those
> for stub resolvers (for interactions with recursive resolvers).
Perhaps I'm not reading it right, but the 2 paragraphs above seem to me
to have contradictory definitions of forwarder.
Do we need to also define the terms "DNS proxy" and "DNS ALG (application
layer gateways)"?
> Authoritative data -- RRsets in the Answer section of a DNS response
> that has the AA bit in the response header set to 1.
>
> Delegation -- The process by which a separate zone is created in the
> name space beneath a given domain. Delegation happens when an NS
> RRset is added in the parent zone for the child origin, and a
> corresponding zone apex is created at the child origin.
>
> Apex -- The SOA and NS RRsets at the origin of a zone. This is also
> called the "zone apex".
Why is it only the SOA and NS RRsets? I would suggest defining it in
terms of the domain name. Isn't this what the original RFCs defined as
the 'top node' (and not specific types of data sets that exist at the
top node)?
Shumon Huque
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
