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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to