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

Mukund Sivaraman <muks@isc.org> Tue, 14 November 2017 07:09 UTC

Return-Path: <muks@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A7AAF126C25 for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 23:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id y41Es4MjLJ0v for <dnsop@ietfa.amsl.com>; Mon, 13 Nov 2017 23:09:46 -0800 (PST)
Received: from mail.banu.com (mail.banu.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5D286124205 for <dnsop@ietf.org>; Mon, 13 Nov 2017 23:09:46 -0800 (PST)
Received: from ponyo.lan.banu.com (unknown [IPv6:2001:67c:370:128:ab3f:8762:ac2a:7f00]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id A4AEB56A0309; Tue, 14 Nov 2017 07:09:44 +0000 (GMT)
Date: Tue, 14 Nov 2017 15:09:39 +0800
From: Mukund Sivaraman <muks@isc.org>
To: dnsop@ietf.org
Message-ID: <20171114070939.GA19501@ponyo.lan.banu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LXXQbQ03m1BkQLzCFiA6mZaeD1Y>
Subject: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Nov 2017 07:09:48 -0000

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?


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

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