Hacker News Reader

Comment by deepsun | Hacker News Reader

How to make it DNSSEC?

With Knot, you can just add ~8 lines to your config [0], copy the records to your registrar, and then you're done.

[0]: https://www.knot-dns.cz/docs/3.5/singlehtml/index.html#autom...

Knot does make it quite easy. Also, their devs are very responsive to support questions on their mailing list. It is currently my favored DNS.

Knot (as suggested by others) is good. As are BIND and PowerDNS. These are the big authoritative resolvers I think of at least, and all of them allow for basically hands-free DNSSEC; just flip a switch and you'll have it. I've run DNSSEC with all three and have no complaints.

And when using such turn-key DNSSEC support, I think there's very little risk to enabling it. While other commenters pointing out its marginal utility are correct, turn-key DNSSEC support that Just Works™ de-risks it enough for me that the relatively marginal utility just isn't a concern.

Plus, once you've got DNSSEC enabled, you can at the very least start to enjoy stuff like SSHFP records. DANE may not have any real-world traction, but who knows what the future may bring.

If you don't absolutely have to, then don't.

That is to say, if you misconfigure it, or try to turn it off, you will have an invalid domain until the TTL runs out, and it's really just not worth the headache unless you have a real use case.

I consider it as basic security measure as SSL. Otherwise any MitM can easily redirect users to a phishing resource.

Did DNSSEC for company website, worked with zero maintenance for several years. On a cloud-provided DNS. Would want the same on self-hosted DNS too.

"Otherwise any MitM can easily redirect users to a phishing resource."

Yes, but with nowadays https/tls usage it's almost irrelevant for normal websites.

If bad actors can create valid tls certs they can solve the dnssec problem.

> If bad actors can create valid tls certs they can solve the dnssec problem.

I think you have it backwards: by not running DNSSEC it can mean bad actors (at least a certain level) can MITM the DNS queries that are used to validate ACME certs.

It is now mandated that public CAs have to verify DNSSEC before issuing a cert:

* https://news.ycombinator.com/item?id=47392510

So if you want to reduce the risk of someone creating a fake cert for one of your properties, you want to protect your DNS responses.

If you mean MITM between DNS Server and CA (e.g. letsencrypt), thats on a level of BGP hacking (means for me government involved) and means they can just use a CA (e.g. Fina CA 2025 with cloudflare).

I think the risk didn't change much (except for big corp/bank).

At one point (pre-HTTPS ubiquity) the NSA hacked (e.g.) Belgium telecoms via injecting malware into web response from (e.g.) Slashdot:

* https://thehackernews.com/2013/11/snowden-reveals-gchq-plant...

* https://www.aclu.org/documents/quantum-insert-diagrams

* https://en.wikipedia.org/wiki/Man-on-the-side_attack

Still state-level, but probably less noticeable than BGP hijacking.

Unless you're entering IP addresses in all your applications and code, non-SEC DNS is an unsecured link in the chain of communications.

If you're a masochist you can do it manually, just make sure you have a good grasp of whats going on first[1]

Simplistically you need a DS record at your registrar, then sign your zones before publishing. You can cheat and make the KSK not expire, which saves some aggravation. I've rolled my own by hand for 10 yrs with no dnssec related downtime

[1] DNSSEC Operational Practices https://datatracker.ietf.org/doc/html/rfc6781

Reply on news.ycombinator.com