A prior company I worked at had API keys (like AWS) in TXT records that would be used in some bootstrapping. Thats uhh, certainly a convenient place to put them, yeah.
In practice, there’s no such thing as “private” DNS. You can disable zone transfers and type “ANY” queries, but NSEC records of DNSSEC enable name enumeration, and public resolvers record and often publish the queries done through them.
Do not put any private information in DNS. It’s not made for it, and many, many systems which work with DNS assume in their design that all DNS data is public.
The DNS data is still not encrypted over the wire, and clients could use their own local resolver which in turn uses the private resolver. This local resolver will most probably be designed with the assumption that DNS data is public.
Route53 private DNS is resolved over link-local addresses, so whether the responses are encrypted is irrelevant. They're specifically designed for private resolution within a VPC.
Link-local networking in VPC is specifically designed to secure data that is plaintext at the application layer (DNS). It’s effectively communication with the hypervisor, not over some untrusted link.
If you don’t buy this, I guess you should start encrypting all your syscalls too?
If you believe a piece of link local infrastructure is a good carrier to trust your data, I have some great broken switches you may be interested in buying.
Or if you insist on it being a virtual stack, how about some DMA engines with transient errors that mix up your packet headers from their payloads?
Another fun one I learned about recently: `e164.arpa` is a reserved domain for E.164 phone number to Internet address lookups[1]: you can query it for NAPTR records, which tell the client how to initiate a call over the Internet (via SIP) instead of over PSTN.
I worked in that space for over a decade. While it's true, the use of E.164 in production was never done (usually, it's some subdomain from the Oligarchic Cell Phone companies). Second, it's never free. Nothing on the telephony network is free. Third, you get back data that includes a regex on how to transform the other data into something you can use---very convoluted.
Verizon for one, at least in the US. I know I used e164.arpa for testing purposes, until new management came in and demanded we use the domain we use in production for testing (because, well, production, I guess? Keep the configs as the same as much as possible?).
Now that I've name names (or a name), how about you? Who uses e164.arpa?
TL;DR: HTTPS records are like SRV records without the weight number (but, crucially, including the priority number), and with some extra stuff to make the TLS handshake happier.
Note that there are both HTTPS and SVCB record types.
Regardless of the standard being finalized there's already some support in the wild. To name a few prominent ones iOS, macOS, Cloudflare, Akamai, and NS1 all support both types.
This is the kind of stuff that makes the internet fun. I really like the types of projects that exist simply to exist. People putting out things that have no reason except for the enjoyment.
It seems like we're missing this kind of stuff lately. Even the April 1st hacks have failed to be interesting on the same level. I wonder what has happened and why.
Yeah, and then this "enjoyment" spills into real-life widely used programs, s.a. Kubernetes. This is literally me, yesterday discovering a little "gotcha" of an L7 reverse proxy in Kubernetes:
# netstat $(hostname) 40443
Trying 10.X.X.X
Connected to hostname.foo.bar
Escape character is '^]'
...
# ss -tpln | grep 40443
#
# lsof -i :40443
#
This kind of fun makes you want to punch each individual ITF member as well as people in Kubernetes who decided it'd be cool to implement L7 proxy using DNAT.
No, seriously, there is no L7 reverse proxy implemented using kube-proxy mechanism (aforementioned DNAT) - It's L4 proxy for supporting legacy code that doesn't support intelligently querying for endpoints (by SRV record, k8s API, or other service discovery protocol).
It's not even required to use it, Services can be declared to not need it (common example is using service mesh or ingress controller with http)
Which doesn't use DNAT unless you explicitly configure it to do so.
nginx-ingress will read Service Endpoints through k8s API and resolve connections to specific pod IPs so long as your network is properly deployed.
Of course it's also possible to make it go through serviceIP (which by default is still implemented using DNAT in kube-proxy), but it's not recommended.
NodePorts like the example given earlier exist for dealing with external traffic from hosts unaware of (possibly unroutable) serviceIP and podIP ranges.
I had lots of !FUN! with nginx-ingress, but that's not one of its faults.
I had set up dnsmasq once and spotted all these weird DNS requests coming out of our network. Turns out some Java installation builder software was using DNS to verify the license status of the software. They would do a lookup something like
You can bypass captive portals by using some of the ideas displayed in this presentation, but you will probably also need to have a server with a good unmetered connection and a cleverly named (sub)domain.
- The One True Sysadmin will look through all the logs and find your server and block it and you'll have to pick another one next time
- The One True A(G)I will find your domain automagically and block it and you'll have to pick another one
...In all seriousness several MB of data to a DNS server will get you bitten at least once because someone somewhere is actually doing the job they're paid to do. But it'll probably be an exception.
As another replier noted, you might evade detection. But the reason I mentioned it is that captive portals (before authenticating) may not allow you at all to do DNS queries... except, for their own whitelisted domains. Depending on how they do it and how they wrote their rules, if they allow example.com you could potentially query example.com.mydomain.com
Tangentially related: One can store SSH server host keys in DNS and tell the client to make use of them. (OpenSSH supports `VerifyHostKeyDNS=yes`.) This is an alternative to the client asking the user to confirm the server host key, which many people just blindly confirm.
I asked GitLab if they could make use of that, but it hasn't received much attention so far:
You'd need DNSSEC for this right? If not can't an MITM still intercept the DNS lookup and substitute their own key?
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?
Yes, you would need a DNSSEC-validating resolver, and no, ssh(1) can't confirm if the answer was actually validated or not.
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).
An example to work around this would be to run a validating resolver (for example unbound) on localhost of each host and have it forward to whatever DNS server you use today.
If you're on Ubuntu, you most likely have a local resolver running already.
On Ubuntu the default is to use systemd-resolved, which is actually a validating stub resolver. You just need to set DNSSEC=true (see man resolved.conf) and it will work*.
*: 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.
Perhaps a solution such as dnscrypt-proxy and configuring it to forward requests that match certain patterns to a validating resolver on the local network would work? Requests that didn't match could be forwarded to some other resolver that wasn't configured to validate.
There should be an option for "validate but still return invalid data, just reflect validity in the AD bit". Is there?
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.
> and no, ssh(1) can't confirm if the answer was actually validated or not.
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
This is [was; the quote in the parent was edited] incorrect, the response includes `header.ad`, which on Linux is controlled by both what the resolver responds with and `option trust-ad` in /etc/resolv.conf, so the administrator can choose if they trust their resolver via "trust-ad".
Thanks for clarifying, that makes more sense. I was just going by what the person I was replying to was saying.
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).
Yes, I mentioned the AD header. However, I stand by my statement that ssh(1) cannot confirm whether the answer was actually validated because an MITM could have set that flag.
EDIT: I meant for this to be a reply to my sibling comment.
If ssh is using the GNU C Library’s resolv functions, and it isn’t setting RES_TRUSTAD, then glibc will automatically clear the AD bit unless the sysadmin has configured the trustad option in resolv.conf. A competent sysadmin would only do that in cases where MITM is impossible - either a local validating resolver, or DoT/DoH to a remote validating resolver. It is true that ssh has to trust the sysadmin to be competent and not enable that option in cases where MITM is possible, but I think that’s a general assumption for security that the sysadmin is doing the right thing, otherwise there are numerous other possible insecure configurations which might break ssh’s security. To double foolproof it, ssh_config could come with its own trustad setting independent of resolv.conf, so you’d have to set both.
In that vein, is there something that could allow me to manage authorized_keys via DNS? Let's say I own capableweb.com, I'd love it if sshd could just read all records from keys.capableweb.com and use those as valid public keys.
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.
As mentioned elsewhere in this thread, actually using SSHFP in a secure way is difficult.
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)
Maybe I'm missing something obvious, but seems to be much more up to the security of my DNS setup rather than the command.
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".
That's what I meant. Just looking up a DNS record as an implementation sounds like a bad idea. You would have to set up thinks like DNSSec validation, and consider all the ways in which that could fail.
The cleanest way in your use case would be to store keys in an LDAP server instead of local users' authorized_keys
You can plug any of your server to this LDAP and enjoy the same users and keys everywhere.
An SSH certificate authority is what I’d choose for that. Can work with both user keys and host keys. The host certs have a field for demonstrating their hostname; the user certs have a field restricting their username. So, as the certificate authority you have a little more power than what you can distribute via DNS.
I’ve set up an AuthorizedKeysCommand that uses unbound to get the authorized keys for the server via DNSSEC, with the ability to specify keys for whole servers, users on servers or globally for all servers. This is pretty neat for my few private boxes, I wouldn’t advise it for something bigger or enterprise, an ldap or similar seems better for that.
People scaling SSH authorization tend to set up SSH CAs (either directly, or baked into some higher-level management solution). SSH CAs scale down nicely, as well.
Please don't put security stuff in DNS. DNS isn't secure and DNSSEC is a travesty. Just take the records it gives "under advisement" and confirm it over TLS or another secure transport protocol.
The rate of DNSSEC signed zones is growing, but the number of recursive resolvers that hard fail on validation failures is static or going down.
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.
Since (regrettably, for other reasons), many people seem to be moving to use centralized resolvers which all, incidentally, do validate DNSSEC strictly, I doubt whether “number of recursive resolvers” is a valid proxy for “number of users using DNSSEC validation in practice” anymore.
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.
What does it matter if your centralized resolver across the Internet is doing DNSSEC? The same on-path attacker DNSSEC was designed to address can defeat DNSSEC on the path between you and the resolver. It's a baffling design.
It matters because the topic was whether DNSSEC is growing or not, specifically whether more or fewer users are using DNSSEC validating resolvers. You’re not just moving the goalposts, you’re changing the topic entirely.
The horse has been beaten to death - DNSSEC is dead. It continues to see adoption on the authoritative side because turning it on in a basic state and letting it limp along costs almost nothing.
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.
From my perspective, DNSSEC is very much alive, and moreso every year. At work, we only ever see requests for more DNSSEC from everybody; both customers and TLDs/registries. Nobody at conferences, both formally and in informal conversations, has said anything against DNSSEC in principle. I used to say that I ever only saw one person argue against DNSSEC; and it was here on HN. I guess that I can now say that it is two people, both here on HN.
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?
What “industry” would that be? Certainly not the DNS industry, or their customers (i.e. anybody who wants a domain name). Do you mean “rejected” in the same sense as how IPv6 is still only slowly being adopted?
Grab any list of the top domains on the Internet. My go-to has been the "Moz 500" --- I don't know what it is, or whether it's any good, but it's easy to get. Then write the trivial shell loop to `dig ds $domain`, and count how many of the top domains are signed. Some patterns will emerge: government sites, unsurprisingly, have subscribed themselves to the de jure government PKI that DNSSEC is, and commercial sites overwhelmingly do not.
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.
This is fun but a more practical solution would be for “ssh host” to GET the host’s public key from https://host/.well-known/.
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.
However I'd wish the reverse is true, SSH via TLS connections, so I don't need to open another 22 port, and make my SSH hidden behind Cloudflare or something.
So one needs to run an HTTP-Server for a host that only has SSH otherwise?
> 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).
Hah, I’m surprised you zoomed in on that part. All you have to do for the protocol is blurt out “HTTP/1.1 200 OK\n\nssh-rsa AAAAf00fcafe…=“ on port 443 instead of “SSH-2.0-OpenSSH_xyz EtcEtc” on port 22. I wouldn’t (and didn’t) suggest you include code to respond with the contents of files, nor should you even bother parsing the request*.
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.
Someone in the old days was playing around with VERY small RSS feeds in DNS TXT records. The slides mention blogging but at a UI level whereas this was "what if we put actual RSS feeds in DNS?" There was some sort of multiline protocol; don't remember how it worked. It never gained traction but I thought it was cool.
There was also something very weird with VRML files in the early 90s, like favicon but in 3d and shipped over DNS kind of idea. Yeah that got about zero traction also.
While those are (mostly) dead now, it would be unfair to say they never took off. In their day some of these were huge,and enormously influential on what we have today.
News (NNTP) basically _was_ the Internet before HTTP came along, and still exists today, albeit in niche form. I still check News every day.
Your standard seems to be "things that were one popular, but have been replaced." whereas the 90's were full of ideas that literally never took off. Like cuecat https://en.m.wikipedia.org/wiki/CueCat
And don't get me started on the blink tag. That was huge, if anything, overused. That was activly killed (for good reason) because it made most Web pages beyond horrible. For some reason non-computer people weren't happy unless like half the site was blinking all the time. It was beyond terrible.
Frankly the jury is still out on VR headsets (an idea from the 60s that simply won't die.)
I remember 15 years or so; a friend and I figured out that DNS got through my friends cellular connection even though the data limit were reached.
We tested and set up a socks-over-dns-proxy back then and it worked! We loled and then never did anything more than that unfortunately (or it depends, we´d most likely be detected if we continued to use that, eh, solution).
About 15 years ago as well, a cruise ship I was on blocked most connections if you hadn't paid, but allowed DNS, so I tunneled some vpn over dns and it worked.
This is really common in ‘airgapped networks’ so much that tools exist to create tunnels. I tested this on a job and upstream dns servers blocked me after about 1mb of traffic, it’s an abuse of a public service and a complete waste of resources (5-10x amplification) so something that’s completely understandable.
I imagine 10 years ago, controls may not have been so good though.
Edit: part of the rationale in some cases, I believe, is to facilitate captive portals for hotel wifi login etc.
Reminds me of a hack with X.25 networks. Certain packet types werent billed, so people used them to communicate (something like hiding information in ICMP packets).
I know of at least one serious security incident (maybe this is mentioned in the talk but I didn't hear it) in which data was exfiltrated from the victim's network by patiently making successive dns queries, which were of course unfiltered as they were considered innocuous, for long hostnames in which segments of the data were encoded. It was not an easy thing to patch.
I'm not sure if this was covered in the presentation, but DNS Toys (which can for example tell the weather, do units conversions, etc.) was featured on HN about 8 months ago:
I was once working on a way to minimize PAC [1] file changes and came up with a hacky way to use DNS for this. The client would use isResolvable(parsedhost.pactest.int.domain.com) after some parsing of host, and use the result of the test to return either a PROXY result or DIRECT.
It resulted in an extra DNS query for every site being accessed, but because the query is internal and the client caches the result, it didn't add much load but otherwise worked well. Then it was just a matter of automating A record creation.
153 comments
[ 2.6 ms ] story [ 222 ms ] threadDo not put any private information in DNS. It’s not made for it, and many, many systems which work with DNS assume in their design that all DNS data is public.
— https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
If you don’t buy this, I guess you should start encrypting all your syscalls too?
Don't forget to encrypt all .socket's, and maybe encrypt everything over at /dev as well.
Or if you insist on it being a virtual stack, how about some DMA engines with transient errors that mix up your packet headers from their payloads?
The network is secure is a fallacy.
[1]: https://www.ietf.org/rfc/rfc2916.txt
Now that I've name names (or a name), how about you? Who uses e164.arpa?
https://www.lastweekinaws.com/blog/route-53-amazons-premier-...
TL;DR: HTTPS records are like SRV records without the weight number (but, crucially, including the priority number), and with some extra stuff to make the TLS handshake happier.
Regardless of the standard being finalized there's already some support in the wild. To name a few prominent ones iOS, macOS, Cloudflare, Akamai, and NS1 all support both types.
https://github.com/MikeBishop/dns-alt-svc/blob/main/svcb-imp...
Yes, but the topic was web browsers, which would use the HTTPS record, not the SVCB one.
It seems like we're missing this kind of stuff lately. Even the April 1st hacks have failed to be interesting on the same level. I wonder what has happened and why.
No, seriously, there is no L7 reverse proxy implemented using kube-proxy mechanism (aforementioned DNAT) - It's L4 proxy for supporting legacy code that doesn't support intelligently querying for endpoints (by SRV record, k8s API, or other service discovery protocol).
It's not even required to use it, Services can be declared to not need it (common example is using service mesh or ingress controller with http)
nginx-ingress will read Service Endpoints through k8s API and resolve connections to specific pod IPs so long as your network is properly deployed.
Of course it's also possible to make it go through serviceIP (which by default is still implemented using DNAT in kube-proxy), but it's not recommended.
NodePorts like the example given earlier exist for dealing with external traffic from hosts unaware of (possibly unroutable) serviceIP and podIP ranges.
I had lots of !FUN! with nginx-ingress, but that's not one of its faults.
$LICENSE_NUMBER.$NAME.$ZIPCODE.example.com
and the reply would indicate the license status.
Using DNS to exfiltrate arbitrary data thru firewalls that don’t log DNS requests is handy too.
What do you mean here?
- The One True A(G)I will find your domain automagically and block it and you'll have to pick another one
...In all seriousness several MB of data to a DNS server will get you bitten at least once because someone somewhere is actually doing the job they're paid to do. But it'll probably be an exception.
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.
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)
https://github.com/shoenig/ssh-key-sync
https://man.openbsd.org/sshd_config#AuthorizedKeysCommand
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".
https://www.keystash.io
https://www.pgp.guide/pgp_dns/
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.
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:
https://caddyserver.com/
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
There was also something very weird with VRML files in the early 90s, like favicon but in 3d and shipped over DNS kind of idea. Yeah that got about zero traction also.
News (NNTP) basically _was_ the Internet before HTTP came along, and still exists today, albeit in niche form. I still check News every day.
Your standard seems to be "things that were one popular, but have been replaced." whereas the 90's were full of ideas that literally never took off. Like cuecat https://en.m.wikipedia.org/wiki/CueCat
And don't get me started on the blink tag. That was huge, if anything, overused. That was activly killed (for good reason) because it made most Web pages beyond horrible. For some reason non-computer people weren't happy unless like half the site was blinking all the time. It was beyond terrible.
Frankly the jury is still out on VR headsets (an idea from the 60s that simply won't die.)
Edit: never mind, these are dead now, but they definitely took off in their day.
“I just really like looking up A records from dig”
I imagine 10 years ago, controls may not have been so good though.
Edit: part of the rationale in some cases, I believe, is to facilitate captive portals for hotel wifi login etc.
https://www.softether.org/1-features/1._Ultimate_Powerful_VP...!)
http://decss.zoy.org/
DNS Toys (946 points) https://news.ycombinator.com/item?id=31704789
Fun fact: you can store ~64 kB of data in a single TXT record
It resulted in an extra DNS query for every site being accessed, but because the query is internal and the client caches the result, it didn't add much load but otherwise worked well. Then it was just a matter of automating A record creation.
[1] https://en.wikipedia.org/wiki/Proxy_auto-config