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

[Tony Finch <[e-mail]>]

Paul Wouters <[e-mail]> wrote:
> On Tue, 10 Mar 2015, Tony Finch wrote:

> > > All of those require round trips.
> >
> > No they do not. Please stop repeating this falsehood.
>
> paul@bofh:~$ sudo unbound-control flush_zone nohats.ca
> paul@bofh:~$ dig a +dnssec www.nohats.ca @127.0.0.1

Oh come on, surely you understand the difference between a protocol
requirement and an implementation artifact.

I agree that current validators use too many round trips, but that is not
because of problems in the protocol.

> > > 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.
> >
> > Or you can use TCP and send the whole lot in a single packet.
>
> Yes, that is what this draft recommends. Are you agreeing with me?

Sorry, by "send the whole lot" I mean the client can bundle up half a
dozen queries (each a separate DNS message) into one TCP packet.

Most existing recursive servers will process these queries serially, but
as Mark Andrews pointed out, if you send the original query before the
queries for the DS+DNSKEY chain, the first query will prime the cache so
the later queries can be answered immediately, for a 1RTT response.

> Sending a number of queries, and then when finding out you are still
> lacking some information, sending out another number of queries, is
> not the same as sending 1 query and getting a dns answer packet back
> that in itself completely validates.

But with the existing DNS protocol you can send out queries for everything
you need up front. If you use edns-chain-query there are still situations
where you have to ask follow-up queries, in pretty much the same cases as
without the extension.

You can implement the API you want without edns-chain-query.

I have looked at several validators, and they all have network logic
intertwined with the validation logic. None of the ones I looked at
currently have a function which can take a chain of RRsets and validate
them, the kind of function edns-chain-query would need. Once you have such
a function it's fairly easy to do 1 RTT query and validation without
edns-chain-query, and you want to do that anyway for compatibility with
old servers.

> > > 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?
> >
> > Well, it would fix an omission.
>
> Should the draft list those RRTYPEs it should consider including?
> If so, should the draft list these in weighted order?
> Does this include _prefix locations? (eg like for TLSA)
> Which records do you think should be considered?

You misunderstand what I mean. I am not suggesting adding answers for
questions that were not asked. I mean dealing with situations where the
DNS protocol (ignoring DNSSEC) requires follow-up queries that the client
cannot predict in advance, and which therefore require a second round
trip.

For example, if I ask for:
  dotat.at in mx ?
I may have to make follow-up queries regarding the target of the MX
record(s), and they have to be a second round trip.

This also applies to CNAME, DNAME, SRV, NS, maybe others.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
South Utsire, Southeast Forties: Southwesterly 4 or 5, becoming variable 3 or
4, then southeasterly 6 to gale 8 later. Moderate or rough. Fair. Good.