3 ms·

> A DNSSEC signature for "this domain doesn't exist" is much longer than a DNSSEC signature for "this domain exists, but doesn't have the type of record you ask

> A DNSSEC signature for "this domain doesn't exist" is much longer than a DNSSEC signature for "this domain exists, but doesn't have the type of record you asked for" so these providers choose to always return the latter type of answer This seems like a major design flaw in DNSSEC, if so. (I don’t have an opinion on whether Cloudflare or whoever else is a good participant in the DNS.)

formerly_proven 4mo ago
Most of the time people are not asking for domains which don't resolve. Also, think about what DNSSEC is actually having to do when signing an NXDOMAIN. It needs to prove a negative with offline signing keys, DNSSEC does this by basically making a linked list of each zone and signing the links.
- tptacek 4mo ago
  It's doing that because the protocol was designed for offline signers, which in turn was a result of a folk belief in the 1990s that computers wouldn't be fast enough to do online signing.
  - pocksuppet 4mo ago
    Was it really nothing to do with keeping keys safer offline?
    - tptacek 4mo ago
      Go read the mailing lists of the time.
- phicoh 4mo ago
  A linked list of each authoritative name in the zone. Not a list of zones. That's for offline signing. For online signing you can do different things. But the point is, and that's what this discussion is about is that DNSSEC can evolve. It can get extra features to make online signing more efficient. The problem is that getting all validating recursive resolvers and other validators to update takes a very long time, on the order of decades. So we got this problem because people started using this feature without verifying that validator support had spread wide enough.
  - tptacek 4mo ago
    At this point, with this microscopic level of adoption and this track record of instability, and given that we're now 4 major revisions (all premised on the same original service model that TIS came up with in the mid-1990s), it would make a lot more sense to go back to the drawing board. That's basically what we did with DoH, a protocol that has drastically more deployment than DNSSEC and a more coherent threat model. The simplest and most obvious thing you could do, if you were being parsimonious about it, would be to switch to an online-signer model. With modern (circa 2005) cryptography, you'd do a straightforward client/server authenticated denial without any of the record-chaining silliness. A big chunk of the complexity of the protocol would just vanish.

formerly_proven 4mo ago

Most of the time people are not asking for domains which don't resolve. Also, think about what DNSSEC is actually having to do when signing an NXDOMAIN. It needs to prove a negative with offline signing keys, DNSSEC does this by basically making a linked list of each zone and signing the links.

tptacek 4mo ago
It's doing that because the protocol was designed for offline signers, which in turn was a result of a folk belief in the 1990s that computers wouldn't be fast enough to do online signing.
- pocksuppet 4mo ago
  Was it really nothing to do with keeping keys safer offline?
  - tptacek 4mo ago
    Go read the mailing lists of the time.
phicoh 4mo ago
A linked list of each authoritative name in the zone. Not a list of zones. That's for offline signing. For online signing you can do different things. But the point is, and that's what this discussion is about is that DNSSEC can evolve. It can get extra features to make online signing more efficient. The problem is that getting all validating recursive resolvers and other validators to update takes a very long time, on the order of decades. So we got this problem because people started using this feature without verifying that validator support had spread wide enough.
- tptacek 4mo ago
  At this point, with this microscopic level of adoption and this track record of instability, and given that we're now 4 major revisions (all premised on the same original service model that TIS came up with in the mid-1990s), it would make a lot more sense to go back to the drawing board. That's basically what we did with DoH, a protocol that has drastically more deployment than DNSSEC and a more coherent threat model. The simplest and most obvious thing you could do, if you were being parsimonious about it, would be to switch to an online-signer model. With modern (circa 2005) cryptography, you'd do a straightforward client/server authenticated denial without any of the record-chaining silliness. A big chunk of the complexity of the protocol would just vanish.