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

From: [email-masked]
Date: Sat, 03 Oct 2015 13:37:53 -0700

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-03.txt
	Pages           : 15
	Date            : 2015-10-03

Abstract:
   This document defines an EDNS0 extension that can be used by a
   security-aware validating Resolver configured as 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.
   This extension requries the use of source IP verified transport such
   as TCP or UDP with DNS-COOKIES 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-03

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

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: Shane Kerr <[email-masked]>
Date: Tue, 6 Oct 2015 15:05:06 +0000

Paul,

> 	Filename        : draft-ietf-dnsop-edns-chain-query-03.txt

I think this draft makes sense - I like it. I see it was updated with
basically no updates. Here are some thoughts.

* Possibly running through a spell-checker would be useful, although
  not super important.

* I note that the terminology section has been superseded a bit by the
  terminology draft, now approved for an informational RFC. I didn't
  follow that work too closely, but I notice that that document
  declares that "validating resolver" is referred to but not defined
  anywhere... and then uses the term "validating resolver" later in the
  document! :P

  Anyway, the soon-to-be-RFC still doesn't seem to define the two terms
  you want, so you may be stuck with defining them.

  You may want to also use "Forwarder" rather than "DNS Forwarder", as
  that seems to be what is in the terminology draft.

* It's not clear whether answers should always be limited to TCP or
  something like DNS cookies, or whether this is only for answers more
  than 512 bytes. I assume always, but this text implies only sometimes:

   Servers answering with chain query data exceeding 512 bytes should
   ensure that the transport is TCP or source IP address verified UDP.
   See Section 8.  This avoids abuse in DNS amplification attacks.

  Just remove "with chain query data exceeding 512 bytes" and it should
  be fine.

* I guess that the "Last Known Query Name" disallows compression as
  part of a general rule for queries. That's fine. It might be
  worthwhile changing "No compression is allowed for this value." to
  say "No DNS name compression is allowed for this value." just to be
  completely clear.

* The discovery mechanism seems to imply that a DNS Forwarder that has
  not done discovery MUST NOT use this option. My own feeling is that
  this is not true (a forwarder could just add the option to the first
  packet and do just-in-time discover, as it were). Perhaps this should
  be clarified? (Reading forward to section 5.3 shows that this is
  actually discussed!)

* I don't understand the motivation for keeping query size to less than
  512 bytes. I guess because there is no way in the protocol to
  specify support for larger query packets? It is a very rare case (I
  guess when the header+QNAME+EDNS option have long QNAME and long entry
  point), and seems unlikely to hurt anything in practice. If one
  wanted to be extra careful it could specify that UDP packets SHOULD
  limit packet size to 512 bytes - certainly this is unlikely to harm
  anything in TCP? (I suppose it is possible, but I'd like a check of
  a few popular servers before I am convinced. I suppose I can do this
  if you'd like...)

* I'm not sure about handling large responses. The advice seems to be
  to to send a REFUSED response. Should a client try again without the
  EDNS option? There are other reasons for REFUSED, and maybe it makes
  more sense to have a way for a resolver to signal to the forwarder
  the reason for the refusal, so the forwarder knows this is the best
  way to react.

* There doesn't seem to be advice for a resolver when support for Chain
  Query is disabled when it was previously working. Probably something
  like "A resolver MUST handle the case where a Chain Query does not
  return the full chain. It MAY change resolvers in this case. It MAY
  periodically attempt to try getting a Chain Query at that server."

* A comment: It is possible for DNSKEY and RRSIG to time out at
  different intervals (and DS, I suppose), right?. It seems that this
  will result in a bit of extra data now and then, the resolver needs to
  specify an entire "last known query name". I think this is okay, but
  it might be possible to avoid this by specifying which particular
  records are needed. Probably that is unneeded complication for this
  case.

* A wayward thought: this technique reveals a small amount of
  information about the cache on the forwarder side in the "last known
  query name". Maybe not worth mentioning because this is basically
  irrelevant when compared to, well, all the DNS resolution the
  resolver is doing?

Anyway, I support it moving forward with or without any changes.

Cheers,

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Tue, 6 Oct 2015 11:40:58 -0400

> basically no updates. Here are some thoughts.

Thanks for the review Shane.

I also received a review by Evan Hunt, so I'm planning to do a real update later this week.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Oct 2015 19:51:36 -0400 (EDT)

>> 	Filename        : draft-ietf-dnsop-edns-chain-query-03.txt

I've updated the draft based on your review and that of Evan Hunt.

>  that seems to be what is in the terminology draft.

I've cleaned this up a bit, and will try to find PaulH tomorrow to talk
about the lack of a term for full resolver.

>  than 512 bytes. I assume always, but this text implies only sometimes:

I clarified it to be always.

>  say "No DNS name compression is allowed for this value." just to be

done.

>  be clarified? (Reading forward to section 5.3 shows that this is

That is what I meant. I clarified the text.

>  512 bytes.

I removed that text.

>  the reason for the refusal, so the forwarder knows this is the best

Evan suggested returning partial chains, from the top down, so clients
can send multiple requests to gain the complete chain. The answer now
also contains the lowest trust point included in the CHAIN answer. So
that should address this issue.

>  periodically attempt to try getting a Chain Query at that server."

I didn't address this yet. Isn't this more of a local implementation
kind of thing?

>  records are needed. Probably that is unneeded complication for this

Evan suggested I define the Trust Point as the lowest FQDN for which you
have both DS and DNSKEY records, so that case should be covered now.
I don't think DNSKEY and RRSIGs can have a different TTL? But if they do,
then I guess the resolver will define that as "not having a validated
copy".

>  irrelevant when compared to, well, all the DNS resolution the

I did not any text for it. It's true it could leak some data if it
used more than one resolver to feed its cache, but it's pretty
arbitrary. the privacy leak is using the forwarders, whether it is
one or more.

> Anyway, I support it moving forward with or without any changes.

Thanks!

Paul

---

From: Shane Kerr <[email-masked]>
Date: Fri, 23 Oct 2015 16:56:19 +0200

Paul,

On Mon, 19 Oct 2015 19:51:36 -0400 (EDT)

> I've updated the draft based on your review and that of Evan Hunt.

Cool!

Noticed a typo:

s/partian/partial/

> I didn't address this yet. Isn't this more of a local implementation

I guess? I'm not opposed to helping implementors by dropping some MAY
statements in the RFC. "Here's some stuff you're going to need to
deal with." But I certainly won't push for this.
 
> then I guess the resolver will define that as "not having a validated

Okay, seems clear enough.

Over all it looks quite excellent! :)

Cheers,

--
Shane