DNS security

I just got all my domains DNSSEC signed, DS records etc.

The .tech TLD had a bug only allowing one DS record. After about a week of a ticket with my registrar (they opened a separate upstream ticket to the .tech registry) - it was fixed.

Your image is of the DNSViz service - it was invaluable to troubleshooting my issues as I tried to get everything configured properly.

I thought DNSCrypt and DNSSEC were different things but maybe I'm wrong

>>60613549
They are.

>>60613509
DNSViz is a super helpful tool, indeed. Why would you need multiple DS RRs in your parent domain for your own domain, though?

So, I'm a chump who owns a couple of computers and an RPi. What should I know about DNS security?
It seems like a topic for server managers.

>>60614220
Depends. Are you hosting anything accessible from the Internet, for example?

>>60614270
Not really hosting, but I'm planning on making the RPi remotely accesible from the internet.
SSH mostly.

>>60614327
Then you might at least benefit from DNSSEC by adding your SSHFP RRs to your DNSSEC secured zone. Then next configure your SSH clients to check the server's fingerprints with the SSHFP RRs in your DNS zone for each time you connect. This can make sure someone else isn't redirecting you to a rogue server. Otherwise there's a slight (by design) Trust On First Use (TOFU[1]) weakness, meaning that you have to make sure the fingerprint you're presented with truly matches your server's fingerprint when connecting with the client for the first time.

Apart from that, you might also benefit in general form a DNSSEC enabled resolver (Unbound[2], for example) for all the queries you send out when connecting to other websites. Many website (but not nearly enough yet) secure their domains with DNSSEC so that you can be sure you're connecting to the right servers. So it's not just for server managers; everyone can benefit.

[1] https://en.wikipedia.org/wiki/Trust_on_first_use
[2] https://unbound.net/

>>60614127

Following the guidance in:

https://tools.ietf.org/html/rfc4509

Essentially one DS of SHA1 and one of SHA256.

>>60614700
I still don't get why you'd need multiple, since you should at most deploy one. Deploying two DS RRs, one SHA-1 and one SHA-256 feels like a transitional hack to support resolvers that can't handle SHA-256 yet, which is weird enough to begin with. Moreover, SHA-1 is considered unsecure since practical attacks[1] are possible. Use SHA-256 or higher wherever possible now.

[1] https://shattered.io/

>>60614327
VPN server, don't make SSH internet-facing

>>60615035

You're right, this is essentially legacy guidance at this point (SHA1).

Can I simply remove the SHA1 DS record from the registrar ? (I.e. nothing to be done with ZSK/KSK ?)

I tried this on a test domain, and validating caches, DNSViz etc all say it's a-ok. The 'getds' command line tool from dnssec-tools does bitch about it though saying there is a missing DS record.

>>60615514
As long as you have a valid SHA-256 DS RR (digest of your current KSK/ZSK) in your parent domain, DNSSEC will work as intended.

I'm not sure about the error you're getting from dnssec-tools, but if DNSViz says it's OK, and you can verify it yourself with your own DNSSEC resolver (e.g. Unbound with the trusted root anchor) you're perfectly fine.