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

Andrew Sullivan <> Tue, 14 November 2017 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89CA4129484 for <>; Mon, 13 Nov 2017 23:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=nQpIHioF; dkim=pass (1024-bit key) header.b=Pn1zQyV5
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ndPQn8tJfWcd for <>; Mon, 13 Nov 2017 23:58:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AFA91292C5 for <>; Mon, 13 Nov 2017 23:58:45 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D86FBF56B for <>; Tue, 14 Nov 2017 07:58:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1510646294; bh=jtiAcoWJd9fVkKeUxCWZV7v/VL3wwXW7hkdR98bmXMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nQpIHioF7rdJmwfZwNf4AmFdQKEWMkYS2Co7osawKelgUtzKTqDoB2mLxNt3pHCSn X3Oggg+1sp7+Y7e+pr8nTRV0R1ILMHMneOoixhV44GycWoC5j3T6S7Ts46VolHZfiG B5bALfj59N3yYRmJH+A2EwfQ2oUdHVVzcyLjowRg=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tb8ffyAnvy2e for <>; Tue, 14 Nov 2017 07:58:12 +0000 (UTC)
Date: Tue, 14 Nov 2017 02:58:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1510646292; bh=jtiAcoWJd9fVkKeUxCWZV7v/VL3wwXW7hkdR98bmXMU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Pn1zQyV5/HN+WQHz8wPoS7pNUQ4dr4oS/dps5sIYm4mt2JecYwhhM8xzwvSvrkc+2 wz71fnUeqKA4E8TaOzFL2nV7kGByNBQpnl3O2W9PGdrcYxDJy7P/aAUTk191lhwUwO eezKcvD9Cz9iZqtmW53bu3aJfmOOolc1eOcl1rmU=
From: Andrew Sullivan <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2017 07:58:46 -0000


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

    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

> * Chain-of-trust (in DNSSEC)

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

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

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?


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


Andrew Sullivan