3 ms·

How to make it DNSSEC?

by deepsun 7mo ago

adiabatichottub 7mo ago
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.
- deepsun 7mo ago
  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.
  - 0x073 7mo ago
    "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.
    - throw0101d 7mo ago
      > 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 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.
      - 0x073 7mo ago
        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).
        throw0101d 7mo ago
        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-planted-malware.html https://thehackernews.com/2013/11/snowden-reveals-gchq-plant... * https://www.aclu.org/documents/quantum-insert-diagrams https://www.aclu.org/documents/quantum-insert-diagrams * https://en.wikipedia.org/wiki/Man-on-the-side_attack 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.
gucci-on-fleek 7mo ago
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#automatic-zsk-management https://www.knot-dns.cz/docs/3.5/singlehtml/index.html#autom...
- adiabatichottub 7mo ago
  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.
jcgl 7mo ago
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.
petee 7mo ago
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 https://datatracker.ietf.org/doc/html/rfc6781

How to make it DNSSEC?

by deepsun 7mo ago

How to make it DNSSEC?

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.

deepsun 7mo ago
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.
- 0x073 7mo ago
  "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.
  - throw0101d 7mo ago
    > 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 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.
    - 0x073 7mo ago
      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).
      - throw0101d 7mo ago
        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-planted-malware.html https://thehackernews.com/2013/11/snowden-reveals-gchq-plant... * https://www.aclu.org/documents/quantum-insert-diagrams https://www.aclu.org/documents/quantum-insert-diagrams * https://en.wikipedia.org/wiki/Man-on-the-side_attack 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.

gucci-on-fleek 7mo ago

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#automatic-zsk-management https://www.knot-dns.cz/docs/3.5/singlehtml/index.html#autom...

adiabatichottub 7mo ago
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.

jcgl 7mo ago

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.

petee 7mo ago

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 https://datatracker.ietf.org/doc/html/rfc6781