Mark Delany wrote: >> one can lookup A, AAAA and SRV in parallel and positive answer >> to SRV, as Paul mentioned, can have additional A and AAAA RRs. > > A downside is that clients has to wait for the SRV query to complete > so they can be sure of the presence or not of an SRV. ...
in a blast protocol where all N queries are sent to the same destination, one can reset the blast timeout upon first response, to 1.2x that response time. or even 1.1x. the total time cost delta of a blast protocol is thus ~10%. since this is only happening on a cache miss, i don't see it as decisive. > ... > > You're also ensuring that the global query rate will substantially > increase on the assumption that HTTP/2.0 becomes as popular as > HTTP/1.0. not so. 97% of the queries reaching the root name servers (as an example of an important subset of global DNS traffic) are unanswerable due to an initator-side screwup of some kind (rfc1918 source; firewall doesn't permit response; etc). if we doubled the traffic that is not that 97%, it would still be mouse nuts compared to that 97%. > ... > > Generally speaking, the challenge is that SRV is likely acceptable to > commercial CDN providers that have thus far relied on CNAME - with > it's intrinsic level of indirection - but will be less welcome by > those who are using every trick to squeeze latency out of HTTP. disagreeing for a third time, SRV is an opportunity to squeeze even more latency out of HTTP. > ... > > If you want to make everyone happy, you need to invent a single > round-trip resolution that supports indirection... content-centric networking would do this. lixia and van have been talking about it for a few years. alas it's a totally non-IP model and not likely to replace the internet during the time it will take us to decide what to do about SRV (and also do whatever it is we decided.) vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
