This turned out to be quite long... I hope it is useful!

An alphabetical index would be helpful, as would making the formatting
of paragraphs more distinct depending on whether they start with a
definition or not (e.g. hangText in xml2rfc markup). It would also be
good to avoid definitions in the middle of paragraphs unless they are
cross-referenced from a headword (except perhaps for field or flag
names).

* Section 2

** FQDN

For a clear definition you should quote RFC 1206:

      A Fully Qualified Domain Name (FQDN) is a domain name that
      includes all higher level domains relevant to the entity named.

The definition should say that the reason for using the term FQDN is to
clearly distinguish them from partially-qualified or unqualified names,
where some or all of the trailing labels are omitted.

I think you should include the terms "partial domain name" (from RFC
1535) with the definition "not an FQDN".

For trailing dots you should use the term "rooted FQDN" and quote the
definition from RFC 1535:

   An absolute "rooted" FQDN is of the format {name}{.}

It is worth mentioning the caveat that some protocols (e.g. SMTP and 822)
do not allow you to include a trailing dot.

** Public suffix

The example of .com.au vs .au is amusing given this :-)
http://domainincite.com/18367-australia-considers-dumping-the-com

** missing definitions

    Alias -- The owner of a CNAME RR, or a subdomain of the owner of a
    DNAME RR [RFC 6672]. See also "canonical name".

    Canonical name -- A CNAME RR identifies its owner name as an
    alias, and specifies the corresponding canonical name in the RDATA
    section of the RR. (RFC 1034 section 3.6.2) This usage of the word
    "canonical" is related to the mathematical concept of "canonical
    form".

    CNAME -- It is traditional to refer to the owner of a CNAME record
    as "a CNAME". This is unfortunate, as "CNAME" is an abbreviation
    of "canonical name", and the owner of a CNAME record is an alias
    not a canonical name. (RFC 2181 section 10.1.1)

* Section 3

I suggest this section should be expanded to cover "DNS messages and
message sequences", the general theme being higher-level properties of
messages. The idea is that the various client and server roles will be
clearer after their interactions have been set out. (It would probably
also make sense to swap the order of section 3 and 4, so the
progression is small -> big, names - records - messages - servers.)

I have some suggested definitions below, some of which need moving
from other sections in the current draft.

** NXRRSET

Correction: NXRRSET is not a synonym for NODATA: NXRRSET is a different
and specific response code used with DNS UPDATE (RFC 2136). I think this
document should say that treating them the same is a misuse of
terminology and liable to cause confusion.

** Negative response

The current definition implies that all negative responses are indicated
by the RCODE, but that isn't the case for NODATA. I suggest:

   Negative response -- A response which indicates that a
   particular RRset does not exist in the DNS or whose RCODE indicates the
   nameserver cannot answer.  Sections 2 and 7 of [RFC2308] describes the
   types of negative responses in detail.

Text mostly from RFC 2308. I say "cannot answer" as a way to cover
REFUSED as well as SERVFAIL.

** NODATA

The following sentences are a bit misleading because they aren't
enough to identify NOERROR responses.

   A NODATA response is 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 1 and include an SOA record.

I suggest:

   NODATA -- a pseudo RCODE which indicates that the name is valid,
   for the given class, but are no records of the given type. (Quoted
   from [RFC 2308] section 1.) NODATA is indicated by an answer with
   the RCODE set to NOERROR and no relevant answers in the answer
   section. The authority section will contain an SOA record, or there
   will be no NS records there. (Quoted from [RFC 2308] section 2.2.)
   (Referrals have a similar format to NODATA replies; RFC 2308
   explains how to distinguish them.)

** Referral

Move here from section 6. I think of referrals as a type of DNS reply
(as in RFC 2308) so it seems wrong to have this definition in a
section about zones. I also think referrals are the whole reply, not
just part of it as the current definition says. And it seems to be a
bit confused - the discussion about authoritative vs non-authoritative
data seems redundant wrt the definitions of authoritative data and
delegations and somewhat irrelevant to the question of what a referral
is.

It's hard to find a succinct definition in the existing RFCs. My best
try is as follows. (Three key characteristics of referrals each with a
quote and a wee bit of clarification.)

   Referral -- A non-recursive response contains an error, the answer,
   or a referral to some other server "closer" to the answer. (RFC
   1034 section 4.3.1) That is, a referral occurs as part of the
   iterative resolution process.

   When searching for an answer in its authoritative data, a referral
   is found when the name server encounters a node with NS RRs marking
   cuts along the bottom of a zone. (RFC 1034 section 4.3.2) That is,
   a referral contains a delegation NS RRset.

   Like NODATA, a referral is an answer with the RCODE set to NOERROR
   and no relevant answers in the answer section. It is possible to
   distinguish between a NODATA and a referral response by the
   presence of a SOA record in the authority section or the absence of
   NS records in the authority section. (Quoted from [RFC 2308]
   section 2.2.)

   Historically, many authoritative servers answered with a referral
   to the root zone when queried for a name for which they were not
   authoritative, but this practice has declined.

Regarding referrals as part of an answer, it might be helpful to add:

   Implicit referral -- An implicit referral is characterised by NS
   records in the authority section referring the resolver towards a
   authoritative source. All answers coming from the cache have an
   implicit referral built into the answer. This enables the resolver
   to locate an authoritative source. ([RFC 2308] section 6.) The NS
   RRset in an implicit referral can come from a zone apex or a
   delegation.

** Zone transfer

Move here from section 5, since zone transfers are messages not servers.
Needs to cite RFC 5936 and RFC 1995. I suggest:

   Zone transfer -- When changes are made to a zone, they must be
   distributed to all of the zone's name servers. While this
   distribution can be accomplished using FTP or some other ad hoc
   procedure, the preferred method is the zone transfer part of the
   DNS protocol. (RFC 1034 section 4.3.5) Authoritative Transfer
   (AXFR) is described in RFC 5936 and Incremental Transfer (IXFR) is
   described in RFC 1995.

** more definitions

   Recursive query -- A query with the Recursion Desired bit set in
   the header. (RD=1) (See RFC 1035 section 4.1.1) If recursive
   service is available and requested via the RD bit in the query, the
   server uses its resolver to answer the query. (RFC 1034 section 4.3.2)

   Non-recursive query -- A query with the Recursion Desired bit unset
   in the header. (RD=0) A server can answer non-recursive queries
   using only local information: the response contains an error, the
   answer, or a referral to some other server "closer" to the answer.
   (RFC 1034 section 4.3.1)

   Iterative query -- Synonym for non-recursive query. This term is
   used in a number of RFCs though never explicitly defined; see for
   instance RFC 4697.

   Resolution -- The process of obtaining an answer to a query from
   one or more name servers, which may be iterative or recursive or
   some mixture of the two.

   Iterative resolution -- A name server may be presented with a query
   that can only be answered by some other server. The two general
   approaches to dealing with this problem are "recursive", in which
   the first server pursues the query for the client at another
   server, and "iterative", in which the server refers the client to
   another server and lets the client pursue the query. (RFC 1034 section 2.3)

   In iterative resolution, the client repeatedly makes non-recursive
   queries and follows referrals and/or aliases. The iterative
   resolution algorithm is described in RFC 1034 section 5.3.3.

   Recursive resolution -- The simplest mode for the client is
   recursive, since in this mode the name server acts in the role of a
   resolver and returns either an error or the answer, but never
   referrals. Recursive service is helpful for a relatively simple
   requester that lacks the ability to use anything other than a
   direct answer to the question. (RFC 1034 section 4.3.1)
   See also "iterative resolution".

* Section 4

** EDNS

There is some single/plural confusion here. I suggest:

   EDNS -- The extension mechanisms for DNS, defined in [RFC6891].
   Sometimes called "EDNS0" or "EDNS(0)" to indicate the version number.
   EDNS allows DNS clients and servers to specify message sizes larger than
   the original 512 octet limit, to expand the response code space, and
   to potentially carry additional options that affect the handling of a
   DNS query.

* Section 5

** Resolver

   Resolver -- A program that extracts information from name servers in
   response to client requests.  (Quoted from [RFC1034], section 2.4) It
   is a program that interfaces user programs to domain name servers.

Where does that sentence come from? It isn't part of the following
quote, and I don't think it adds anything to the preceding quote.

   The resolver is located on the same machine as the program that
   requests the resolver's services.  (Quoted from [RFC1034], section
   5.1)

I think it's worth including the rest of that sentence:

   , but it may need to consult name servers on other hosts.

You should be able to drop the sentences about resolution if you adopt
my suggestions for section 3.

** Iterative mode

drop

** Recursive mode

I suggest replacing with:

   Recursive server -- The recursion available, or RA bit, is set or
   cleared by a recursive server in all responses. The bit is true if
   the name server is willing to provide recursive service for the
   client. (RFC 1034 section 4.1.1) A recursive server may be thought
   of as having a name server side (which is what answers the query)
   and a resolver side (which performs the resolution function).

   Recursive client -- A client that sends recursive queries, such as
   a stub resolver.

   Recursive resolver -- This term is ambiguous and best avoided. It
   can mean either 1. A recursive server; or 2. A recursive client. To
   make this more confusing, recursive servers commonly perform
   iterative resolution.

** Full-service resolver

Does this imply that the resolver is also a recursive server, or just
that it implements the cache and client/query side? The RFC 1034 model
implies resolvers are client-only, and RFC 1123 doesn't explicitly
require the server side.

** Authoritative server

RFC 2182 has a really nice definition:

   Authoritative Server -- A server that knows the content of a DNS
   zone from local knowledge, and thus can answer queries about that
   zone without needing to query other servers. (RFC 2182 section 2)

This is also good:

   The name server [sets the Authoritative Answer (AA) bit in] its
   responses to queries so that the requester can tell whether the
   response comes from authoritative data or not. (RFC 1034 section
   4.1)

** Hidden master

Needs a headword of its own. The current definition isn't quite right
because it implies the hidden master is a slave, whereas it is often the
primary master.

I suggest:

   Stealth server -- This is the same as a slave server except that it
   is not listed in an NS resource record for the zone.  (Quoted from
   [RFC1996], section 2.1) See also "hidden master".

   Hidden master -- In this arrangement,
   the master name server that processes the updates is unavailable to
   general hosts on the Internet; it is not listed in the NS RRset.
   (Quoted from [RFC 6781] section 3.4.3) The predecessor [RFC 4641]
   says the hidden master's name appears in the SOA RRs MNAME field,
   though in some setups it does not appear in the public DNS at all.

** Zone transfer

Move to section 3.

** Open resolver

Worth citing openresolverproject.org ?

** view

I don't know of servers that do per-QTYPE views. I suggest:

                                                            Typically,
   views differ by the source IP address of a query, but can also be
   based on the destination IP address, the query class (such as
   CHAOS), whether or not it is recursive, and so on.

** Child-centric resolver

This definition seems incomplete to me. The resolvers I am familiar
with change which NS RRset they serve depending on whether or not NS
records have been explicitly queried for.

Also [citation needed] ... the term isn't used in
draft-vixie-dnsext-resimprove which discussed this kind of issue,
so is it a prominent enough term to include here?

* Section 6

** Origin

Meaning 1 has a pressy nice definition in RFC 2181:

   The domain name that appears at the top of a zone (just below the cut
   that separates the zone from its parent) is called the zone's
   "origin".  The name of the zone is the same as the name of the domain
   at the zone's origin.

** Zone cut

I think this text from RFC 2181 is a definition:

   Zones are delimited by "zone cuts".  Each zone cut separates a
   "child" zone (below the cut) from a "parent" zone (above the cut).

** Apex

Probably worth noting that RFC 1034 calls this the "top node of the zone",
but "apex" is now the preferred term.

** Delegation

The current definition is the verb form. There is also a noun form, e.g.
RFC 4035:

   the parental side of a zone cut (that is, at a delegation point)

RFC 1035:

   ... the RRs defining a delegation ...

I suggest:

   Delegation -- A delegation point is the parental side of a zone cut. It
   is defined by an NS RRset indicating the servers that host the child zone,
   and may have associated glue, DS, and other DNSSEC records.
   "Delegation" can also be a verb describing the process of introducing a
   zone cut.

** Referral

Move to section 3 - see above.

** Glue

I suggest tweaking the definition to make it clearer that "the servers"
are name servers in subzones (since the quote omits preceding sentences
from RFC 1034 that "the servers" refers to):

   Glue records -- Resource records which are not part of the
   authoritative data [of the zone], and are address RRs for
   [name servers in subzones].

** Authoritative data

This sentence is wrong:

              It is noted that this definition might inadvertently also
   include any NS records that appear in the zone, even those that might
   not truly be authoritative because there are identical NS RRs below
   the zone cut.

In RFC 1034, zone cuts are clearly defined to occur between labels, above
each delegation point, so it is correct to define authoritative data as
being above the zone cut, and this unambiguously excludes delegation NS
RRsets.

With the DNSSEC definition of zone cut which goes through the middle of
the delegation point, you can argue (though it is a bit subtle) that the
NSEC and DS RRsets are above the zone cut and the non-authoritative
delegation NS RRset (and any glue) are below the zone cut.

So I suggest:

   Authoritative data -- All of the RRs attached to all of the nodes
   from the top node of the zone down to leaf nodes or nodes above cuts
   around the bottom edge of the zone.  (Quoted from Section 4.2.1 of
   [RFC1034]) This definition excludes any delegation NS RRsets and glue
   records. RFC 4035 section 2.6 updates the original DNS specification to allow
   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
   are authoritative for the parent when they appear at the parent side
   of a zone cut. RFC 4035 section 2.2 says that delegation NS RRsets and
   glue are not signed, consistent with them not being authoritative data.

** Empty non-terminals

Should cite RFC 4592 section 2.2.2 which has a very nice expanded
definition.

** Delegation-centric

Probably worth citing RFC 5155 which uses the term without
defining it.

Did we decide whether or not to include a definition of "delegation-only"?
The announcement for BIND 9.2.2-P2 which introduced the feature has a
pretty good definition.

https://lists.isc.org/pipermail/bind-announce/2003-September/000120.html

   Delegation-only zone -- a zone which is limited to containing NS
   RRs for subdomains, but no other data outside its apex (for example,
   its SOA RR and apex NS RRset).

** Fast flux

Should cite RFC 6561 section 1.1.5

* Section 7

I suggest adding this definition:

   WHOIS -- a protocol specified in RFC 3912 often used for querying
   registry databases.

* Section 8

I suggest adding this definition:

   Secure Entry Point (SEP) -- a DNSKEY flag bit which can be used to
   distinguish between keys that are intended to be pointed to
   by parental DS RRs or configured as a trust anchor. It is suggested
   that the SEP flag be set on keys that are used as KSKs and not on keys
   that are used as ZSKs. [RFC 6781 section 3.2.3]

I suggest reformarring the last few sentences as follows, and using a
quote from RFC 6781:

   CSK -- In cases where the differentiation between the KSK and ZSK is not made,
   i.e., where keys have the role of both KSK and ZSK, we talk about a
   Single-Type Signing Scheme. [RFC 6781] This is sometimes called a
   "combined signing key" or CSK.  It is operational practice, not
   protocol, that determines whether a particular key is a ZSK, a KSK,
   or a CSK.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Trafalgar: Variable 4, becoming southeasterly 5 to 7 in west. Moderate or
rough, becoming very rough later in west. Rain later. Good, occasionally poor
later.