Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-05.txt

From: [email-masked]
Date: Mon, 16 Nov 2015 23:05:37 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Chain Query requests in DNS
        Author          : Paul Wouters
	Filename        : draft-ietf-dnsop-edns-chain-query-05.txt
	Pages           : 16
	Date            : 2015-11-16

Abstract:
   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 reduction in queries lowers the
   latency and reduces the need to send multiple queries at once.  This
   extension mandates the use of source IP verified transport such as
   TCP or UDP with EDNS-COOKIE so it cannot be abused in amplification
   attacks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-chain-query-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Nov 2015 02:13:05 -0500 (EST)

On Mon, 16 Nov 2015, [email-masked] wrote:

> Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-05.txt

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-chain-query-05

This includes some textual changes based on Shumon's comments. It
includes the type code of 13 now that IANA has assigned it.

The examples had not been updated to contain the lowest included Closest
Trust Point introduced in -03.

The NS RRset inclusion for the chain was changed from MUST to SHOULD,
with an explanation that if size is an issue, these can be omited. This
should play more nicely with code re-use for the TLS extension to send
the CHAIN data.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Nov 2015 18:58:27 +1100

This example as the wrong length unless you want every from wire
reader to be re-written to not look for the root label.  Given the
comment about no compression pointers this should be wire format
not text format.

	"com." has length 0x05  (0x03 0x63 0x6f 0x6d 0x00)

o  The upstream Recursive Resolver adds the CHAIN option to the DNS
      response as follows:

      *  Option-code, set to 13

      *  Option-length, set to 0x00 0x04

      *  The Closest Trust Point is set to "com.".

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Nov 2015 19:04:44 +1100

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.

Why disabled on CD=1?  If you have the contents cached and validated
already what does it hurt to send the trust chain?  If you don't
have a element of the trust chain you can still fetch it and return
it unvalidated just using the signer names.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Nov 2015 04:58:20 -0500 (EST)

> it unvalidated just using the signer names.

If you ask for www.toronto.redhat.com with CD=1 and redhat.com's RRSIG's
are missing, do you still traverse down the chain to www.toronto.redhat.com?

Also, the upstream resolver might not want to serve any data below it.
How could it fetch a (bogus) chain for the answer without mixing up
these known bad records in its cache?

I thought it better to just not support it. But I could be convinced
otherwise.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Nov 2015 04:59:05 -0500 (EST)

>      *  The Closest Trust Point is set to "com.".

Thanks - I'll fix the example and double check the other ones as well.

Paul