I asked GitLab if they could make use of that, but it hasn't received much attention so far:
* https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/10376
In fact, even if the original domain does support DNSSEC, can a userspace program such as the SSH client actually tell whether the record it just resolved was resolved using a DNSSEC-aware resolver?
There's an "ad" (Authenticated Data) flag in the DNS reply header that a resolver can set to 1 to indicate that it validated the answer, but an MITM can also just set that to 1. The client would have to do its own validation, and ssh(1) doesn't. Therefore, you can only safely use this if you use a DNSSEC-validating resolver, and you trust the resolver (e.g. you administer it yourself), and you have a trusted path between you and it (e.g. it's on your LAN).
If you're on Ubuntu, you most likely have a local resolver running already.
*: this is the definition of "work" that also means it won't resolve anything if anything is wrong with DNSSEC validation, but if you want to be secure you need it to fail closed.
That way most things will still work even DNSSEC is broken, and apps with higher security requirements can opt-in to "fail if invalid", by passing setting the AD bit on queries, and checking if it is still there on responses.
Isn’t this a gap in the API? res_query/etc should provide some way to find out if the response is validated or not. That would require either (1) a validating resolver running locally, or (2) a remote validating revolver, accessed over a secure protocol (such as DoT or DoH), which the system administrator has elected to trust. But the system should be able to tell applications, via some API, whether (1) or (2) hold or not
The man pages on my Linux box are too old to mention the trust-ad option, although newer Linux man pages do.
glibc defines a RES_TRUSTAD bit which is equivalent, so applications can choose to request and trust the AD bit even if resolv.conf isn't configured to do so. However, that doesn't appear to be documented anywhere other than the header file and the NEWS file in the glibc distribution. Both RES_TRUSTAD and trust-ad were added in glibc 2.31 (released Feb 2020).
EDIT: I meant for this to be a reply to my sibling comment.
The OpenSSH daemon could host it for you if you could fit a tiny, vuln free httpd inside it — not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Add ACME support and you’ve moved the TOFU MITM attack from being possible on every-new-client-connection to also having to coincide with the once-every-X-days for the HTTPS certificate renewal.
It’s a lot of new functionality which probably isn’t cool for the OpenSSH codebase, but it’s a pragmatic solution to plugging the gap between mankind’s universally deployed PKI and ssh’s ephemeral peer-to-peer verification.
> but it's a pragmatic ...
I think we have different views of the word pragmatic if your pragmatic solution covers including a HTTP server in OpenSSH for serving a single (!) file while the other solution depends on something you most probably already use to connect to the server (DNS).
The harder part is what is the client going to do? How will you implement TLS at each end? Your ssh client will want to link against an HTTP library that integrates with the client OS’s x509 PKI. That will be the axiom upon which your trust of the server is founded. OpenSSH’s client might trust their ssh host key because it was served in a connection signed by Let’s Encrypt, and the local copy of libcurl used libssl which found Let’s Encrypt in /etc/ssl/cacerts.pem etc etc.
The hardest part is adding a TLS implementation to the OpenSSH daemon and the crazy part is having it support ACME so it can fetch its own certificates**. There is precedent for this though — caddy includes support for negotiating issuance and renewal of SSL certificates via ACME:
Adding a new feature like this comes with the responsibility of supporting it in production and fixing bugs (in this case, dealing with weird missing features) for the remaining lifetime of the product. It’s not something to be done as lightly as an HN comment, by any means. There are a lot of sensible reasons to use DNS to bootstrap trust but as others have pointed out it is a little naive to think that DNSSEC has anything like the level of deployment that HTTPS has achieved since ACME and Lets Encrypt showed up. I contend that it’s that aspect which makes my solution indeed a more practical method — pragmatic, even — of bootstrapping trust over The Internet in 2023.
* Yes, this will mean you cannot support clients that demand their content be encoded with xzip in ylang with zspace. We’re not writing a real httpd here, remember.
** If it’s using ACME HTTP then that makes the simplistic httpd a bit more complicated, of course. Now you have to blurt two responses instead of one.
Yeah then you got at least two more problems. SSL and OCSP
I have bunch of personal servers, and bunch of keys in use, many of the servers are not automated (they're pets, not cattle), so when I rotate keys, it's sometimes a hassle.
Mostly asking just because it'd be fun.
Far better is to use SSH host certificates, then your known_hosts can simply have a @cert-authority * some-cert in it. (See https://www.lorier.net/docs/ssh-ca.html)
The suggested alternative using certificates is a much more standard way that has less ways to create holes in your security.
The command would basically hit "keys.my-domain.example" and return the values of each TXT record. Not sure what could go wrong here, besides if I lose DNS access, I won't have access to the boxes. Probably add some sort of caching as well for that.
But otherwise, it seems to be much more about the security of what goes into "keys.my-domain.example".
Unfortunately the user experience for a DNSSEC signature failure is so bad, the only option if you run a large ISP or corporate network is to just use the answer you get anyway.
In fact, I see a lot of people advocating for using centralized resolvers, and not even once have I seen a counter-argument in the form of DNSSEC validation being a problem.
Many recursive servers do validate DNSSEC, but disable it on a per-zone basis when validation failures happen and users start to complain.
tptacek raises an additional good point that DNSSEC does nothing to protect the last mile of a query. It also provides zero confidentiality.
dnscrypt was always a superior implementation, but saw little uptake because people blindly believed the DNSSEC propaganda.
If validation failures were that common, I would think I, working at a domain registrar and authoritative DNS provider, would hear about it. The last mile problem would be solved by DoT/DoH, no?
If anything is a “dead horse”, it’s dnscrypt. Are you claiming that DNSSEC is some sort of industry conspiracy?
It's very easy to just check this for yourself. There are increasing numbers of domains signed every year, because registrars and product companies have baked DNSSEC in as a feature. But the vast majority of zones don't matter: nobody ever looks anything up in them. The figure of merit is how many important zones are signed.
Amusingly for this method to work the resolver must understand DNSSEC. This is because DS records exist solely at the parent side of a delegation. A resolver that is not aware of DNSSEC will look to the child as it would for any other kind of record type.