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

[Paul Wouters <[e-mail]>]

On Mon, 9 Nov 2015, Shumon Huque wrote:

> I've read this document and think it proposes a useful capability.

Thanks for your feedback Shumon! (I think you read -03 and not -04)

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

I've changed the text to:

             This document defines an EDNS0 extension that can be used
             by a security-aware validating Resolver configured to use
             a Forwarder to send a single query, requesting a complete
             validation path along with the regular query answer.

(the text was already somewhat changed from before)

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

Done.

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

Added:

 	The added RRsets MAY be added in matching hierarchical
 	order but a DNS client MUST NOT depend on the order of the
 	added RRsets for validation.

> > 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?

Text changed to:

             A DNS query that contains the CHAIN option MUST also have
              the DNSSEC OK ("OK") bit set. If this bit is not set,
              or if the Checking Disabled ("CD") bit is set, the CHAIN
              option received MUST be ignored.

> > 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?

The NS RRset lives at the child (authoritative and signed) and at the
parent (unsigned glue). We want the signed set, not the unsigned set. I've
changed the text.

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

Okay, I've reworded it and loosened the MUST to a SHOULD unless space considerations
are important:

            CHAIN responses SHOULD include the NS RRset from the zone itself
            including the RRSIG records required for validation. It MUST
            NOT include the NS RRset from parent zone, as this RRset is
            not signed. If the size of the answer is an important factor,
            the NS RRset MAY be omited.

Paul