On Sun, Nov 1, 2015 at 5:36 PM, Tim Wicinski <tjw.i...@gmail.com> 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: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ > > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
