5 ms·
The reality is that this is not that infeasible a change as everyone wants us to think that it is. It is simply a change to the DNS resolution logic for HTTP/HT
by dsparkman 9y ago
The reality is that this is not that infeasible a change as everyone wants us to think that it is. It is simply a change to the DNS resolution logic for HTTP/HTTPS. The major browser vendors could make the change in relatively short order. The major hurdle is that it would increase the number of DNS queries to resolve a website.
XMPP is an example of a protocol that currently has this correct, in that it uses SRV records to control ports for a given host.
- LgWoodenBadger 9y agoWhy would it involve extra DNS queries? Why wouldn't the SRV record come back as part of the original response to the host-name resolution request?
- zAy0LfpBZLC8mAC 9y agoThere is no such thing as a "host-name resolution request". A DNS query specifies a domain name and a record type, and gets as the result a list of all records of that type under that name. Record types would be A (IPv4 address), AAAA (IPv6 address), MX (mail exchanger name), SRV (server name and port for a particular service), TXT (free-form text), and many others, most of them nowadays unused.
- icebraining 9y agoYou can specify "ANY" as the type in the query and get all results. Try running "host -a ycombinator.com". It doesn't recursively resolve CNAMEs like an A query does, though. Also, at least Cloudflare refuses those requests, to reduce DNS reflection attacks.
- zAy0LfpBZLC8mAC 9y agoANY gives you all records for the given name in the cache of the name server that you are querying, which usually will be incomplete in the case of recursive resolvers.
- JdeBP 9y ago"any" does not mean "all". People regularly make this mistake. One cannot do these sorts of tricks with ANY queries. * http://jdebp.eu/Softwares/djbwares/qmail-patches.html#any-to-cname http://jdebp.eu/Softwares/djbwares/qmail-patches.html#any-to...
- JdeBP 9y agoThe "It will increase the number of DNS queries" is another of the many attempts at a counterargument that is not really true if one analyses it, that has been coming up for two decades now. * http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html In reality, the number of back-end DNS queries to perform an A or an AAAA lookup can vary enormously, and can number in the tens or hundreds of queries already. It's not generally true that the number of back-end lookups will increase, because the number of back-end lookups varies wildly by time (depending from what is cached from momement to moment) by domain name (depending from the amount of gluelessness) and by country. There is so much variation in there already that the variation caused by a two-step SRV lookup can quite often be lost in the noise. Of course, SRV lookups do not even have to be two-step in the first place. A proxy or content DNS server is free to add the requisite A and AAAA resource record sets as additional section data in its response, meaning that the client obtains both pieces of information in a single transaction. And of course several real world DNS server softwares do exactly this. * https://news.ycombinator.com/item?id=8850302 https://news.ycombinator.com/item?id=8850302 Whenever you see these objections, always remember that there are protocols where SRV resource records have been in use for coming up to twenty years. And yet one never hears of actual problems with those protocols that mirror the supposed projected problems of using SRV lookups for HTTP. A lot of what one hears about why this would not work is simply bad analysis and excuse making. The worst part perhaps is that the code to do this for one of the WWW browsers was actually written, the only actual technical niggles were solved 17 years ago, and -- perhaps most tellingly of all -- whilst people are still telling us how this cannot be done all these years after the code was written, there are parts of the world that are quietly and happily doing it right now. The FreeBSD packaging system uses SRV resource records and HTTP/HTTPS, for example. It's also an example of how real world DNS servers can and do send all of the data in one transaction using the additional section. They've even made it in-bailiwick. JdeBP % dnsq srv _http._tcp.pkg.freebsd.org. ns1.isc-sns.net. 33 _http._tcp.pkg.freebsd.org: 510 bytes, 1+5+3+8 records, response, authoritative, noerror query: 33 _http._tcp.pkg.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.isc.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.nyi.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 10 10 80 pkgmir.geo.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.bme.freebsd.org answer: _http._tcp.pkg.freebsd.org 300 SRV 50 10 80 pkg0.ydx.freebsd.org authority: freebsd.org 3600 NS ns1.isc-sns.net authority: freebsd.org 3600 NS ns3.isc-sns.info authority: freebsd.org 3600 NS ns2.isc-sns.com additional: pkg0.bme.freebsd.org 3600 A 213.138.116.73 additional: pkg0.bme.freebsd.org 3600 AAAA 2001:41c8:112:8300:0:0:50:1 additional: pkg0.isc.freebsd.org 3600 A 149.20.1.201 additional: pkg0.isc.freebsd.org 3600 AAAA 2001:4f8:1:11:0:0:50:1 additional: pkg0.nyi.freebsd.org 3600 A 96.47.72.71 additional: pkg0.nyi.freebsd.org 3600 AAAA 2610:1c1:1:606c:0:0:50:1 additional: pkg0.ydx.freebsd.org 3600 A 77.88.40.109 additional: pkg0.ydx.freebsd.org 3600 AAAA 2a02:6b8:b010:1001:0:0:50:1 JdeBP %
- JdeBP 9y agoThere are actually quite a few protocols whose clients use SRV resource records. * http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html http://jdebp.eu./FGA/dns-srv-record-use-by-clients.html