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

Shumon Huque <> Mon, 09 November 2015 12:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A22E01AD378 for <>; Mon, 9 Nov 2015 04:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GX_D3JjYBk7l for <>; Mon, 9 Nov 2015 04:06:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E3681AD35B for <>; Mon, 9 Nov 2015 04:06:17 -0800 (PST)
Received: by qgeb1 with SMTP id b1so87651996qge.1 for <>; Mon, 09 Nov 2015 04:06:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5RiTj9Mpt9xaa62joOOM+mR2oT7OBt0evKq9v9Da64=; b=R/93+vNGL5nxX6VhZeIXdPkublxNRsWfqQXO8MAx2+A0hgneMaUWnLcdW5UAPd2Soe yItfuoezOO4JVvu8ZAj8lZyjEIMoJ+TpPpg6+GhHxaYeLtZVdGD6PNrH5CJyEO3FMZpK Sg9iNyEX4LBBFnuyYE0obuQJ/8xD8sK3jticergMK4WfUARWIeOMtkLabqTTqK1C+NTA 6ttULbq8cjV7MxR/a6FOV1/p3J7iSmHYCOmiVvXidWJiyqUBT4G4J5mZhvfq8Tkqo26D HX+G6nRgzC8WPlvREsYlan1TtlcmQ4xQ1s4p8PxT85OHLOCR5hXCFbQ+XwmVn2BELPOZ o5jw==
MIME-Version: 1.0
X-Received: by with SMTP id a106mr28183606qgf.19.1447070776556; Mon, 09 Nov 2015 04:06:16 -0800 (PST)
Received: by with HTTP; Mon, 9 Nov 2015 04:06:16 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Mon, 09 Nov 2015 21:06:16 +0900
Message-ID: <>
From: Shumon Huque <>
To: Tim Wicinski <>
Content-Type: multipart/alternative; boundary="001a1134f6d69a042f05241a6b21"
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, 09 Nov 2015 12:06:30 -0000

On Sun, Nov 1, 2015 at 5:36 PM, Tim Wicinski <> wrote:

> Hi
> The authors have updated their document to address all outstanding issues,
> and we feel the document is ready for Working Group Last Call.
> 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've read this document and think it proposes a useful capability.

I also have a practical use for an option like this - the TLS dnssec
chain extension that I'm involved in. Server implementations of that
extension could use the EDNS chain query capability to more efficiently
build the authentication chain returned to the TLS client.

Some other quick comments:

> This document specifies an EDNS0 extension that allows a validating
> Resolver running as a Forwarder to open a TCP connection to another
> Resolver and request a DNS chain answer using one DNS query/answer
> pair.

The definition of "Forwarder" being used here conflicts with the
definition in existing DNS protocol documents (e.g. RFC2308) and
also in the new draft-ietf-dnsop-dns-terminology document.

For what it's worth, I prefer the reversed definition this draft is
using which is much more logical, but I think it's important that we
use an agreed upon term or reconcile this in some other manner.

> Closest Trust Point, a variable length FDQN of the requested start
> point of the chain.

FDQN --> FQDN. But it is probably worth being more explicit. I assume
you mean a fully qualified domain name in DNS wire format.

> 5.4.  Generate a Response
> When a query containing a non-zero CHAIN option is received from a
> Forwarder, the upstream Recursive Resolver supporting CHAIN MAY
> respond by confirming that it is returning a CHAIN.  To do so, it MUST
> set the CHAIN option to the lowest Trust Point sent as part of the
> chain, with its corresponding OPTION-LENGTH.  It extends the Authority
> Section in the DNS answer packet with the DNS RRsets required for
> validating the answer.  The DNS RRsets added start with the first
> chain element below the received Closest Trust Point up to and
> including the NS and DS RRsets that represent the zone cut
> (authoritative servers) of the QNAME.

To follow-up on in-person discussion that happened at the last dnsop
meeting, this last sentence seems to imply an ordered sequence of RRsets
in the authority section comprising the chain. Since consensus is
against introducing ordering of RRsets in DNS message sections, this
should probably be reworded.

> A DNS query that contains the CHAIN option MUST also have the DNSSEC
> OK bit set.  If this bit is not set, the CHAIN option received MUST
> be ignored.

What is the expected behavior if the requestor sets the CD bit?

> 6.2.  NS record Considerations
> CHAIN responses MUST include the NS RRset from the child zone
> including the RRSIG records required for validation.
> When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer
> required to use the NS RRset, as it can construct the validation path
> via the DNSKEY and DS RRsets without using the NS RRset.  However, the
> Forwarder might be forced to switch from Forwarder mode to Recursive
> Resolver mode due to a network topology change.  In Recursive Resolver
> mode, the NS RRsets are needed to find and query Authoritative Servers
> directly.  It is RECOMMENDED that the DNS Forwarder populate its cache
> with this information to avoid requiring future queries to obtain any
> missing NS records.  Therefore, CHAIN responses MUST include the NS
> RRset from the child zone, including the RRSIG records required for
> validation.

What is meant by "the NS RRset from the child zone"? Should this be the
NS RRset of the zone containing the queried name?

I understand the stated rationale for including NS RRsets. On the other
hand this makes it less likely that the TLS chain extension would use
this message format (because of size considerations) rather than its
current format of a sequence of RRsets (a discussion that is happening
around that draft).

Shumon Huque