3 ms·

Fun fact: nowhere in the HTTP protocol specification does it say "use DNS". It is a convention that we do. It is a further convention that we use A records.

Fun fact: nowhere in the HTTP protocol specification does it say "use DNS". It is a convention that we do. It is a further convention that we use A records. And in my opinion it was a travesty that HTTP/2 did not mandate using DNS with SRV records.

wahern 10y ago
Corporate firewalls have ruined the internet. You can't put a website on an arbitrary port. The shift to SSL won't even change that, because sysadmins and similar professionals like categorizing traffic by port, and no amount of reasoning will change that. They still think you can filter good/bad, allowed/disallowed by port, even if you can't scan it. Load-balancing isn't within the ambit of HTTP, so that doesn't weigh in favor of SRV. The _service._proto template for SRV names is pointless for anything already communicating over HTTP, as it's going to be either too specific/redundant or not specific enough for your particular scenario. For example, I'm using SRV for a automatic service registration and discovery project and ignoring it entirely. But ignoring that in a standard is awkward. Finally, IPv6 (presuming we get there!) will make ports redundant. You can just assign a new address to your service. The historical baggage will be annoying (requiring root to bind to ports <1024), but with VMs and containers corporate software doesn't bother with old-school best practices like that. And we're ignoring that there's already an installed base and market for load balancers, redirectors, etc. I understand that the dream is to be able to move that logic back toward the edges, and I whole heartedly agree. But as with filtering by port number, the majority of IT professionals just don't think that way.
- inopinatus 10y ago
  We achieve change incrementally. If you think corporate firewalls and inflexible admins should define the architecture of the internet, you have already lost. In practice, they adapt. Believe me they are already having to, with the change of wire format and connection behaviours due to HTTP/2 requests. Actually nothing persuades a stick-in-the-mud sysadmin quite like a ratified standards document: that is something they can relate to. I say this with confidence because I am a stick-in-the-mud sysadmin. The major immediate utility of SRV records is one we haven't mentioned: they can be aliases at apex records, because they are not A/AAAA records. The broader case is that all protocols should be using SRV because overloading address records for service discovery has so many misbehaviours. Allocating multiple IPv6 addresses doesn't fix the problem of overloaded symbolic names. Using address records hurts the adoption of DNS for federation.
LukeShu 10y ago
I was about to disagree with you and say that it indirectly says to use DNS through RFC 3986. But you're right! RFC 3986 says to (unless otherwise directed by the URI scheme) to use the operating system's registered name resolution mechanism: Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. It's just a convention that all modern operating systems (primarily) use DNS!

wahern 10y ago

Corporate firewalls have ruined the internet. You can't put a website on an arbitrary port. The shift to SSL won't even change that, because sysadmins and similar professionals like categorizing traffic by port, and no amount of reasoning will change that. They still think you can filter good/bad, allowed/disallowed by port, even if you can't scan it. Load-balancing isn't within the ambit of HTTP, so that doesn't weigh in favor of SRV. The _service._proto template for SRV names is pointless for anything already communicating over HTTP, as it's going to be either too specific/redundant or not specific enough for your particular scenario. For example, I'm using SRV for a automatic service registration and discovery project and ignoring it entirely. But ignoring that in a standard is awkward. Finally, IPv6 (presuming we get there!) will make ports redundant. You can just assign a new address to your service. The historical baggage will be annoying (requiring root to bind to ports <1024), but with VMs and containers corporate software doesn't bother with old-school best practices like that. And we're ignoring that there's already an installed base and market for load balancers, redirectors, etc. I understand that the dream is to be able to move that logic back toward the edges, and I whole heartedly agree. But as with filtering by port number, the majority of IT professionals just don't think that way.

inopinatus 10y ago
We achieve change incrementally. If you think corporate firewalls and inflexible admins should define the architecture of the internet, you have already lost. In practice, they adapt. Believe me they are already having to, with the change of wire format and connection behaviours due to HTTP/2 requests. Actually nothing persuades a stick-in-the-mud sysadmin quite like a ratified standards document: that is something they can relate to. I say this with confidence because I am a stick-in-the-mud sysadmin. The major immediate utility of SRV records is one we haven't mentioned: they can be aliases at apex records, because they are not A/AAAA records. The broader case is that all protocols should be using SRV because overloading address records for service discovery has so many misbehaviours. Allocating multiple IPv6 addresses doesn't fix the problem of overloaded symbolic names. Using address records hurts the adoption of DNS for federation.

LukeShu 10y ago

I was about to disagree with you and say that it indirectly says to use DNS through RFC 3986. But you're right! RFC 3986 says to (unless otherwise directed by the URI scheme) to use the operating system's registered name resolution mechanism: Instead, it delegates the issue of registered name syntax conformance to the operating system of each application performing URI resolution, and that operating system decides what it will allow for the purpose of host identification. A URI resolution implementation might use DNS, host tables, yellow pages, NetInfo, WINS, or any other system for lookup of registered names. It's just a convention that all modern operating systems (primarily) use DNS!