Re: [DNSOP] draft-ietf-dnsop-edns-chain-query and draft-ietf-dnsop-edns-tcp-keepalive

[Tony Finch <[e-mail]>]

Paul Wouters <[e-mail]> wrote:
> On Wed, 8 Oct 2014, Tony Finch wrote:
> > Tim Wicinski <[e-mail]> wrote:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/
> >
> > I do not think this protocol extension is necessary.
> >
> > I have previously described how you can get the same round-trip
> > performance by sending queries for all the chain records at once:
> > http://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html
>
> That doesn't help a stub resolver much. Do you really want the resolver
> logic of gathering all this data in asynchronous queries to be in libc?

You don't need any asynchronous code to send concurrent queries. If you
are using a TCP socket you don't even need to select(). Just write out the
queries then read the replies.

(You only need to go async if you want to be concurrent with other
activity in the program, in which case it isn't relevant to compare with
the non-async libc resolver.)

> > The performance problem that EDNS chain queries are trying to fix is an
> > problem with existing server implementations, NOT a protocol limitation.
> > Both BIND and Unbound fail to handle queries concurrently when they arrive
> > over one TCP connection.
>
> this extension allows a significant resource saving when used on mobile
> phones.

Yes, I pointed that out in the article linked above. But EDNS chain
queries only reduce the data sent and received, not the number of round
trips. The maximum number of round trips required is two, with or without
EDNS chain queries.

Note that the numbers I was working with did not include NS RRsets. If you
add those in as required for EDNS chain queries, then I guess you will not
actually be winning.

Perhaps a more useful option would be to request minimal responses.

> > It would be much better to spend time working on fixing these bugs instead
> > of adding complexity to the protocol.
>
> What is the complexity? It's not introducing any new formats, no new
> record types, and just an edns option you can ignore if you don't want
> it? The complexity is in the upstream resolver picking up all the right
> entries. The client is clean and simple. Send one packet, get a nicely
> validatable answer back.

The client needs to negotiate support and keep track of which servers
provide it or not.

The EDNS chain query option doesn't include enough information for the
server to optimize its response correctly if the answer is a CNAME or MX
etc. to a different zone (e.g. under a different TLD).

It isn't clear to me if including NS records in the response makes sense
as the default behaviour. Maybe it does for roaming clients (like Unbound
/ DNSSEC-trigger) that switch back and forth between forwarding and
iterative resolution, but if you have a forwarding-only resolver it is
just waste. You could make it optional - or you could just remove the
feature and if the client wants NS records it can ask for them using a
separate query.

But all of these questions disappear, and you get negligible loss of
performance, if the client sends concurrent queries for just the records
it needs.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.