On Wed, 8 Oct 2014, Tony Finch wrote:
Tim Wicinski <[email protected]> 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?
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.
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.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
