[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [46.4.129.225]) 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? 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
- [DNSOP] Some comments on draft-ietf-dnsop-termino… Mukund Sivaraman
- Re: [DNSOP] Some comments on draft-ietf-dnsop-ter… Andrew Sullivan