Comment by gunapologist99 | Hacker News Reader

Comment by gunapologist99 | Hacker News Reader

You could also securely hash a username and password together with something like argon2ID, and then authenticate users by seeing if the base64'ed TXT record exists. No need to hit an overloaded database, just dig and you'll even have the benefits of local caching with per-record TTL's!

But should you do crazy things like this? Absolutely not!

DNS is notoriously prone to MITM, injection, cache poisoning, DoS, etc. DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way.

Even though it's the foundation of almost everything we try to do securely, including the basis for TLS DV certificate (totally fungible, regardless of a hundred or so certificate authorities, including many located in authoritarian regimes!) validation:

DNS is absolutely and irredeemably broken forever, from a security perspective, and can never be fixed. As tempting (and easy) as it is to hack on it or treat it as an ultra-fast and extensible UDP remotely-accessible lookup database, just don't. (It just needs to die in a fire, probably along with SMTP.)

Unfortunately, even if someone came up with some system that could credibly replace it, that system would inevitably have a LOT of privacy and censorship trade-offs, so DNS is what we're stuck with.

Just stay very aware of the risks of encoding anything security-related inside DNS and try to minimize your reliance on it as best you can.

I am just stopping by to say that this is actually a thing. It is called hesiod and works great in small, maybe air-gapped networks.

As a side note, anything security related exists in the reality of uncertainty. It is expected that sharing properly secured secrets is reasonably safe, but day after day we discover "we didn't know". Sometimes simplicity for a particular application is worth certain amount of risk.

Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...

For quick reference: - https://en.m.wikipedia.org/wiki/Hesiod_(name_service) - https://jpmens.net/2012/06/28/hesiod-a-lightweight-directory...

Hesiod was actually a thing. I'm not aware of anyone who has run it in production in the last 20 years, perhaps you are? But, in any event, password technology was immature and insecure then (i.e. RMS got upset when passwords were introduced, or remember how easy it was to crack 3DES in /etc/passwd so /etc/shadow came to be).

It's even worse now, even on an air-gapped network, because the underlying insecurity is still within DNS. DNS would make a great highly-scalable authn DB for non-UNIX accounts (not in the Hesiod sense, but more in the modern web-app sense), except for all of the other high-scalable and secure authn DB's that aren't built on top of woefully insecure tech.

> It is expected that sharing properly secured secrets is reasonably safe

As you know, though, this is why Diffie and Hellman invented public key exchange -- because sharing secrets, even properly secured, is actually not reasonably safe at all in most circumstances. Even if you secure the secret, it's the communication of those secrets during the sharing where everything breaks down. (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...)

This is of course because a secret is not a secret as soon as you share it with someone else. Instead, DH designed their key exchange to have a private key, that only you know, and a public key that you can share. Each party can derive a shared key using the other's public key, but only they each know their private key.

> Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...

Even though perfect security is obviously impossible, it's still worth striving for. Relying on DNS for more than absolutely necessary is choosing to rely on technology that began without any thought to security and ended up with a history of massive, Internet-wide vulnerabilities. (See elsewhere in the thread for a great Wired article on Dan Kaminsky's successful attack on all of DNS.)

> DANE and DNSSEC are horrible bodges that don't actually do anything useful or in a secure way.

Adoption is extremely poor, usability is horrible, and the approach used is quite dated, but I'm not sure DANE and DNSSEC are insecure. Did you have a reference on the latter?

https://sockpuppet.org/blog/2015/01/15/against-dnssec/ is relevant.

This is quite dated, unfortunately.

How so? Has DNSSEC appreciably changed since 2015?

No. The case that post makes has gotten stronger since 2015, not weaker.

I agree with the idea that one should not trust DNS with any information one does not want public. I'm not totally convinced DNS is irreparably broken though. What are your thoughts on DNS over HTTPS?

DNS over HTTPS secures the connection between the client and their resolver. It doesn't improve anything else. It's still vulnerable to tampering at the still insecure connection between the resolver and the authoritative DNS server.

Reply on news.ycombinator.com