Paul Wouters <p...@nohats.ca> wrote: > On Wed, 8 Oct 2014, Tony Finch wrote: > > > > 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. > > If you keep the TCP connection open, for chain query it would be a > maximum of one round trip. I am not sure how you are saying you can do > all the work in parallel, when you do not know beforehand how many CNAME > or DNAME contstruct will appear in your queries and when you have no > cache other then the root key. Unless you are going to break up on every > dot and send all those packets in parallel.
Yes exactly, as I explained in my article from last October. Note that when you get a response involving a CNAME from a recursive server, you get the whole CNAME chain, so you can get all the validation chains in a second round trip. EDNS chain queries also require this second round trip, unless they waste space by eagerly sending all the CNAME validation chains in the first response. But if you send them eagerly you are wasting radio time and battery charge if the client has them in its cache. > > 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. > > I do not understand this at all? Can you clarify? See the numbers in my previous article. The savings from EDNS chain query were quite large in my example because I chose a deeply nested domain with some non-zone-cut labels. If you have a domain of a more common length and you pad the response with NS RRsets then I doubt EDNS chain queries will save much compared to concurrent standard queries. > > 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). > > I think it does. It can add the required records in the additional > section so that the dns answer packet contains all the components > required for validation. When I say "not enough information" I mean the "last known" name isn't enough for the server to both eliminate wasted validation chains and eliminate second round trips. Say I visit www.ietf.org, and I send an EDNS chain query with a "last known" name of org. The server can either send back just the DS+DNSKEY for ietf.org, or it can also include the whole validation chain for cdn.cloudflare.net. If it sends the short response, I might need to send another query to get Cloudflare's validation chain. If it sends the long response it might be wasted effort if I already have it cached. There is no way I can anticipate what the target of the CNAME is, so there's nothing useful I can add to the EDNS chain query to avoid the wasted effort. There is no way the server can anticipate what is in my cache so it can't avoid sending too little or too much data. > Additionally, those that prefer rapid-fire can already do so and not use > query-chain. Exactly. Tony. -- f.anthony.n.finch <d...@dotat.at> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
