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

[Paul Wouters <[e-mail]>]

On Tue, 6 Oct 2015, Shane Kerr wrote:

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

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

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

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.

> * 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:

I clarified it to be always.

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

done.

> * 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!)

That is what I meant. I clarified the text.

> * I don't understand the motivation for keeping query size to less than
>  512 bytes.

I removed that text.

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

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.

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

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

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

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

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

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