Subject: [DNSOP] New version of the DNS terminology draft

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Jan 2015 14:16:47 -0800

Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks!

Name:		draft-hoffman-dns-terminology
Revision:	01
Title:		DNS Terminology
Document date:	2015-01-19
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt
Status:         https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
Htmlized:       http://tools.ietf.org/html/draft-hoffman-dns-terminology-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 19 Jan 2015 18:27:08 -0500

All,

This seems like a tremendously useful document to have out there. Thanks to the authors for the effort and I suspect discussion on the list would be helpful.

As a general reminder, we had a very productive meeting in Honolulu, and now we're about halfway from there to Dallas (somewhere just west of LA? :-)) For authors, editors, and reviewers-- it'll be agenda-bashing time before you know it, let's start now and beat the rush!

(And yes that means it's also time to start letting your chairs know what we can do to support progress on new drafts or those already in the pipeline.)

thanks,
Suzanne

On Jan 19, 2015, at 5:16 PM, Paul Hoffman <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Davey Song <[email-masked]>
Date: Tue, 20 Jan 2015 11:26:14 +0800

Oh, It's a great work and helpful as a collection of important DNS
terminology.  It's not easy to choose the terminology from massive
DNS-related RFCs.

By the way, I notice the "Priming" is not included in the draft. I think it
is a common jargon(not documented yet) used in the community. There maybe
other jargon like that.

Davey

On Tue, Jan 20, 2015 at 6:16 AM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. Andrew, Kazunori, and I have done a massive revision on
> the DNS terminology draft based on the input we got on the -00. We're sure
> we have further to go, but we wanted people to look over the new version
> and give feedback. Thanks!
>
> URL:
> http://www.ietf.org/internet-drafts/draft-hoffman-dns-terminology-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology/
> Htmlized:
> http://tools.ietf.org/html/draft-hoffman-dns-terminology-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-01
>

---

From: Declan Ma <[email-masked]>
Date: Tue, 20 Jan 2015 23:56:44 +0800

Paul,

As for 'DNS Servers', I think we should set aside space for 'Cache-only DNS Server' which is pervasive in all kinds of DNS document. 

And as in 'Zones', you mentioned 'Origin'. So, I suggest adding a paragraph to describe 'Default TTL', which is represented as $TTL in zone file.

Still, 'Stub Zone' is yet another common expression in DNS context. We may put it into this document. 

Declan Ma

ZDNS Ltd.

4, South 4th Street, Zhongguancun, 
Haidian, Beijing 100190,
China

> 在 2015年1月20日，上午6:16，Paul Hoffman <[email-masked]> 写道：
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 21 Jan 2015 06:52:40 -0800

Awesome doc, just some small observations;

TTL: It might be worth using the word 'maximum' in relation to the
TTL; I think there is consensus that TTLs may be truncated.

RRSet:  Are the RRs in an RRSet required to have different data? For
types such as A/AAAA/SRV/MX this makes sense, but maybe not for TXT. I
also think views and other implementation specific features confuse
things here. A user might have 10 A records defined for a given name;
but if their DNS server returns one at a time (say it's using weighted
round robin) - I don't think of the 10 as an RRSet; but rather it's 10
RRSets. What's actually sent on the wire is what matters, I think.

Stealth server:  this definition seems a bit contradictory. Starts out
by saying it's a slave, but then says it can also be a master.

Suggestions for section 6:  Open resolver, Public resolver

Suggestions for section 7: glue, child-centric, parent-centric

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2015 07:25:00 -0800

> Colm MacCárthaigh <mailto:[email-masked]>
> Wednesday, January 21, 2015 6:52 AM
>
>

if their server returns only one RR at a time, then there are ten
RRsets, as you say. however, such a server would not be speaking the DNS
protocol as defined, if it starts from a zone file or zone transfer
where there is within the zone ten RR's for a given name. so, by
definition, the current text is correct.
> by saying it's a slave, but then says it can also be a master.

in <http://www.rfc-editor.org/rfc/rfc1996.txt> we see:

   1.3. This document intentionally gives more definition to the roles
   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
   RRs, and the SOA MNAME field.  In that sense, this document can be
   considered an addendum to [RFC1035].
...

   2.1. The following definitions are used in this document:

   Slave           an authoritative server which uses zone transfer to
                   retrieve the zone.  All slave servers are named in
                   the NS RRs for the zone.

   Master          any authoritative server configured to be the source
                   of zone transfer for one or more slave servers.

   Primary Master  master server at the root of the zone transfer
                   dependency graph.  The primary master is named in the
                   zone's SOA MNAME field and optionally by an NS RR.
                   There is by definition only one primary master server
                   per zone.

   Stealth         like a slave server except not listed in an NS RR for
                   the zone.  A stealth server, unless explicitly
                   configured to do otherwise, will set the AA bit in
                   responses and be capable of acting as a master.  A
                   stealth server will only be known by other servers if
                   they are given static configuration data indicating
                   its existence.

   Notify Set      set of servers to be notified of changes to some
                   zone.  Default is all servers named in the NS RRset,
                   except for any server also named in the SOA MNAME.
                   Some implementations will permit the name server
                   administrator to override this set or add elements to
                   it (such as, for example, stealth servers).

   2.2. The zone's servers must be organized into a dependency graph
   such that there is a primary master, and all other servers must use
   AXFR or IXFR either from the primary master or from some slave which
   is also a master.  No loops are permitted in the AXFR dependency
   graph.

in other words, what makes you a master is that someone is transferring from you. the primary master is the only master that by definition cannot also be a slave. the terms "master" and "slave" refer to protocol roles within the AXFR/IXFR transaction.

-- 
Paul Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Jan 2015 07:54:18 -0800

Thanks for the suggestions! However:

> RRSets. What's actually sent on the wire is what matters, I think.

Note that, when possible, our document is reproducing what is in the standards-track RFCs. You might want a different definition for a term, but if there is a non-confusing definition already, our document should use it. In this case, the RFC 2181 definition is refreshingly clear, and what you are describing would be a thing that is not an RRset and maybe should have a different term.

We are, in fact, making up some terms in the document, but only in cases where there is a well-known thing that doesn't have a term. I don't think your round-robin example is such a thing, but if others disagree and can come up with a new term, we can add it.

--Paul Hoffman

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 21 Jan 2015 08:36:48 -0800

On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie <[email-masked]> wrote:
> if their server returns only one RR at a time, then there are ten RRsets,
> as you say. however, such a server would not be speaking the DNS protocol
> as defined, if it starts from a zone file or zone transfer where there is
> within the zone ten RR's for a given name. so, by definition, the current
> text is correct.
>

If there are two zones for the same name, with different views, do the RRs
of a given name and type in both zones form a single rrset? I don't think
so. Zone files aren't a requirement of the DNS protocol either; and I don't
think there's any case to be made that the configuration of multiple rrsets
for the same name/type is not speaking the DNS protocol as defined.

> It might be worth updating the text to say "is often also a master" to
make the non-exclusivity between master and slave a bit more clear.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Jan 2015 09:12:04 -0800

> Wednesday, January 21, 2015 8:36 AM
>
>
> On Wed, Jan 21, 2015 at 7:25 AM, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     RRsets, as you say. however, such a server would not be speaking
>     the DNS protocol as defined, if it starts from a zone file or zone
>     transfer where there is within the zone ten RR's for a given name.
>     so, by definition, the current text is correct.
>
>
> If there are two zones for the same name, with different views, do the
> RRs of a given name and type in both zones form a single rrset? ...

views are outside of the protocol, and i don't think a dns terminology
document should talk about them at all.

> I don't think so. Zone files aren't a requirement of the DNS protocol
> either; and I don't think there's any case to be made that the
> configuration of multiple rrsets for the same name/type is not
> speaking the DNS protocol as defined.

to my credit, i wrote "or a zone transfer". that means if you are
optionally receiving a zone (as defined in the protocol) or optionally
loading a zone file (as defined in the protocol), then the meaning of a
set of rr's in that zone transfer session or that zone file is as
described by the protocol, and if you subset that set of rr's when
sending a response to a query matching that name and type, then you are
acting outside of the protocol. in this case as in the above case, i
don't think a dns terminology document should describe things that are
outside of the protocol.

> make the non-exclusivity between master and slave a bit more clear. 

i think so too.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Jan 2015 17:40:00 +0000

> TTL; I think there is consensus that TTLs may be truncated.

Yes, due to memory pressure, server restarts, administrative fiat,
DNSSEC (RFC 4035 section 5.3.3), etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover, Wight, Portland: Southeast, backing east, 4 or 5,
occasionally 6 at first in Humber. Slight or moderate, but rough at first in
Portland. Showers. Good, occasionally moderate.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Wed, 21 Jan 2015 18:27:12 +0000

At Mon, 19 Jan 2015 14:16:47 -0800,
Paul Hoffman wrote:
> 
> Greetings again. Andrew, Kazunori, and I have done a massive
> revision on the DNS terminology draft based on the input we got on
> the -00. We're sure we have further to go,

  So far, great job!

> but we wanted people to
> look over the new version and give feedback. Thanks!

[snip from http://www.ietf.org/id/draft-hoffman-dns-terminology-01.txt]
7.  Zones

   This section defines terms that are used when discussing zones that
   are being served or retrieved.

   Zone -- A unit of organization of authoritative data.

   [...]

   Authoritative data -- RRsets in the Answer section of a DNS response
   that has the AA bit in the response header set to 1.
[/snip]

  This seems to describe how Authoritative data must be marked in
  a DNS response, rather than to define Authoritative data.

  Besides, section 6.2.7 of RFC1034 shows a non-authoritative RR in
  the Answer section of a response which has the AA bit.

  I'ld suggest using the following text from RFC1034 (section 4.2.1):
  "The authoritative data for a zone is simply 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."

  Best regards,
  Niall O'Reilly

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Jan 2015 11:27:26 -0800

>  nodes above cuts around the bottom edge of the zone."

Quoting directly from the source RFCs seems better, yes. Thanks!

--Paul Hoffman

---

From: 神明達哉 <[email-masked]>
Date: Thu, 22 Jan 2015 10:29:02 -0800

At Wed, 21 Jan 2015 07:54:18 -0800,

> Note that, when possible, our document is reproducing what is in the standards-track RFCs. You might want a different definition for a term, but if there is a non-confusing definition already, our…

+1.

I'd also note that if we extended the definition of the term "RRset"
so it can contain duplicate RDATA, it would break Section 6.3 of
RFC4034:

   [RFC2181] specifies that an RRset is not allowed to contain duplicate
   records (multiple RRs with the same owner name, class, type, and
   RDATA).  Therefore, if an implementation detects duplicate RRs when
   putting the RRset in canonical form, it MUST treat this as a protocol
   error.

I guess there may be other normative text that relies on this
definition.

So, if we had any specific reason to name the concept of a "set of
RRs that can contain duplicate RDATA", that should be something
different than "RRset".

--
JINMEI, Tatuya

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 27 Jan 2015 12:58:15 +0000

Paul Hoffman wrote:
> 
> [...] we wanted people to look over the new version and give
> feedback. Thanks!

  The introduction presents the definition,
  "The DNS is a simple query-response protocol whose messages in both
   directions have the same format."

  Maybe it's just me, but I think a broader definition would be useful
  for "instructional" purposes.  I'm not thinking here only of teaching
  students or professional trainees, but also of persuading management.
  
  From time to time, I've found I needed to describe the DNS in any
  of four different ways, according to the aspect needing emphasis
  in particular circumstances.

  FWIW, I see the DNS as

  - a naming scheme for objects on the Internet;

  - a database representing the names and certain properties of these
    objects;

  - an architecture providing distributed maintenance, resilience,
    and loose coherency for this database; and

  - a simple query-response protocol (as mentioned in the current
    draft) implementing this architecture.

  IHTH
  Niall O'Reilly

---

From: "Jiankang Yao" <[email-masked]>
Date: Thu, 29 Jan 2015 14:33:03 +0800

It is a great job.
It lists many terms.
In order to have some words be understood by newbie of DNS, I think that adding the example for every term in the appendix will be another bonus.

For example,for the term of "zone cut"

     Zone cut -- The delimitation point between two zones where the origin
   of one of the zones is the child of the other zone. 

If there are some examples which show what the zone cuts are, that will be great.

Jiankang Yao

From: Paul Hoffman
Date: 2015-01-20 06:16
To: IETF DNSOP WG
Subject: [DNSOP] New version of the DNS terminology draft
Greetings again. Andrew, Kazunori, and I have done a massive revision on the DNS terminology draft based on the input we got on the -00. We're sure we have further to go, but we wanted people to look over the new version and give feedback. Thanks!