4 ms·

RFC9460: Service Binding via the DNS (SVCB and HTTPS Resource Records)

88 points by teddyh 3y ago

chrismorgan 3y ago
Ooh, it’s finally published, huh? Not certain about timing, but I believe browsers have all supported it for 2–4 years. Simplifying beyond the point of strict accuracy, this is a signal so that when your browser asks DNS “where’s the example.com server?” the response mentions “oh BTW it supports HTTP/3” and so the browser goes straight to https://example.com https://example.com over HTTP/3. Otherwise, first-time visitors will commonly go to http://example.com http://example.com over HTTP/1.1, and then be redirected to https://example.com https://example.com over HTTP/1.1 or HTTP/2 (negotiated at TLS handshake time), and only use HTTP/3 on subsequent visits. It’s a pity that supporting HTTP/3 takes extra effort compared to HTTP/1 or HTTP/2, but it’s not really avoidable.
- aaronax 3y ago
  Maybe they shouldn't have used http:// http:// for something that isn't http. Nah, users are too dumb and "my precious adoption rates"
  - xg15 3y ago
    I guess it's more "my precious marketing". General consensus in marketing seems to be that people can't memorize anything more than domain names, and maybe also a "www." or a single word path behind the domain - but the scheme seems to be universally seen as "technical cruft that non-technical users can't be expected to deal with". (with the one exception that "http:// http:// = bad and https:// https:// = good") So I guess companies don't want a situations in which they suddenly have to teach their users that, no, it's not "awesomecorp.com", it's actually "https3://awesomecorp.com" (but NOT https://3awesomecorp.com https://3awesomecorp.com, that's a scammer) etc etc
    - ekr____ 3y ago
      The main motivation here is the desire to have a seamless transition to newer protocols without having to change the site. This way, your hosting service can enable HTTP/3 and it will just work with an HTTP/3 compatible browser. This is the way every upgrade in TLS and HTTP has worked for quite some time. It's especially important with HTTP/3 because there are network environments where HTTP/3 doesn't work and so you need to fall back to HTTP/2, and you obviously want that to work seamlessly. In addition, the basic security structure in the Web is the origin, defined in RFC 6454, and origins are defined by a triplet of [scheme, host, port]. It would not be good to have HTTP over TLS and HTTP/3 be different origins. For instance, you don't want to lose all your cookies if the site turns HTTP/3 on or off.
- crote 3y ago
  Do you happen to know what this is called in CanIUse & friends? It would be neat to see what the actual support is. "All browsers" usually means "Chrome and maybe Firefox if you're lucky", unfortunately.
  - DASD 3y ago
    Here's a request discussion to add support in Can I use: https://github.com/Fyrd/caniuse/issues/6091 https://github.com/Fyrd/caniuse/issues/6091
teddyh 3y ago
Reasons this is significant, IMHO: • Most importantly, it makes fallback and load-balancing available for regular people; just spin up an extra web server somewhere else and add it to the DNS, just like a secondary MX. Mostly no need for a CDN anymore. • The importance of SNI is lessened, since the DNS can now point to a port number as well as a host name. This makes it possible to have web server configurations without an enumeration of all server names; just have the web server use a certificate from a file and listen to the correct port number – no need to configure host names. • The possibility to have separate web sites use different ports makes process isolation easier without having to go through a gateway host. • It frees the apex DNS domain name from having to have an IP address; an IP address is harder to keep updated than a simple host name of a web server. In summary, these things either make it easier to live on today’s internet without Google, Cloudflare, or other centralizing actors, or they make it easier for the smaller web hosting providers, or both.
- crote 3y ago
  I'm not convinced about the port stuff. Until support is well over 99%, using a custom port will mean your website is simply inaccessible to some visitors. Even worse, a link which works perfectly fine on one computer will simply be completely broken on another, without any kind of warning or explanation. It's like trying to host a website on IPv6-only in 2023: nice idea, just not viable in practice. Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello?
  - teddyh 3y ago
    Of course you have to maintain a backwards-compatible gateway proxy. But since most clients will not use it, and since it is obvious that it will be possible to remove it at some time in the future, this is, IMHO, acceptable. > Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello? Has that been implemented and/or standardized yet?
    - DistractionRect 3y ago
      AFAIK that proposal got dropped in favor of ECH, which isn't standardized yet [0]. [0] https://blog.cloudflare.com/announcing-encrypted-client-hello/ https://blog.cloudflare.com/announcing-encrypted-client-hell...
throw0101b 3y ago
My first thought was to SRV records: > C.1. Differences from the SRV RR Type > An SRV record [SRV] can perform a function similar to that of the SVCB record, informing a client to look in a different location for a service. However, there are several differences: > * SRV records are typically mandatory, whereas SVCB is intended to be optional when used with pre-existing protocols. > * SRV records cannot instruct the client to switch or upgrade protocols, whereas SVCB can signal such an upgrade (e.g., to HTTP/2). > * SRV records are not extensible, whereas SVCB and HTTPS RRs can be extended with new parameters. > * SRV records specify a "weight" for unbalanced randomized load balancing. SVCB only supports balanced randomized load balancing, although weights could be added via a future SvcParam. * https://datatracker.ietf.org/doc/html/rfc9460#appendix-C.1 https://datatracker.ietf.org/doc/html/rfc9460#appendix-C.1
_8j50 3y ago
This (dns) approach does not authenticate. SRV and TXT records already publicize too much information to the public. A RESTful api would be ideal or adding the equivalent of bearer token auth to DNS.
- teddyh 3y ago
  Since the DNS record is extensible, it can be extended to contain any extra parameters deemed necessary in the future.
patriciajohn99 3y ago
[dead]
loxias 3y ago
So, how is this different from SRV records? They work fine for my limited use...
- thayne 3y ago
  - it allows specifying that http3 or http2 should be used. The former is especially important, since http requires using udp instead of tcp - it can include certificate information used for ECH - it can be used as an alias record at the apex of a zone. Which sort of solves the problem of not being able to have a CNAME on the apex... Once this is widely deployed.
- crest 3y ago
  Did you read Appendix C.1 of RFC 9460? It’s addressed in the very document. If implemented it can reduce time to first byte (it saves round trips to negotiate the next protocol) and it can be retrofitted to existing protocols like HTTP. If this is implemented by most browsers the SNI reverse proxy only has to handle remaining load.
  - loxias 3y ago
    Thank you for this. No, I did not, though now, I have. :)
throwawaaarrgh 3y ago
I like the idea of SVCB, but I hate the idea of there being an RR for one specific other protocol (HTTPS). DNS and HTTP[S] are complicated enough without building cyclical dependencies between the two protocols. Less coupling is better. However, they don't make a good case for how SVCB is need over SRV. SRV could be modified in a different spec instead.
- arccy 3y ago
  there is no cyclical dependency for the HTTPS record
  - silverwind 3y ago
    There is if you use DOH.
- thayne 3y ago
  > SRV could be modified in a different spec instead. I don't think it could be, at least without breaking things. Unlike SVCB, SRV wasn't designed to be extensible, so adding new functionality can't really be done without breaking anything that currently parses SRV responses.
__turbobrew__ 3y ago
Reducing the number of hops needed before first data bytes is really cool. We cannot change the speed of light but we can design protocols which need to traverse the medium fewer times.
efitz 3y ago
I was always a huge fan of SRV records; it gives you the ability to easily and quickly shape traffic centrally when clients and protocol are not under your control. However, I found very few allies in this. Most people that I talked to disliked the fact that networking/DNS teams were organizationally far removed from application teams, and often imposed slow, onerous change processes. I don’t see any reason why that will have changed, even though my experience is 15+ years ago.
- pas 3y ago
  the whole devops ("microservices") culture is about giving teams autonomy, more project/product ownership. sure, many companies hire "devops engineers" and then require them to file Jira tickets to networking/provisioning/cloud team, but it's not the fault of the protocol :)
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]

88 points by teddyh 3y ago

Ooh, it’s finally published, huh? Not certain about timing, but I believe browsers have all supported it for 2–4 years. Simplifying beyond the point of strict accuracy, this is a signal so that when your browser asks DNS “where’s the example.com server?” the response mentions “oh BTW it supports HTTP/3” and so the browser goes straight to https://example.com https://example.com over HTTP/3. Otherwise, first-time visitors will commonly go to http://example.com http://example.com over HTTP/1.1, and then be redirected to https://example.com https://example.com over HTTP/1.1 or HTTP/2 (negotiated at TLS handshake time), and only use HTTP/3 on subsequent visits. It’s a pity that supporting HTTP/3 takes extra effort compared to HTTP/1 or HTTP/2, but it’s not really avoidable.

aaronax 3y ago
Maybe they shouldn't have used http:// http:// for something that isn't http. Nah, users are too dumb and "my precious adoption rates"
- xg15 3y ago
  I guess it's more "my precious marketing". General consensus in marketing seems to be that people can't memorize anything more than domain names, and maybe also a "www." or a single word path behind the domain - but the scheme seems to be universally seen as "technical cruft that non-technical users can't be expected to deal with". (with the one exception that "http:// http:// = bad and https:// https:// = good") So I guess companies don't want a situations in which they suddenly have to teach their users that, no, it's not "awesomecorp.com", it's actually "https3://awesomecorp.com" (but NOT https://3awesomecorp.com https://3awesomecorp.com, that's a scammer) etc etc
  - ekr____ 3y ago
    The main motivation here is the desire to have a seamless transition to newer protocols without having to change the site. This way, your hosting service can enable HTTP/3 and it will just work with an HTTP/3 compatible browser. This is the way every upgrade in TLS and HTTP has worked for quite some time. It's especially important with HTTP/3 because there are network environments where HTTP/3 doesn't work and so you need to fall back to HTTP/2, and you obviously want that to work seamlessly. In addition, the basic security structure in the Web is the origin, defined in RFC 6454, and origins are defined by a triplet of [scheme, host, port]. It would not be good to have HTTP over TLS and HTTP/3 be different origins. For instance, you don't want to lose all your cookies if the site turns HTTP/3 on or off.
crote 3y ago
Do you happen to know what this is called in CanIUse & friends? It would be neat to see what the actual support is. "All browsers" usually means "Chrome and maybe Firefox if you're lucky", unfortunately.
- DASD 3y ago
  Here's a request discussion to add support in Can I use: https://github.com/Fyrd/caniuse/issues/6091 https://github.com/Fyrd/caniuse/issues/6091

teddyh 3y ago

Reasons this is significant, IMHO: • Most importantly, it makes fallback and load-balancing available for regular people; just spin up an extra web server somewhere else and add it to the DNS, just like a secondary MX. Mostly no need for a CDN anymore. • The importance of SNI is lessened, since the DNS can now point to a port number as well as a host name. This makes it possible to have web server configurations without an enumeration of all server names; just have the web server use a certificate from a file and listen to the correct port number – no need to configure host names. • The possibility to have separate web sites use different ports makes process isolation easier without having to go through a gateway host. • It frees the apex DNS domain name from having to have an IP address; an IP address is harder to keep updated than a simple host name of a web server. In summary, these things either make it easier to live on today’s internet without Google, Cloudflare, or other centralizing actors, or they make it easier for the smaller web hosting providers, or both.

crote 3y ago
I'm not convinced about the port stuff. Until support is well over 99%, using a custom port will mean your website is simply inaccessible to some visitors. Even worse, a link which works perfectly fine on one computer will simply be completely broken on another, without any kind of warning or explanation. It's like trying to host a website on IPv6-only in 2023: nice idea, just not viable in practice. Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello?
- teddyh 3y ago
  Of course you have to maintain a backwards-compatible gateway proxy. But since most clients will not use it, and since it is obvious that it will be possible to remove it at some time in the future, this is, IMHO, acceptable. > Besides, weren't the issues with SNI supposed to be solved with ESNI and Encrypted ClientHello? Has that been implemented and/or standardized yet?
  - DistractionRect 3y ago
    AFAIK that proposal got dropped in favor of ECH, which isn't standardized yet [0]. [0] https://blog.cloudflare.com/announcing-encrypted-client-hello/ https://blog.cloudflare.com/announcing-encrypted-client-hell...

throw0101b 3y ago

My first thought was to SRV records: > C.1. Differences from the SRV RR Type > An SRV record [SRV] can perform a function similar to that of the SVCB record, informing a client to look in a different location for a service. However, there are several differences: > * SRV records are typically mandatory, whereas SVCB is intended to be optional when used with pre-existing protocols. > * SRV records cannot instruct the client to switch or upgrade protocols, whereas SVCB can signal such an upgrade (e.g., to HTTP/2). > * SRV records are not extensible, whereas SVCB and HTTPS RRs can be extended with new parameters. > * SRV records specify a "weight" for unbalanced randomized load balancing. SVCB only supports balanced randomized load balancing, although weights could be added via a future SvcParam. * https://datatracker.ietf.org/doc/html/rfc9460#appendix-C.1 https://datatracker.ietf.org/doc/html/rfc9460#appendix-C.1

_8j50 3y ago

This (dns) approach does not authenticate. SRV and TXT records already publicize too much information to the public. A RESTful api would be ideal or adding the equivalent of bearer token auth to DNS.

teddyh 3y ago
Since the DNS record is extensible, it can be extended to contain any extra parameters deemed necessary in the future.

patriciajohn99 3y ago

[dead]

loxias 3y ago

So, how is this different from SRV records? They work fine for my limited use...

thayne 3y ago
- it allows specifying that http3 or http2 should be used. The former is especially important, since http requires using udp instead of tcp - it can include certificate information used for ECH - it can be used as an alias record at the apex of a zone. Which sort of solves the problem of not being able to have a CNAME on the apex... Once this is widely deployed.
crest 3y ago
Did you read Appendix C.1 of RFC 9460? It’s addressed in the very document. If implemented it can reduce time to first byte (it saves round trips to negotiate the next protocol) and it can be retrofitted to existing protocols like HTTP. If this is implemented by most browsers the SNI reverse proxy only has to handle remaining load.
- loxias 3y ago
  Thank you for this. No, I did not, though now, I have. :)

throwawaaarrgh 3y ago

I like the idea of SVCB, but I hate the idea of there being an RR for one specific other protocol (HTTPS). DNS and HTTP[S] are complicated enough without building cyclical dependencies between the two protocols. Less coupling is better. However, they don't make a good case for how SVCB is need over SRV. SRV could be modified in a different spec instead.

arccy 3y ago
there is no cyclical dependency for the HTTPS record
- silverwind 3y ago
  There is if you use DOH.
thayne 3y ago
> SRV could be modified in a different spec instead. I don't think it could be, at least without breaking things. Unlike SVCB, SRV wasn't designed to be extensible, so adding new functionality can't really be done without breaking anything that currently parses SRV responses.

__turbobrew__ 3y ago

Reducing the number of hops needed before first data bytes is really cool. We cannot change the speed of light but we can design protocols which need to traverse the medium fewer times.

efitz 3y ago

I was always a huge fan of SRV records; it gives you the ability to easily and quickly shape traffic centrally when clients and protocol are not under your control. However, I found very few allies in this. Most people that I talked to disliked the fact that networking/DNS teams were organizationally far removed from application teams, and often imposed slow, onerous change processes. I don’t see any reason why that will have changed, even though my experience is 15+ years ago.

pas 3y ago
the whole devops ("microservices") culture is about giving teams autonomy, more project/product ownership. sure, many companies hire "devops engineers" and then require them to file Jira tickets to networking/provisioning/cloud team, but it's not the fault of the protocol :)

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]