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.)