4 ms·

HTTP protocol & normative references don't actually mention DNS at all. The hand-wringing evidenced by some about the difficulties of introducing a new behavio

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.

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.