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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
