Sorry for the belated reply.
On Mar 24, 2015, at 1:03 PM, Shumon Huque <shu...@gmail.com> wrote:
> 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.
This seems good.
> 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?
That does not seem to be established firmly enough for us to add.
> > [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."
Excellent, yes.
>
> > 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)?
RFC 2308 has pages defining "negative responses". Instead of trying to
reproduce that, we should just point to it. We can add this as a new definition
in the preceding section.
> 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.
We're tentatively open to doing this, but doing so will delay the document
unless we have a strong candidate from the WG for the new wording.
>
> [...]
>
> > 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.
Good catch.
>
> > 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).
There are things that can transfer a copy of the zone data in some other
manner, but those are not really "slave servers", they are "some other data
source".
> Is "Secondary Server" (also fairly commonly used) a synonym for this?
Good catch; yes. We'll add a pointer to RFC 2182.
>
> > 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.
I can see that if I squint a bit. However, it's not up to us to say which one
is the "correct" definition.
> Do we need to also define the terms "DNS proxy" and "DNS ALG (application
> layer gateways)"?
Only if we have good definitions for those. :-)
>
> > 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)?
Based on other discussion, we will have a new definition for it in the next
draft.
Thanks!
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
