Hi,
the following is a review of draft-ietf-dnsop-terminology-bis-08. It
represents a reading of the document front-to-back as a sort of
whirlwind introduction to the depths of DNS and assumes that such a
reading is intended and there is a narrative. Even if that wasn’t the
original intention, the arrangement of the terms seems to imply it
and I really like this form of introduction by short definition and
pointers to further details.
The review turned out to be quite a bit longer than expected. That
notwithstanding, I really like the document. It is extremely helpful and
serves its purpose well.
Most of the comments are of an editorial nature, pointing out wording
that might be unclear or the use of terms that haven’t been defined
yet. I understand that the purpose of this bis was to only update RFC
7719 to new developments, but I hope the following will be helpful to
the editors, anyway.
Because most comments are very short, I decided to collect everything in
this one message rather then creating issues on Github. If the editors
would have preferred that or any other form more helpful, I am happy to
transform the message accordingly.
With that in mind, here goes:
------ %< ------
1. INTRODUCTION
| (See Section 2 for a fuller definition.)
Section 2 doesn’t actually provide a definition for Domain Name System.
It does introduce Naming Systems and the Global DNS, but not the DNS as
such.
DOMAIN NAME
| [RFC1034] defines the "domain name space" using [...], and the
definition | in [RF1034] has the same practical result
Repetition, replace with "...and this definition has the same ..."?
| ... a domain name is a list of labels identifying a portion along one
edge | of a directed acyclic graph.
I keep struggling with this sentence, not being able to decide whether
there is some error in it or whether I just am not familiar with the
phrase ‘portion along one edge.’ Neither is optimal, though, so I would
propose to rather follow RFC 1034 and speak simply of a ‘path’ through
the graph?
One realisation I had while thinking too much about this sentence is
that my intuition (apparently backed up by RFC 1034) was to stick the
labels to the nodes in the tree, but that it might actually be a better
model to attach them to the edges and identify a node through the
domain name leading up to it. Maybe that is what the sentence is trying
to express?
| A domain name can be relative to other parts of the tree [...]
Proposal: Strike ‘other’ as there was no previous ‘this part’ it could
refer to?
GLOBAL DNS -- FORMAT OF NAMES
| Names in the common display format are normally written such that the
| directionality of the writing system presents labels by decreasing
| distance from the root (so, in both English and C the first label in
the | ordered list is right-most; but in Arabic it may be left-most,
depending | on local conventions).
The first sentence makes it sound as if right-to-left languages would
normally write ‘com.example’ which is not the case. Yes, things get
difficult once IDNs enter the scene, but the definition of the common
display format (‘same as presentation format’) only allows ASCII
characters and under these circumstances the name will always be in the
‘usual’ order.
GLOBAL DNS -- ADMINISTRATION OF NAMES
| (see the definition of to "delegation" in Section 6)
Extra "to".
| names operational community
I am not sure if people outside of the immediate ICANN sphere have ever
heard that term. Perhaps enclose it in quotes to indicate that this is a
jargon introduced here?
In general, I am not sure if this rapid sequence of terms and
organizations surrounding the root zone is necessary here. Maybe it
would fit better and in somewhat more detail in section 7? The
important point for DNS seems to be that each zone administers its own
names and that administration can be transferred via delegation?
PRIVATE DNS
| A system can use both the global DNS and one or more private DNS
systems; | for example, see "Split DNS" in Section 7.
Split DNS is actually defined in section 5.
FULLY QUALIFIED DOMAIN NAME (FQDN):
The discussion of the missing final dot probably predates the
introduction of representation format and common display formats for
domain names in the definition of Global DNS. It can either be dropped
entirely or replaced with a short reminder that there are two slightly
different textual formats.
| [...] partially qualified domain names, which are names where one or
more | of the earliest labels in the ordered list are omitted (for
example, | "www").
I am not sure the term ’earliest label’ is clear enough. The example
doesn’t help, since it isn’t clear whether it is the omitted labels (my
first reading) or a partially qualified name (following my internal
definition of the term).
HOST NAME
Perhaps mention the concrete rules for the labels? Particular since the
paragraph already mentions specifically how they have been relaxed
later.
Also, would be it be worthwhile to mention the use of non-host names as
a means to embed additional information in a query, i.e., the whole
business of ‘underscore labels?’
TLD
| most of them are also delegation-centric zones
Add a reference to the definition of delegation-centric zone in section
6?
ALIAS, CANONICAL NAME, and CNAME
These three definitions use a bunch of terms that haven’t been defined
(or even mentioned) yet. Perhaps they should be moved to section 4? I
suppose it is here because of the definition of QNAME, but, well, see
there.
Also, the definitions of alias and canonical name feel a bit cyclic.
PUBLIC SUFFIX
Perhaps this should be moved to section 7, given that is talks about
registries. Also, the uncommented mention of HTTP cookies was a bit of a
‘Huh?’ moment. That might deserve an extra sentence.
3. DNS HEADER AND RESPONSE CODES
After defining the header, the section suddenly talks about QNAME which
isn’t part of the header at all. It concludes with Referral which
doesn’t have much to do with the header either.
Given that the section also occasionally uses terms from section 4, a
proposal would be to rename it into something like "DNS Transactions"
and move it to after current section 4.
THE THREE MEANINGS OF QNAME
Would it be too preposterous for the document to actually introduce
these three meanings as actual terms, e.g., define ‘Original QNAME’?
The definition for ’QNAME (effective)’ isn’t quite clear. Does it mean
the ‘final’ QNAME in a response that doesn’t fully resolve a CNAME
chain?
FURTHER IN SECTION 3
| All of the RCODEs are listed at
| http://www.iana.org/assignments/dns-parameters, [...]
Should this be a reference? In particular, because
[IANA_Resource_Registry] is one.
A motivation, why those particular RCODEs have been included and not
others might be good. The teaser for NXRRSET made me feel dumb for not
remembering what it actually is.
(As an aside, the whole UPDATE business isn’t mentioned anywhere. The
term Dynamic DNS in particular might be worth defining.)
4. RESOURCE RECORDS
Does the term ‘resource record’ itself warrant a definition? It does
have a drive-by introduction in Global DNS, but it’s a bit indirect.
RRSET
I think it would be better to paraphrase RFC 2181’s definition and use
the precise term ‘owner name’ here (even though it still hasn’t been
defined at this point--perhaps pull that up before RRset?) and then
point out the somewhat rebellious use of the term ’label’ in 2181 (and
perhaps even the irony that a document entitled ‘Clarifications to the
DNS Specification’ needs a clarification).
MASTER FILE
A very common alternative term for master files that may be worth
pointing out is ‘zone files.’ The distinction to a master file as per
RFC 1035 may or may not be that a zone file contains the records for a
single zone.
SOA FIELD NAMES
This is an aside, but at various points the document speaks of "an SOA
record" (or similar). I have only ever heard SOA used as an acronym and
pronounced as ‘soah.’ Is the pronunciation as ‘ess oh ah’ indicated by
the use of ’an’ indeed common?
TTL
Here, RFC 2181 seems to swing the other way and provide an overly
precise definition. Would anyone really shift the TTL value one bit to
the left for wire formatting? I think paraphrasing would be better.
Did RFC 2181 introduce the 31 bit thing to deal with the error in RFC
1035 without the need to update it? If so, this might be worth pointing
out.
Beyond that, RFC 1035 specifically mentions the case of a TTL of zero.
Should this case, its consequences, and uses be discussed here?
RESOLVER
| "The resolver is located on the same machine as the program that
requests | the resolver's services, [...]" [...] In practice, the term
is usually | referring to some specific type of resolver
I think the main difference in practice to that quote from RFC 1034 is
that a resolver is often meant as a DNS server that provides the
resolution function and whose clients may very well be on different
machines. The quote should either be dropped or its conflict with
common usage be pointed out specifically.
ITERATIVE MODE
Further down is a definition for ‘iterative resolution’ which provides a
more in-depth explanation. Perhaps these two should be merged?
PRIMING
This comes a bit suddenly. Maybe it should start with a short
introduction a la ‘In order to operate in recursive mode, a resolver
needs to know the address of at least one root server.’
ROOT HINTS
It sounds like this is the configuration mentioned in ‘priming.’ If
that is so, that should probably be pointed out.
ZONE TRANSFER
I think this and all the following related definitions belong in
section 6 after the whole concept of zones has been introduced.
SECONDARY SERVERS
The final sentence might better be included in the normal text. For
instance, instead of the second sentence: ‘Secondary server are
discussed initially in [RFC1034] and described in detail in [RFC2182].’
Ditto for PRIMARY SERVERS
STEALTH SERVER and HIDDEN MASTER
A stealth server is defined as a secondary server and a hidden master
(which should probably be a ’hidden primary’ for consistency) as a
stealth server which it can’t be on account of being a primary server.
FORWARDING
| [RFC5625] does not give a specific definition for forwarding, but
| describes in detail what features a system that forwards need to
| support.
s/need/needs/
FORWARDER
The quoted text from RFC 2308 defines the forwarder as the upstream
server used by a resolver that only forwards queries. This definition
runs somewhat counter to the construct’s usual meaning in English where
a forwarder would be ’someone who forwards.’ This is particularly
grating after the previous definition of what ‘forwarding’ means takes
away the argument that it is a forwarder because it relays (‘forwards’)
my queries.
Which is to say, there maybe should be an acknowledgement of this
discrepancy.
PASSIVE DNS
| A mechanism to collect DNS data by storing DNS transactions from name
| servers. Some of these systems also collect the DNS queries
associated | with the responses.
I don’t think it has been defined yet, but the term ‘transaction’
commonly refers to a pair of a query and its response (plus possibly
any re-sent queries or responses due to packet loss). With this in
mind, the second sentence doesn’t quite make sense.
SPLIT DNS
This seems to be a play on the term ‘view’ defined earlier and should be
described in tandem with it. It might be worthwhile pointing out where
the two differ.
CHILD
| "The entity on record that has the delegation of the domain from the
| Parent."
There is probably a better term than ‘entity’ which hasn’t been used
anywhere before and is a very generic term.
PARENT
I’m not sure the quotes from an RFC obsoleted thirty years ago add any
value to the understanding of the term.
GLUE RECORDS
Given that the definition refers to authoritative data, that term’s
definition should perhaps be moved up before this one.
IN-BAILIWICK
The three definitions here are very confusing. I think what isn’t
becoming clear is that the zone origin that the name server is
‘subordinate (etc., etc.) to’ is that of the parent zone of the
delegation and that the definitions of the two types switch that
subordinate to the child zone’s apex. The latter is mentioned via
’owner name of the NS record’ but this should probably be made more
clear.
Also, on behalf on non-native speakers, a short explanation of the
origin of the term would perhaps be nice.
AUTHORITATIVE DATA
I can’t quite see how the definition from RFC 1034 would allow
delegation NS records to be part of the authoritative data, as these
records are attached to nodes _below_ the cuts. Even if there is any
doubt left, RFC 1034 very clearly calls out that they are NOT, two
paragraphs on.
Consequently, I also don’t see the ambiguity. It may be worth pointing
out (and perhaps this is the perceived ambiguity) that there is data
that is part of a zone but not authoritative, specifically those
delegation NS records and all the glue.
Of course, there then are DS records but they aren’t mentioned in the
document at all.
WILDCARD
Perhaps pull the last sentence up as a consequence of the first:
‘[RFC1034] defined wildards, but in a way that turned out to be
confusing to implementers, so [RFC4592] provides an extended discussion
[...]’ It might still be good to mention why exactly they are confusing
in RFC1034 since that may not be obvious for a casual reader.
Further, this could probably be tied together with the definition of
asterisk label and wildcard domain name.
ASTERISK LABEL
I think it would be better to paraphrase this definition since label
types (quite rightfully) haven’t been mentioned anywhere yet and the
length octet earlier has been introduced as part of the wire-format
representation of the label and not the label itself. So, something
along the lines of ’A single-octet label consisting merely of the ASCII
representation of the “*” character.
But I am not sure if this term is important enough to warrant an entire
entry instead of just mentioning it en passant during the definition of
wildcard (domain name).
CLOSEST ENCLOSER and following
These should probably called out to be only relevant for wildcard
processing. (Which makes me think that maybe adding another level of
sectioning might be helpful for grouping terms generally.)
OCCLUDED NAME
Dynamic update has never been introduced and DNAME only mentioned.
Without understanding these, the definition is impossible to make sense
of.
INFRASTRUCTURE DOMAIN
The term ’domain’ has never been defined. Its use is quite vague. The
quoted RFC 3172 seems to use it as a synonym for TLD. Given that the
term ’infrastructure domain’ was specifically only created for arpa, I
am not sure it should be a separate item here but rather be mentioned
as part of the definition of arpa.
SUBORDINATE AND SUPERORDINATE
This should probably be way, way up in section 2. Also (continuing from
the last point), domain here seems to mean domain name. Or does it?
GENERAL DNSSEC
I think it would be good to define DNSSEC and mention what it does and,
more importantly, what it does not do. There seems to be quite a bit of
confusion around that.
This could perhaps be done by pulling up section 9 and starting it by
that DNSSEC definition.
VALIDATION
| Validation, in the context of DNSSEC, refers to the following:
For clarity: ‘one of the following’ or ‘all of the following’?
ZONE SIGNING KEY
| Note that the roles KSK and ZSK are not mutually exclusive [...]
This note is unnecessary given the following definition of a CSK.
HARDWARE SECURITY MODULES
| [...] and to create the RRSIG records at periodic intervals.
Technically, the HSM only creates the signatures that are part of the
RRSIG records. The distinction is important to avoid implying that HSMs
are somehow DNS-aware rather than them having only been appropriated for
DNSSEC.
SIGNING SOFTWARE
| Authoritative DNS servers that supports DNSSEC often contains software
| [...]
support and contain sans the ‘s’.
9. DNSSEC STATES
Given how important these states are and that the consequences of
‘bogus’ and ‘insecure’ can easily be miss-interpreted by only looking
at the words, I am not sure I like the rather hand wavy tone of this
section.
One improvement would be to contrast the definitions directly be placing
them next to each other for each term.
------ %< ------
Kind regards,
Martin
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
