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

[Paul Wouters <[e-mail]>]

On Mon, 9 Mar 2015, Tony Finch wrote:

> The justification in the introduction is misleading:
>
>   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.  This reduces the number of round-trip times ("RTT") to two.
>   If combined with long livd TCP or [TCP-KEEPALIVE] there is only 1
>   RTT.
>
> Without this extension the typical number of RTTs required is 1, so this
> isn't a reduction.

When you have nothing of nohats.ca in your cache, and you ask for the
A record of www.nohats.ca, you will normally get back the A record
and the RRSIG. Then you need to query for the DS, DNSKEY, etc etc. And
then for the DS, DNSKEY et all of the parent, the parents parent, etc.
All of those require round trips. Yes you can blindly send a bunch of
parallel udp queries on every dot and hope the last one you need didn't
take too long or drop. Clearly this extension provides a more robust
way of doing this. The interface is clean, and you get all you need
in a single DNS packet.

>                                           There is also no guarantee
>   that the initial set of UDP questions will result in all the records
>   required for DNSSEC validation.  More round trips could be required
>   depending on the resulting DNS answers.
>
> With this extension you still require 2 RTT if the target is SRV or MX,
> and maybe if it is CNAME or DNAME depending on how much the server decides
> to return. Maybe it requires 3 RTT if the server decides it doesn't like
> doing chain queries any more.

I'm happy to add a section of recommendations for adding common "related
records" such as IPSECKEY, TLSA, SSHFP or what not. It does mention
CNAME/DNAME and I'm happy to add an entry about SRV and MX. Would that
address your concerns?

> It occurs to me that you could get a lot of edns-chain-query's bandwidth
> saving with a simple "minimal responses please" query flag.

This is not about bandwidth saving.

Paul