Subject: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 14 Nov 2017 15:09:39 +0800

I haven't done a full review, but want to. Please answer this first: The
terminology document seems to contain both easy and hard-to-come-by
definitions. Without knowing what to filter, I keep getting a large
vocabulary of DNS phrases to propose but I don't know if they belong in
this terminology document. Is any DNS phrase acceptable?

Examples:

* DNS indirection (a phrase also used in the infamous iDNS
  attack.. lookup of name leads to lookup of nameserver's address
  nsname1/A, which leads to lookup of another nameserver's address
  nsname2/A), etc.

* Cache (explanation of what a cache is, what it contains, how long the
  cache may be expected to store data, whether it is strongly coupled to
  authoritative data, etc.)

* Chain-of-trust (in DNSSEC)

* Owner name (of RRs)

* Truncated message (I feel it's important to describe it and what
  happens due to it, as it's a commonly seen occurrence)

* DNS continuation (e.g., the sequence of AXFR messages)

* Inline signing

* Stub zones (it's a feature available from multiple implementations,
  but not clearly explained in most documentation)

* DNS class (what is it good for? :)

* Notification

* DNSSEC lookaside validation (though ISC's DLV service is "off", the
  protocol itself is not)

* Kaminsky attack (why not mention this phrase that's used to identify a
  DNS poisoning attack?)

* DNS cookie

* Key rollover
* Wire format

* DNS64
* RPZ
* RRL
* Prefetching

I'll be happy to contribute definitions if you select any phrases to
include. And also more DNS terms if it's clear what can be included.

----

Some comments:

* Negative response - shouldn't this also include "name doesn't exist"
  NXDOMAIN?)

* Reverse lookup - is it worth mentioning PTR here?

* Occluded name - This is not limited to DNS UPDATE and introduction of
  DNAME. It _can_ also occur via regular zone loading process, if the
  parser allows non-address "glue" (the wider use). I think it isn't
  strictly specified that such occluded records should be rejected
  during zone load.

		Mukund

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Nov 2017 02:58:06 -0500

Hi,

Speaking only for myself and not the other editors:

On Tue, Nov 14, 2017 at 03:09:39PM +0800, Mukund Sivaraman wrote:

> The terminology document seems to contain both easy and
> hard-to-come-by definitions. Without knowing what to filter, I keep
> getting a large vocabulary of DNS phrases to propose but I don't
> know if they belong in this terminology document. Is any DNS phrase
> acceptable?

Maybe :) The editors will of course do whatever the WG consensus is.
Still, the point is not, IMO, to cover every term that has to do with
the DNS in any context, and if a term is not used except in a given
context I'd expect familiarity with that part of the protocol to be
enough unless the terms are otherwise poorly defined.  The genesis of
the document was in part, at least for me, irritant terms:

    1.  There were terms that I would trip across even though they were
    well-documented (nobody would bother to look them up), and I
    wanted an easy thing to point to.  Usually these were terms that
    were used badly or carelessly (sometimes by people who were
    obviously pretending to know what they were talking about).

    2.  There were terms that got thrown around all the time, and when
    someone would ask me the meaning I found I didn't have a good
    reference, but I knew perfectly well that everyone knew what was
    meant.

    3.  There were terms that I was afraid were being used ambiguously
    or even equivocally.  Some of these haven't made the cut yet :)

I don't know whether Paul's and Kazunori's inspirations were the same.
I think in general though the WG has attempted to include terms that
are in wide enough use and sufficiently DNS-specific so as to be
appropriate for processing through the DNSOP WG.

>   nsname1/A, which leads to lookup of another nameserver's address

I am not sure I have ever heard this term, so I can't tell whether it
ought to be included.

>   authoritative data, etc.)

Probably the general term cache doesn't need explaining, but it's true
that 7719 has a lot of mentions of caches without saying what they
ought to have, and I'm not sure the older RFCs are too clear about
this.

> * Chain-of-trust (in DNSSEC)

Is this a DNS-specific term?  I think it's pretty common in PK crypto,
no?

> * Owner name (of RRs)

Already there ;-)

>   happens due to it, as it's a commonly seen occurrence)

If you have proposed text, I can maybe see a spot for this.

> * DNS continuation (e.g., the sequence of AXFR messages)

There is a pretty exhaustive AXFR document, and this only comes up in
that context, right?

[…]
 
> * DNS class (what is it good for? :)

Absolutely nothing, say it again.  I offered a draft about this a
while ago and got enough push back that I gave up.  I am not convinced
that a terminology draft could tackle the definition of class in STD
13 without attempting to alter the meaning, myself.

> * Negative response - shouldn't this also include "name doesn't exist"

It does, no?  We don't reproduce the stuff to which we refer: you're
supposed to follow those referrals, just like a resolver ;-)

> * Reverse lookup - is it worth mentioning PTR here?

Text?

>   strictly specified that such occluded records should be rejected

This sounds like a somewhat wider definition.  I'd like to see text
and strong WG support before it gets included.

A

-- 
Andrew Sullivan
[email-masked]