That's actually a pretty good point and I wish more services used SRV records to determine which host and port to use. HTTP 2.0 was a chance to implement it for HTTP but the effort fizzled out after just a handful of comments in 2007 or so.
I also like the idea of squeezing other information into DNS, like certificates, gpg keys, why not HSTS-like
information too? Say, a TXT record enforcing ssl, no exceptions (ssl=all). But all this hinges on DNSSEC which is very unpopular here.
In recent years a few people (myself included) have tried again to inject the use of DNS service records into the HTTP/2 effort and have been consistently knocked back by the authors. Last I looked, the new standard was studiously burying its head in the sand and avoiding mentioning lower-layer resolution issues at all, as though things like dual-stack IP, port number variation or the zone-apex issue were Somebody Else's Problem. Whilst I think they are glaring UX issues for HTTP clients that arise directly from the continuing and mistaken default of resolving address records.
Of course what we get instead is unspecified and even conflicting* behaviour, which I think just stinks. Many other standards have managed to get it together by specifying the use of SRV. I gave up trying to change the entrenched positions.
* there is language in the draft that advises against multiple connections, conflicting with the current "Happy Eyeballs" dual-stack resolution workaround.
One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system.
CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least).
Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.
Comments
Port numbers are a limited resource.
That's actually a pretty good point and I wish more services used SRV records to determine which host and port to use. HTTP 2.0 was a chance to implement it for HTTP but the effort fizzled out after just a handful of comments in 2007 or so.
I also like the idea of squeezing other information into DNS, like certificates, gpg keys, why not HSTS-like information too? Say, a TXT record enforcing ssl, no exceptions (ssl=all). But all this hinges on DNSSEC which is very unpopular here.
In recent years a few people (myself included) have tried again to inject the use of DNS service records into the HTTP/2 effort and have been consistently knocked back by the authors. Last I looked, the new standard was studiously burying its head in the sand and avoiding mentioning lower-layer resolution issues at all, as though things like dual-stack IP, port number variation or the zone-apex issue were Somebody Else's Problem. Whilst I think they are glaring UX issues for HTTP clients that arise directly from the continuing and mistaken default of resolving address records.
Of course what we get instead is unspecified and even conflicting* behaviour, which I think just stinks. Many other standards have managed to get it together by specifying the use of SRV. I gave up trying to change the entrenched positions.
* there is language in the draft that advises against multiple connections, conflicting with the current "Happy Eyeballs" dual-stack resolution workaround.
One reason DNSSEC is unpopular is that it fails to address the fact that centralized PKI suffers from tons of problems. Those problems would defeat the purpose of a gesture as serious as putting your gpg key in DNS.
It always seems ridiculous to me that people are coming up with ways to cope with universal CAs (Tack, Convergence, CRLSets, etc.), but can't imagine how to apply those same ideas with a hierarchical system.
CAs are a problem that DNSSEC doesn't solve, but DNSSEC solves tons of other problems without making the CA problem harder.
I think it's unpopular, because it is complex and it doesn't address privacy (between you and your ISP at least).
Centralized, hierarchical PKI is ok here, because it is better than what we have now (600 CAs for TLS, unsigned DNS, etc.) and nobody has a proposal for a fully decentralized system that ordinary people can understand (as demonstrated by GPG).
Sure but those are the same problems that a centralized domain name system suffers from. Currently, we have the privilege of paying for a second centralized system (CAs) which solves none of them.