On 9 Nov 2015, at 8:55, Tony Finch wrote:
Paul Hoffman <paul.hoff...@vpnc.org> wrote:
On 9 Nov 2015, at 5:02, Tony Finch wrote:
The rationale for this document is still completely wrong. It does
not
provide any reduction in latency compared to the existing DNS
protocol.
Is that really true? That is, I assume that you mean the latency with
this
proposal is due to the recursive still having to go fetch all the
pieces.
No, I mean stub/recursive latency.
OK, but...
However, if the recursive already has some or all of the answers in
its cache,
this proposal reduces the latency compared to the stub asking for
each piece.
No, as I have explained at least twice before.
With the current DNS protocol, a stub resolver can get all the records
it
needs to validate a response in 1RTT, by sending multiple concurrent
queries for all the possible delegation points in the QNAME.
I'm confused. How does the stub know all of those ahead of time?
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
