On Wed, Dec 05, 2018 at 10:22:49PM +0530, Mukund Sivaraman wrote:
> Nod, HTTPS has demonstrated that TLS can be scalable (even more so in
> recent years) and DNS is not different in this aspect. This is one
> aspect for protocol selection. I also worry about roundtrips in
> recursive resolution. If a message security scheme can somehow work as a
> stateless request-response protocol where prior state establishment is
> not necessary, it can reduce time to respond to queries comparable to
> traditional DNS. This was not a problem for stub->resolver transport
> where processing a client request is limited to talking to one peer, and
> RTT to a resolver is usually low. resolver->auth is different where the
> transport can be used many times for a single client query.
Unexpected latency here can not only badly impact user experience, but
cause timeouts. FWIW, a stub resolver such as glibc would typically
timeout a query in 5 seconds and make a second attempt (possibly to a
different nameserver) if the first one fails. This may or may not
totally take 5 seconds in all. dig will timeout each fetch at 5 seconds
by default, and try up to 3 times in all before it gives up. The need to
answer within such time is why the serve-stale draft has a "client
response timer".
These circumstances can also occur with regular DNS with a lot of
indirection (several NS lookups in servicing a single client query) and
high RTT to nameservers. E.g. BIND can wait from 10 upto 30 seconds for
a resolution to timeout based on configuration, but its client usually
won't wait that long, but named can at least insert the resolution
result into cache for future queries. Stub timeout behavior is something
to consider when switching transports.
Mukund
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
