3 ms·

For web browsers, multiple A/AAAA are sufficient. Web browsers worked around the issues folks are mentioning some time ago using retries to each IP. The use o

For web browsers, multiple A/AAAA are sufficient. Web browsers worked around the issues folks are mentioning some time ago using retries to each IP. The use of SRV could help in newer API driven implementations so that scripts and other tooling could enumerate which IP's are preferred. For now, developers will just have to make use of multiple records like the browsers do. That said, it won't likely happen because the HTTP spec does not allow new DNS implementations. The RFC would have to be deprecated with a new one that permits SRV. HTTP/2 would have been a grand opportunity to do just that. There have been many discussions [1] and debates on the issue, but I do not foresee it happening. [1] - https://www.ietf.org/mail-archive/web/httpbisa/current/msg25379.html https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...

deleted 8y ago
[deleted]
inopinatus 8y ago
HTTP protocol & normative references don't actually mention DNS at all. The hand-wringing evidenced by some about the difficulties of introducing a new behaviour seems pretty feeble when you consider that Google has successfully intruded both a new transport protocol (QUIC) and a new application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling browser updates are now the norm and enable these major changes.
- LinuxBender 8y ago
  Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement. Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.
  - inopinatus 8y ago
    Funny thing is, TBL anticipated this years ago when registering the service names. Read the assignment notes at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http https://www.iana.org/assignments/service-names-port-numbers/... - yes it's talking about DNS-SD specifically but the remark generalises to all service discovery, basically setting the expectation of different service names based on intended use. API endpoints tend not to be apex records, indeed are characterised by using a label of "api" or similar which doesn't automatically conflict with other services, certainly not in the common case. It'd remain a violation IMO to use a host name as a service selector but in practice they could continue using address records for many years of transition.

deleted 8y ago

[deleted]

inopinatus 8y ago

HTTP protocol & normative references don't actually mention DNS at all. The hand-wringing evidenced by some about the difficulties of introducing a new behaviour seems pretty feeble when you consider that Google has successfully intruded both a new transport protocol (QUIC) and a new application layer protocol (HTTP/2 i.e. SPDY) in a few short years. Rolling browser updates are now the norm and enable these major changes.

LinuxBender 8y ago
Agreed, but the protocol does not allow for deviation without creating a new protocol; which to your point, Google did. Google could have introduced SRV records as optional components in the spec. So the lack of mention of DNS standards in the protocol is sufficient to block the implementation of a new DNS requirement. Browsers are not the only thing that speak http. There are a myriad of libraries used by API's and all manor of automation that must also be updated to support a new protocol. A good example of this is SNI. All major browsers support SNI, but there are plenty of libraries that have yet to catch up to that very well aged protocol.
- inopinatus 8y ago
  Funny thing is, TBL anticipated this years ago when registering the service names. Read the assignment notes at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=http https://www.iana.org/assignments/service-names-port-numbers/... - yes it's talking about DNS-SD specifically but the remark generalises to all service discovery, basically setting the expectation of different service names based on intended use. API endpoints tend not to be apex records, indeed are characterised by using a label of "api" or similar which doesn't automatically conflict with other services, certainly not in the common case. It'd remain a violation IMO to use a host name as a service selector but in practice they could continue using address records for many years of transition.