> DNS as a Password Manager? Shades of the old NIS+/AUTH_DH/mech_dh scheme. That's a scheme that Sun used in 1987 for NFS security and for authentication. It

> DNS as a Password Manager? Shades of the old NIS+/AUTH_DH/mech_dh scheme. That's a scheme that Sun used in 1987 for NFS security and for authentication. It goes like this: - there is a name service called 'publickey' (i.e., with a getent style API, a 'files' backend, so /etc/publickey, and a NIS+ backend for domain-based authen.) - each publickey(5) entry has: - the name ("netname") of the entity - a DH group identifier - a DH public key and - the corresponding DH private key encrypted in the entity's password To login you in the system would prompt you for a username and password, lookup your entry in the publickey(5) name service, if found then it would decrypt the private key and confirm that the public key matches. To authenticate to a remote service the system would find that service's publickey(5) entry, compute the shared DH secret, and send a message with the local and remote names, a nonce, and a proof of knowledge of the shared secret. Anyways, you could store publickey(5) in DNS, naturally, if you wanted, though that was never implemented because mech_dh simply died of disuse. It's worth noting that the DNS is mostly public. Yes, you can make zone iteration hard, but not impossible. So if you publish secrets encrypted in low-entropy keys (like typical passwords) then those will be subject to cracking. I do think mech_dh, modernized with ECDH and PQ key agreement, could make a lot of sense to revive. I could totally see a new scheme that's a cross between mech_dh, Kerberos, and JWT.