Subject: Re: [DNSOP] DNS terminology draft

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Apr 2015 11:21:13 -0700

On Mar 24, 2015, at 3:02 PM, Dave Lawrence <[email-masked]> wrote:

> EDNS / EDNS0 -- The Extension Mechanisms for DNS, defined by
> [RFC6891], are an addition to the original message format to allow DNS
> agents [which I acknowledge is not defined, but by which I mean to
> indicate "any software which speaks DNS"] 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 query.  EDNS can be versioned, but currently the only
> version in public use is EDNS0.

Yes, we clearly should define EDNS before we talk about OPT; done in the next draft.

> ECS / EDNS client-subnet -- An EDNS option principally for carrying
> information from a resolver to an authoritative server about
> the general network location of a client of the resolver.  This is
> generally used by full service resolves who serve clients from a
> diverse network topography to get response from authoritative servers
> that tailor their responses based on client location.
> 
> [This also seems to be missing as a commonly seen token:]

This seems premature given that the whole area is still under discussion.

> One thing that has been experience by many of us in different
> organizations, and which actually has shown its head within
> discussions with IETF people this week who are not in the DNS
> community, is that they very, very commonly think of the EDNS
> client-subnet option as being "EDNS0".  Those of us involved with ECS
> constantly try to educate people about this, especially since there
> are currently very few EDNS options and this is the only one that
> seems to be known by people outside of the DNS community.

That's a row you have to hoe on your own, I'm afraid. There are other EDNS options, and the document defining EDNS0 is not all that easy to understand as "this just gives us some extensions".

> RRTYPE [RRType?] -- A mnemonic or numeric value representing the type
> of data carried in an RR, as defined in [RFC1035] section 3.2, which
> impacts how its RDATA is interpreted.  The full set of assigned values
> is listed at [IANA reference].
> 
> RDATA -- The data portion of an RR, as defined in [RFC1035].  Its
> format and semantics varies by RRTYPE.

I'm hesitant to define all of the parts of a record from RFC 1035. Do we split out the subfields of RDATA? Do we also define "Answer section"?

Would it be valuable to just list all these "basic terms" from 1035 in one section, and say "read 1035 for the definitions"?

> PS: I tend to use NXRRSET as slightly more expressive than NODATA,
> though it is an extended rcode for dynamic update.  Worth mentioning
> along with the NODATA definition, or am I pretty much solo in using
> the term this way?

Done.

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 1 Apr 2015 23:16:36 -0400

Dave Lawrence:
>> ECS / EDNS client-subnet -- An EDNS option [...]

> This seems premature given that the whole area is still under discussion.

I have a mixed reaction to this, because I appreciate the point that
there is not yet an official RFC on the matter (though there is an
assigned option code).  Yet though the RFC is under discussion, it is
a protocol in active production use on the public Internet and people
who are not DNS people refer to it.

Then again, those people are also highly unlikely to ever read this
document so I'm not sure that putting it here is particularly helpful.
But a boy can dream.

Dave Lawrence:
>> people [...] very, very commonly think of the EDNS
>> client-subnet option as being "EDNS0".

Paul Hoffman:
> That's a row you have to hoe on your own, I'm afraid. There are
> other EDNS options, and the document defining EDNS0 is not all that
> easy to understand as "this just gives us some extensions".

Well yes, those of us who have to talk about it are already hoeing
that row, so "on your own" is actually several people I know who have
encountered the issue.  I'd think that "the document defining EDNS0 is
not all that easy to understand" would actually be an argument in
favour of clarifying the situation in this terminology document.

Ultimately though I am not really bent out of shape if you decide not
to include it.

> Would it be valuable to just list all these "basic terms" from 1035
> in one section, and say "read 1035 for the definitions"?

Sure, I'd be good with that.