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

[Andrew Sullivan <[e-mail]>]

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.

> * 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.

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

> 
> * 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.)

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 ;-)

> * Truncated message (I feel it's important to describe it and what
>   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"
>   NXDOMAIN?)

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?

> * 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.

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

A

-- 
Andrew Sullivan
[e-mail]