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.
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? As chain queries give
you all the required validation data in one round trip, how will you do
the same without sending an excessive amount of queries and then still
needing so send another wave of those if there is a CNAME/DNAME? How
would you break even accomplishing 1 RTT (assuming that when you say
"win" you don't mean less than 1 RTT :)
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.
On the stub, the client would use the assigned forwarders only. So it
just needs to remember if its current one or two resolvers support this
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).
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.
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.
That is something we could discuss. It might be that the gains for NS
records are not worth it. I am not sure yet either way.
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.
In the case of the caching itterative resolver, that might make sense.
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.
See above. I disagree that rapid-fire is desirable over sending a single
query. And I did not yet see how you can achieve this in roughly 1 RTT.
Additionally, those that prefer rapid-fire can already do so and not use
query-chain.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
