Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query

"Joe Abley" <> Mon, 02 November 2015 15:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACCAA1B48BC for <>; Mon, 2 Nov 2015 07:45:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Icu8-ow-zVzC for <>; Mon, 2 Nov 2015 07:45:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 887551B48BD for <>; Mon, 2 Nov 2015 07:45:23 -0800 (PST)
Received: by igpw7 with SMTP id w7so50905296igp.1 for <>; Mon, 02 Nov 2015 07:45:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=/iiD5fldFSeq/2nQTKM0fLCOD5WyHHu4xT6Cy+L0Nbo=; b=NzIHAIyzTikEtO4GUg5QPlxUpH9pSQZovLAlGnvqTxAWX10u6UI71+Fy5t1VRqMLyd APul5z36CDCVprbc2IBVjuamJJUfNJSfjKbMrHLHg8YSfhrK37WDZuVXz6I9x6UE2blB zXaMyZ7mHW9b1gUMUQWUfgJcx0QXH/KyOvxq0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=/iiD5fldFSeq/2nQTKM0fLCOD5WyHHu4xT6Cy+L0Nbo=; b=JpnPpe+6YT/BnD2REJQbBRLPE3KJtDt5ZrfaIjBF6t290IUmMbmtDIKgK8SbuuZSzx 4JZcUWcyK8g1EKCdPwrvwZ5qDpeMVtRRFV+XhlY6RKbBRE9Res+DE6qTWs/H/4jfjrSG 268L6MXAvQQ0qrKBUajhORDm8iVLebuehpMHNDM55DRpyTcf218LuOVYUZxSBSuDttN5 C1tawcNwDHclk5aNpWc0Mjyra4wI0tid/wJw/6+ZltmpocCZF+1B1bpd13h0iRvAkJ7z Vt5we0NpajLuqMqUoa5Z/irBZpjQQWDWn4tB1BK0V6JW6TDjrhFb0MTAdruFCNkD9oig yY7g==
X-Gm-Message-State: ALoCoQl1DeQejgaVRU6vuQ9OP5RwCRLpZXEKkFCxftSLSIG3/G2rDO66ZvzGNjubvJA6rhPm3OeB
X-Received: by with SMTP id y7mr12304431igp.34.1446479122867; Mon, 02 Nov 2015 07:45:22 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id ij6sm5943967igb.1.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 02 Nov 2015 07:45:22 -0800 (PST)
From: Joe Abley <>
To: Tim Wicinski <>
Date: Mon, 02 Nov 2015 10:45:20 -0500
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5141)
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-chain-query
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2015 15:45:25 -0000

On 1 Nov 2015, at 3:36, Tim Wicinski wrote:

> This starts a Working Group Last Call for
> 	draft-ietf-dnsop-edns-chain-query
> Current versions of the draft is available here:
> Please review the draft and offer relevant comments. Also, if someone 
> feels the document is *not* ready for publication, please speak out 
> with your reasons.

I have read this document and believe it needs a bit more work. Sorry 
for not reviewing this document earlier (e.g. before the wg last call).

> Currently the document is marked “Standards Track”, but due to 
> lack of implementations at this time (though some are being worked), I 
> am suggesting we apply the “Experimental” label to this.  The 
> working group is welcome to chime inhere.

According to RFC 2026 section 4.1.1, "Proposed Standard":

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has 
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable, and will
    usually represent a strong argument in favor of a Proposed Standard

I don't think a lack of implementation reports should be a deal breaker 
for proposed standard. No doubt our illustrious AD could shed some light 
here, however, since I am far from familiar with this stuff.



The introduction and overview are littered with phrases like 
"stub-mode", "DNS client" and "host" that, because of the nineteen 
different varieties of name server we have to deal with come across as 
ambiguous. Worse, there are different world-views about DNSSEC 
validation on end hosts, e.g. those that trust an unsigned AD bit, 
expecting validation to occur upstream, and those who do validation 

I think the context of the whole document would be much easier to grasp 
for a new reader if there was a clear diagram as close to the top of the 
text as possible that clearly outlined the precise deployment scenario 
we're talking about. I realise there is plenty of text that describes 
the use case here, but starting with a picture I think would be a great 
kindness to the reader.


The "Closest Trust Point (FQDN)" field in the EDNS(0) option as 
described in section 4 is a bit vague, I think. You're talking about an 
owner name, but you don't mention that phrase; you talk about "lowest" 
without context (is the root at the top or the bottom?) You don't 
specify the encoding of the owner name; I think it's natural to assume 
that it's a series of run-length encoded labels with a zero-length label 
indicating the end, but as written it could be taken as being in 
presentation format with a trailing dot (a nod to the use of "FQDN" 
which is generally in presentation format).

I have some reservations about the idea of inferring capabilities based 
on previous experience interacting with a server at a particular 
address. Authority servers are frequently built in clusters, and the 
origin server that responds to one query at one address might be 
different from the one that responds next time. Similarly, clients are 
frequently deployed behind NATs, and inferring capabilities based on 
source address there seems like a bad idea.

More fundamentally, I'm not sure I understand the benefit of 
capabilities discovery. A client surely should add the option to all 
queries; if it gets useful information back in the response it can use 
it, and if it doesn't, it has to re-query along the chain anyway. If the 
concern is related to dealing with servers that don't deal with unknown 
EDNS(0) options correctly, then I think the preferred approach would me 
to let them fail, forcing operator intervention on one or both sides.

Aside from capabilities disovery, I'm not sure what the purpose is of a 
server including the CHAIN option in a response. The sections in the 
response will either contain additional, useful information or they 
won't -- it's not clear to me what benefit the CHAIN signalling from 
server to client provides.

Section 5.4 indicates that extra RRSets included because of CHAIN 
processing should be included in the authority section. Wouldn't the 
additional section make more sense, except in the case of RRSIGs over an 

Section 6.4 contains the intriguing word "partian" that I had not 
encountered before, although I have to say I like it.

Section 8.1 uses the phrase "source IP address verification" which is 
vague. Do you mean that the implementation needs to have convincing 
indications that a query is not spoofed, e.g. by using DNS cookies? Or 
do you mean that the server should not be an open resolver? Or that if 
it's an open resolver, it should be operated mindful of the fact that 
there is amplification potential?