Paul Wouters <[email protected]> wrote: > 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?
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 <[email protected]> http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
