1. 16
  1. 11

    I do still agree with Thomas Ptacek: DNSSEC is not necessarily.


    1. 2

      From that article:

      Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.

      1. 1

        Is that true, though?

        He would have been in a position to take over the public key, if he were willing to do so visibly. The DNS isn’t like a CA — a CA can issue n certificates for the same domain, but the DNS makes it difficult to give me one set of answers and you quite another, particularly if either of us is suspicious, as a monitoring service might be.

        Bit.ly controlled its own private key. Gaddafi’s possibility was to take over control of the domain and publish other RRs, in full view of everyone. A concealed or targeted attack… I don’t think so.

        1. 1

          Read the article, the quote comes from the part about DANE that extends DNSSEC, which is about putting public keys for TLS in TLSA resource records.

          Certificate Transparency has pretty much solved this for the CA system, where it is directly visible if unauthorized certificates are being used.

          1. 1

            I read it when it was new… I suppose things have changed a bit. The trened towards JSON-over-HTTPS has been very strong and gone very far, so securing only application protocols like HTTP isn’t as much of a problem as it was.

            DNSSEC and DANE provide assurance that a given IP address is what I asked for. But if IP addresses aren’t relevant, assurances about them aren’t either…

      2. 1

        So what do you think about DNS-over-HTTPS, which AIUI is also motivated by much the same thing, but only secures the path from the endpoint to the caching DNS server?

        I once saw advertising for some $%⚠雷𝀲☠⏣☡☢☣☧⍾♏♣⚑⚒⏁ game on my own website while holding a presentation. The venue’s WLAN “enhanced” my site. Both DNS-over-HTTPS and DNSSEC would have prevented that attack, at least if I had used google’s or cloudflare’s resolvers instead of the presentation venue’s.

        1. 1

          I do like that, although I would prefer that all authoritative DNS servers would implement TLS, so that my own recursor could do secure look-ups instead of only having a few centralized DoH resolvers.

          1. 1

            Oh, in that case you’d still have much the same bottleneck: You’d need to do DoH/DoT to the root/tld name servers, of which there aren’t many.

            1. 1

              Correct. But I’d like to see that development, which would be far better than DNSSEC.

        2. 1

          I feel like many arguments in this article are misleading and/or omit important details.

          DNSSEC is Cryptographically Weak

          Except.. it’s not. You can use ECDSA keys just fine for signing. Sure, you can use insecure keys. Just like you can use insecure keys or methods in TLS or pretty much anywhere else. We’ve come to distrust insecure configurations in TLS and we will probably have to move in that direction in DNSSEC. But first we should at least halfway get there.

          DNSSEC is Expensive To Adopt

          That seems to depend a lot on your point of view. A client trusting a validating recursor only needs to check a single flag in the DNS response to know if a record was signed correctly. Insecure results are therefore clearly visible and incorrectly signed results won’t be returned by the resolver. For clients, very little seems to need changing, but this is also the place where the least adaption has happened up until now.

          DNSSEC is Expensive To Deploy

          Two or three lines of configuration in knot-dns w/ automatic zone signing. No extra configuration on any of my nsd secondary servers. Not sure if I’d call that expensive to deploy. For a small zone, getting basic signing going is easier than configuring a Letsencrypt acme client. The biggest pain point is finding a registrar that allows you to set DS records for your zone.

          DNSSEC is Incomplete

          Securing the “last mile” is not what DNSSEC tries to do. We’ve got DoT and DoH for this, so that’s a different issue from a DNSSEC point of view.

          DNSSEC is a Government-Controlled PKI

          This is the only truely interesting point and it’s a difficult and interesing one for sure. Not sure if I’d open that can of worms right away, because the TLS CA system is also far from ideal. But I suppose it is true that DNSSEC has one central anchor for trust, which would usually be the keys for the root zone. It is of course also true that any local registrar might be influenced by a local government. But all of this is true today. The implications this has for DANE should probably discussed in the context of DANE and not of DNSSEC, but that’s just my 2 cents on this.