7 ms·

Use of HTTPS Resource Records

89 points by campuscodi 3y ago

zamadatix 3y ago
This prompted me to try adding an HTTPS record for my home website. Worked fine in bind, didn't take much work. Between A, AAAA, and HTTPS it is getting to be quite a lot to maintain vs the days of just having an A record. Of course, just having an A record is still a valid option (for now) if that's your main concern.
josephg 3y ago
Cool! I had no idea this was a thing. Looks way more elegant than HSTS and all that mess. Whats the status on DNSSEC? Last I checked, it was a bit of a mess as far as protocols go.
- tptacek 3y ago
  It is deployed on less than 5% of .COM, and an even smaller fraction of "important" or "popular" zones (take any top 500, run it through a loop of `dig ds $domain +short`; try "microsoft.com" and "google.com", and then "uscis.dhs.gov" to see what a positive response looks like). IIRC, there have been recent years where the deployment count in .COM went down. It's pretty much a dead letter.
  - teddyh 3y ago
    Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Whereas, from where I sit, I work at a registry and DNS server host (among other things) where about 40% of all our domains have DNSSEC (and that number is constantly climbing). Every conference I go to, and in every webinar, people seemingly always talk about DNSSEC and how usage is increasing. You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). I’m not an expert on the details; you could most assuredly argue circles around me when it comes to the cryptography, and possibly about the DNSSEC protocol details as well. But, from my perspective, your continuous claim that “nobody uses” DNSSEC is simply false. DNSSEC works, usage of DNSSEC is steadily increasing, and new protocols (like DANE) are starting to make use of DNSSEC for its features. Conversely, I only relatively rarely hear anything about MTA-STS. (Repost of a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530>, but the details given have not changed substantially.)
    - tptacek 3y ago
      (I vouched this comment, because I wanted to reply to it.) I'm not making the statistics up; you can just Google "DNSSEC deployment statistics" to see that I'm right about them, and I even provided a methodology in the comment you responded to for readers to verify for themselves. Where DNSSEC signatures are climbing, it's largely because of registrars that automatically sign domains for customers. That's security theater. Moreover, it's capturing the least interesting cohort of new DNS zones: random things people register. I own a bunch of them, including "atmosflat.org" and "paulgra-ham.com" (don't ask me, I don't remember). If I had registered them at an autosigning DNSSEC registrar, they too would count in the "steadily increasing" count to which you refer.
      - chrismorgan 3y ago
        Why/how is automatic signing of domains security theatre? As one not particularly involved, I’d have thought that was the goal, and certainly the only way you’re ever going to get anything but niche usage.
        tptacek 3y ago
        The registrar controls your keys. Further: virtually all DNS hijacking happens via registrars, not the on- and off-path network attacks on the DNS that DNSSEC attempts to defend against. (I'm focused on the stats argument here, because I feel like 'teddyh was trying to imply that I was making them up --- he only ever sees me relating them, to which I'd respond "that's because nobody else cares about DNSSEC". I have, an, uh, pretty expansive case to make against DNSSEC, but here I was just sort of relying on context 'teddyh and I share. Sorry about that!)
        alwillis 3y ago
        > The registrar controls your keys. I've been managing domains with DNSSEC for several years and I've always had control of my keys. Clarification of who controls what keys [1]: The TLD zone's private keys are managed by the company operating it. For a Country Code Top-Level Domain (ccTLD), the government of the country will be managing the key. For popular TLDs like .COM or .NET, it will be the U.S. government through the operator Verisign. For popular ccTLD .IO, it is the government of British Indian Ocean Territory. The private keys for an individual domain name are managed by the domain owner either directly or via the DNS provider hosting their domain name. With DNSSEC, it is pretty clear who controls the private keys and also keeps the risks involved distributed. Which means while China holds private keys for .cn ccTLD, it can only sign domain names under it. [1]: https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...
- jeroenhd 3y ago
  DNSSEC is widely supported and used in some countries but practically unused in others (https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec) How easy it is to set up depends on where you host and bought your domain. In my experience, I needed to copy-paste two keys and it Just Worked. It's barely used in .COM though, so companies like Amazon took ages to implement even basic support for it, and their buggy services took down various websites. To top it all off, mistakes by badly managed TLDs caused downtimes for various TLDs over time, of "someone told the root servers to redirect .NZ to localhost for a week" severity. If whoever is managing your TLD cannot be trusted to maintain a TLD, don't enable DNSSEC. The protocol is Very 90s ("computers aren't fast enough to validate RSA signatures so let's centralise it"), but modern clients take all of the 90s bullcrap out of the picture. DNSSEC is in dire need of a v2 that fixes this, but I've never had much trouble with it in practice, other than when websites misconfigure their DNSSEC config.
  - thayne 3y ago
    > other than when websites misconfigure their DNSSEC config One major problem with DNSSEC is that it is relatively easy to misconfigure it, especially in more complicated scenarios, and a misconfiguration can take you down for a long time.
    - bodgie 3y ago
      It can also be quite easy. Buggy complicated Route 53 and self-hosting with a buggy bespoke solution aren't the only options, but they are the only kinds of DNSSEC failures I've seen on the HN front page.
      - tptacek 3y ago
        The only failures you see on the HN front page are the ones that occur to gigantic companies we've all heard of, with huge networking teams and all the advantages you can ask for in getting DNSSEC working. When random small shops fall off the Internet because they broke DNSSEC, nobody cares; it never makes any front page anywhere.
woodruffw 3y ago
Very cool. It's a bummer it only works in Firefox with DoH, though. I couldn't find an explanation for why that is in the associated changeset[1]. (I would use DoH on my devices, but I run a local resolver for filtering purposes. The local resolver then connects to a global NS via DoH, but my local devices use plain old DNS.) [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1623126 https://bugzilla.mozilla.org/show_bug.cgi?id=1623126
- sillystuff 3y ago
  Depending on your local resolver, you possibly can provide DoH on localhost as well? I'm using unbound, and it was trivial to also provide DoH on localhost with a funky port, so 443 localhost remains available for other things (my motivation was that firefox also doesn't support ESNI without a DoH resolver; I assume this is still true for ECH as well, but haven't re-visited). For firefox, you can use a self-signed cert on your resolver (firefox did not work with ed25519, it did work with NIST P-256; I wanted a small key for lower overhead [having to use TLS + HTTP encapsulation for a resolver on localhost bothered me in irrational ways, and I was determined to minimize the overhead, even if the rational part of my brain said the overhead difference was too negligible to matter]). Add it with: edit-> settings -> (search "cert" in 'find in settings') -> view certificates -> (server tab) -> add exception -> enter the url: https://localhost:4353/dns-query https://localhost:4353/dns-query ensure "permanent" is checked The file, "cert_override.txt" is created by firefox after adding the cert exception, which can be copied to other profiles for provisioning. The gui DoH config will create the following in about:config which can be used for provisioning with user.js: network.trr.uri https://localhost:4353/dns-query network.trr.bootstrapAddress 127.0.0.1 network.trr.mode 3 trr true (network.trr.custom_uri is not used for anything but display in the gui) network.trr.custom_uri https://localhost:4353/dns-query I don't think chromium requires DoH for ESNI / HTTPSSVC, so it can just use plain-text localhost:53 as before. If it does need DoH for this, I do not know the equivalent to the above config, for chromium.
- thayne 3y ago
  It's because Firefox uses its own dns resolver when it uses DoH, but if DoH is disabled it just calls getaddrinfo from libc to look up a domain. And unfortunately getaddrinfo is a very minimal API, that doesn't have any way to resolve arbitrary record types like HTTPS or SVCB, it just returns ip addresses. There is a bug[1] for supporting HTTPS records when using the system dns, but I haven't seen much progress on it. And sadly, it probably requires different code for each OS. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1852752 https://bugzilla.mozilla.org/show_bug.cgi?id=1852752
remram 3y ago
Is there any guide for setting up ECH? Are we waiting for support in HTTPS server software?
- Ayesh 3y ago
  OpenSSL and Go crypt/tls has no support yet, so none of the webservers that depend on them support it. Apache, Nginx, and Caddy, they all need upstream ECH support first. - https://github.com/openssl/openssl/issues/7482 https://github.com/openssl/openssl/issues/7482 - https://github.com/openssl/openssl/pull/22938 https://github.com/openssl/openssl/pull/22938 - https://github.com/golang/go/issues/63369 https://github.com/golang/go/issues/63369
Ayesh 3y ago
I recently added HTTPS records to all of my domains, along with HTTP/3. From query statistics, I see that around 15% of the queries are for HTTPS records, 30-35% for A and AAAA records, and the rest for RR types like NS, TXT, etc. Browsers make HTTPS requests in addition to the A/AAAA, so this makes sense. In an ideal world, the ipv4/ipv6hints do the job if A and AAAA records, so a browser will only need to make an HTTPS request.
- chrismorgan 3y ago
  Note that ipv4hint and ipv6hint are not supposed to replace A/AAAA <https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv6hint https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv...>: > The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName per Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance. That is: you’re allowed to use the ipv4hint on this connection, but you should still fetch A/AAAA and use that subsequently.

89 points by campuscodi 3y ago

This prompted me to try adding an HTTPS record for my home website. Worked fine in bind, didn't take much work. Between A, AAAA, and HTTPS it is getting to be quite a lot to maintain vs the days of just having an A record. Of course, just having an A record is still a valid option (for now) if that's your main concern.

josephg 3y ago

Cool! I had no idea this was a thing. Looks way more elegant than HSTS and all that mess. Whats the status on DNSSEC? Last I checked, it was a bit of a mess as far as protocols go.

tptacek 3y ago
It is deployed on less than 5% of .COM, and an even smaller fraction of "important" or "popular" zones (take any top 500, run it through a loop of `dig ds $domain +short`; try "microsoft.com" and "google.com", and then "uscis.dhs.gov" to see what a positive response looks like). IIRC, there have been recent years where the deployment count in .COM went down. It's pretty much a dead letter.
- teddyh 3y ago
  Almost every time anyone mentions DNSSEC here on HN, you pop up like a jack-in-the-box to claim that nobody is using it and that it is dead. And it’s always you, nobody else. Whereas, from where I sit, I work at a registry and DNS server host (among other things) where about 40% of all our domains have DNSSEC (and that number is constantly climbing). Every conference I go to, and in every webinar, people seemingly always talk about DNSSEC and how usage is increasing. You might have some valid criticism about the cryptography; I would not be able to judge that (except when you are basing it on wildly outdated information). I’m not an expert on the details; you could most assuredly argue circles around me when it comes to the cryptography, and possibly about the DNSSEC protocol details as well. But, from my perspective, your continuous claim that “nobody uses” DNSSEC is simply false. DNSSEC works, usage of DNSSEC is steadily increasing, and new protocols (like DANE) are starting to make use of DNSSEC for its features. Conversely, I only relatively rarely hear anything about MTA-STS. (Repost of a two year old comment of mine: <https://news.ycombinator.com/item?id=27837530 https://news.ycombinator.com/item?id=27837530>, but the details given have not changed substantially.)
  - tptacek 3y ago
    (I vouched this comment, because I wanted to reply to it.) I'm not making the statistics up; you can just Google "DNSSEC deployment statistics" to see that I'm right about them, and I even provided a methodology in the comment you responded to for readers to verify for themselves. Where DNSSEC signatures are climbing, it's largely because of registrars that automatically sign domains for customers. That's security theater. Moreover, it's capturing the least interesting cohort of new DNS zones: random things people register. I own a bunch of them, including "atmosflat.org" and "paulgra-ham.com" (don't ask me, I don't remember). If I had registered them at an autosigning DNSSEC registrar, they too would count in the "steadily increasing" count to which you refer.
    - chrismorgan 3y ago
      Why/how is automatic signing of domains security theatre? As one not particularly involved, I’d have thought that was the goal, and certainly the only way you’re ever going to get anything but niche usage.
      - tptacek 3y ago
        The registrar controls your keys. Further: virtually all DNS hijacking happens via registrars, not the on- and off-path network attacks on the DNS that DNSSEC attempts to defend against. (I'm focused on the stats argument here, because I feel like 'teddyh was trying to imply that I was making them up --- he only ever sees me relating them, to which I'd respond "that's because nobody else cares about DNSSEC". I have, an, uh, pretty expansive case to make against DNSSEC, but here I was just sort of relying on context 'teddyh and I share. Sorry about that!)
        alwillis 3y ago
        > The registrar controls your keys. I've been managing domains with DNSSEC for several years and I've always had control of my keys. Clarification of who controls what keys [1]: The TLD zone's private keys are managed by the company operating it. For a Country Code Top-Level Domain (ccTLD), the government of the country will be managing the key. For popular TLDs like .COM or .NET, it will be the U.S. government through the operator Verisign. For popular ccTLD .IO, it is the government of British Indian Ocean Territory. The private keys for an individual domain name are managed by the domain owner either directly or via the DNS provider hosting their domain name. With DNSSEC, it is pretty clear who controls the private keys and also keeps the risks involved distributed. Which means while China holds private keys for .cn ccTLD, it can only sign domain names under it. [1]: https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-is-needed.html https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...
jeroenhd 3y ago
DNSSEC is widely supported and used in some countries but practically unused in others (https://stats.labs.apnic.net/dnssec https://stats.labs.apnic.net/dnssec) How easy it is to set up depends on where you host and bought your domain. In my experience, I needed to copy-paste two keys and it Just Worked. It's barely used in .COM though, so companies like Amazon took ages to implement even basic support for it, and their buggy services took down various websites. To top it all off, mistakes by badly managed TLDs caused downtimes for various TLDs over time, of "someone told the root servers to redirect .NZ to localhost for a week" severity. If whoever is managing your TLD cannot be trusted to maintain a TLD, don't enable DNSSEC. The protocol is Very 90s ("computers aren't fast enough to validate RSA signatures so let's centralise it"), but modern clients take all of the 90s bullcrap out of the picture. DNSSEC is in dire need of a v2 that fixes this, but I've never had much trouble with it in practice, other than when websites misconfigure their DNSSEC config.
- thayne 3y ago
  > other than when websites misconfigure their DNSSEC config One major problem with DNSSEC is that it is relatively easy to misconfigure it, especially in more complicated scenarios, and a misconfiguration can take you down for a long time.
  - bodgie 3y ago
    It can also be quite easy. Buggy complicated Route 53 and self-hosting with a buggy bespoke solution aren't the only options, but they are the only kinds of DNSSEC failures I've seen on the HN front page.
    - tptacek 3y ago
      The only failures you see on the HN front page are the ones that occur to gigantic companies we've all heard of, with huge networking teams and all the advantages you can ask for in getting DNSSEC working. When random small shops fall off the Internet because they broke DNSSEC, nobody cares; it never makes any front page anywhere.

woodruffw 3y ago

Very cool. It's a bummer it only works in Firefox with DoH, though. I couldn't find an explanation for why that is in the associated changeset[1]. (I would use DoH on my devices, but I run a local resolver for filtering purposes. The local resolver then connects to a global NS via DoH, but my local devices use plain old DNS.) [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1623126 https://bugzilla.mozilla.org/show_bug.cgi?id=1623126

sillystuff 3y ago
Depending on your local resolver, you possibly can provide DoH on localhost as well? I'm using unbound, and it was trivial to also provide DoH on localhost with a funky port, so 443 localhost remains available for other things (my motivation was that firefox also doesn't support ESNI without a DoH resolver; I assume this is still true for ECH as well, but haven't re-visited). For firefox, you can use a self-signed cert on your resolver (firefox did not work with ed25519, it did work with NIST P-256; I wanted a small key for lower overhead [having to use TLS + HTTP encapsulation for a resolver on localhost bothered me in irrational ways, and I was determined to minimize the overhead, even if the rational part of my brain said the overhead difference was too negligible to matter]). Add it with: edit-> settings -> (search "cert" in 'find in settings') -> view certificates -> (server tab) -> add exception -> enter the url: https://localhost:4353/dns-query https://localhost:4353/dns-query ensure "permanent" is checked The file, "cert_override.txt" is created by firefox after adding the cert exception, which can be copied to other profiles for provisioning. The gui DoH config will create the following in about:config which can be used for provisioning with user.js: network.trr.uri https://localhost:4353/dns-query network.trr.bootstrapAddress 127.0.0.1 network.trr.mode 3 trr true (network.trr.custom_uri is not used for anything but display in the gui) network.trr.custom_uri https://localhost:4353/dns-query I don't think chromium requires DoH for ESNI / HTTPSSVC, so it can just use plain-text localhost:53 as before. If it does need DoH for this, I do not know the equivalent to the above config, for chromium.
thayne 3y ago
It's because Firefox uses its own dns resolver when it uses DoH, but if DoH is disabled it just calls getaddrinfo from libc to look up a domain. And unfortunately getaddrinfo is a very minimal API, that doesn't have any way to resolve arbitrary record types like HTTPS or SVCB, it just returns ip addresses. There is a bug[1] for supporting HTTPS records when using the system dns, but I haven't seen much progress on it. And sadly, it probably requires different code for each OS. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1852752 https://bugzilla.mozilla.org/show_bug.cgi?id=1852752

remram 3y ago

Is there any guide for setting up ECH? Are we waiting for support in HTTPS server software?

Ayesh 3y ago
OpenSSL and Go crypt/tls has no support yet, so none of the webservers that depend on them support it. Apache, Nginx, and Caddy, they all need upstream ECH support first. - https://github.com/openssl/openssl/issues/7482 https://github.com/openssl/openssl/issues/7482 - https://github.com/openssl/openssl/pull/22938 https://github.com/openssl/openssl/pull/22938 - https://github.com/golang/go/issues/63369 https://github.com/golang/go/issues/63369

Ayesh 3y ago

I recently added HTTPS records to all of my domains, along with HTTP/3. From query statistics, I see that around 15% of the queries are for HTTPS records, 30-35% for A and AAAA records, and the rest for RR types like NS, TXT, etc. Browsers make HTTPS requests in addition to the A/AAAA, so this makes sense. In an ideal world, the ipv4/ipv6hints do the job if A and AAAA records, so a browser will only need to make an HTTPS request.

chrismorgan 3y ago
Note that ipv4hint and ipv6hint are not supposed to replace A/AAAA <https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv6hint https://www.rfc-editor.org/rfc/rfc9460#name-ipv4hint-and-ipv...>: > The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName per Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance. That is: you’re allowed to use the ipv4hint on this connection, but you should still fetch A/AAAA and use that subsequently.