> Guangqing Deng <mailto:dengguangq...@cnnic.cn>
> Sunday, December 28, 2014 10:52 PM
> ... there do exist some ones who think the DNS resolution delay is not
> as short as they expected, especially those running applications
> depending on the DNS resolution.
early internet applications were written with the assumption of on-host
or on-lan RDNS, such that a cached answer would be almost immediate
(less than 1 millisecond). using google dns or opendns or any other
cloud-oriented ("anycast") RDNS has a higher time-cost than that.
servers in san francisco, san jose, palo alto, or fremont are ~5
milliseconds from me. opendns and google dns are ~8ms from me. my
on-campus (well, at my house) RDNS servers are ~400 microseconds (~0.4
milliseconds).
so, i agree. and i was half way down the path of considering how a light
weight caching DNS shim could be installed on a host or on a LAN that
would do RTT-based server selection to keep track of closer/farther
servers, and i realized, i was reinventing RDNS. one of my new great
regrets of things-not-done-while-at-ISC was to make BIND RDNS into a
binary package that could be installed on any windows or mac/os or
android or iOS device, with cloud/subscription based configuration (for
RPZ policy).
--
Paul Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
