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 <d...@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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
