3 ms·

I run the signing systems for a bunch of TLDs and honestly it scares me. .NZ was just the latest public failure. If multiple large registry operators employing

by elp 3y ago

I run the signing systems for a bunch of TLDs and honestly it scares me. .NZ was just the latest public failure. If multiple large registry operators employing people who wrote the DNS and DNSSEC rfcs have had failures then how can you expect regular mortals to get it right? Transferring your domain and your old ISP had dnssec on but the new one knows nothing about it and didn't check ... Down you go. Mess up the key signing key change over procedure while transferring to a competent DNSSEC provider ... down you go again (although hopefully for a shorter time). We do best practice DNSSEC, using fancy HSMs to do so, but if my fancy, proprietary, badly documented Thales HSM dies and the next person with my job has trouble getting the new box configured... no changes to the zones until its fixed. Take long enough that the RRSIGs expire ... down YOU go again. If at that point they throw out the HSM and roll regular DNSSEC using Knot or something it will probably be at least 24 hours for the zone to work properly even with IANAs emergency procedures. I'm paranoid so we have 3 identical HSMs and detailed restore procedures but there is zero guarantee that if I ever leave my replacement will get it right. You can't hire dnssec staff, they are impossible to find, you have to train on the job. The basic idea is excellent but the implementation in the real world is horrible. If dnssec usage was wide spread we might reach some decent maturity with the tools and protocols, but I can't see that happening any time soon.

donttellmypeers 3y ago
> If dnssec usage was wide spread we might reach some decent maturity with the tools and protocols, but I can't see that happening any time soon. DNSSEC's lack of maturity is a symptom of DNS itself not having a healthy ecosystem. I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole.
- silisili 3y ago
  Totally. DNS was always an IETF RFC bound thing. Recently, big players just kinda started making their own decisions. I'm not sure which is better. Having big companies control the internet is definitely bad, but the pedantry and bikeshedding the IETF offers can be equally bad. I'd probably rather see the two cooperate/converge, but that's a pipe dream.
  - teddyh 3y ago
    This sounds exactly like the age-old debates bemoaning the bureaucracy of government versus the exploitation of industry. People knowing the pain of one always look hopefully at the other.
- abwizz 3y ago
  > I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole. you mean like the ppl that made it more centralized and failure prone?
  - donttellmypeers 3y ago
    Is that a dig at the DoH crowd? My comment wasn't suggesting a HTTP background is necessary for someone to help move the DNS ecosystem forward.
    - abwizz 3y ago
      it was indeed
belorn 3y ago
One major problem with new security technology is that testing is generally created as the result of failure, rather than preceding the failure so that it doesn't occur in the first place. Even very basic things like verifying that a new key actually fit the intended lock (ie, that a new key correspond to the published data) is a concept that people tend to implement only once they have had experienced a failure. One general solution is to have standardized tools with standardized testing. Transferring a domain should always involve testing the old data, testing the old keys, testing the new data, testing the new keys, testing the chain of delegation, testing the chain of trust and so on. Some TLD's has gone as far as doing basic sanity test before a domain owner is allowed to transfer a domain. (industry term is to delegate a domain, since transfer is strictly about legal ownership) Thankfully there are initiatives to create standard tools and standard test. Zonemaster (https://zonemaster.net https://zonemaster.net) is one I recommend for testing, which is the result of a collaboration between .se and .fr. There is also initiatives for tooling that create multi-signing (https://github.com/DNSSEC-Provisioning/music https://github.com/DNSSEC-Provisioning/music), which is to have multiple keys operating for the same domain. Redundancy in HSM's are nice, but redundancy is not a replacement for testing and backup procedures. It was one of the hard lessons learned by the IT industry, especially with data. No amount of RAID will save a company if a rogue script deletes all the files, or if the database becomes corrupt. A lot of experts learned the hard way that redundancy is mostly just a complement to sanity tests and backup procedures.
- tptacek 3y ago
  This isn't new security technology. The service model for DNSSEC was designed in 1994.
tptacek 3y ago
The basic idea isn't excellent. It's wrong. It's firmly rooted in mid-1990s cryptography (the original design was a DOD contract to TIS); in particular, to the idea that cryptography is too expensive to do on edge systems. That's why DNSSEC's core design has offline signers (my belief is that the supposed security benefits of offline signing are back-rationalized --- remember that a best-practices "leaf" DNSSEC deployment today will have online signers, to foil enumeration attacks). If you were to scrap DNSSEC-ter and start from scratch in 2023, there is no chance the design would look anything like DNSSEC. It would be fully encrypted for privacy. It would strike a different balance between authenticated denial and offline keys. It would use different primitives, and it would probably have a different DNS RR schema. There are lots of implementation problems with DNSSEC, but the real issue is that the design is the best we could do in 1998, and that most of what's "improved" since then have been more effective ways to shoehorn the same model into the evolving core DNS infrastructure, rather than really improving the fundamental design.

by elp 3y ago

donttellmypeers 3y ago

> If dnssec usage was wide spread we might reach some decent maturity with the tools and protocols, but I can't see that happening any time soon. DNSSEC's lack of maturity is a symptom of DNS itself not having a healthy ecosystem. I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole.

silisili 3y ago
Totally. DNS was always an IETF RFC bound thing. Recently, big players just kinda started making their own decisions. I'm not sure which is better. Having big companies control the internet is definitely bad, but the pedantry and bikeshedding the IETF offers can be equally bad. I'd probably rather see the two cooperate/converge, but that's a pipe dream.
- teddyh 3y ago
  This sounds exactly like the age-old debates bemoaning the bureaucracy of government versus the exploitation of industry. People knowing the pain of one always look hopefully at the other.
abwizz 3y ago
> I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole. you mean like the ppl that made it more centralized and failure prone?
- donttellmypeers 3y ago
  Is that a dig at the DoH crowd? My comment wasn't suggesting a HTTP background is necessary for someone to help move the DNS ecosystem forward.
  - abwizz 3y ago
    it was indeed

belorn 3y ago

One major problem with new security technology is that testing is generally created as the result of failure, rather than preceding the failure so that it doesn't occur in the first place. Even very basic things like verifying that a new key actually fit the intended lock (ie, that a new key correspond to the published data) is a concept that people tend to implement only once they have had experienced a failure. One general solution is to have standardized tools with standardized testing. Transferring a domain should always involve testing the old data, testing the old keys, testing the new data, testing the new keys, testing the chain of delegation, testing the chain of trust and so on. Some TLD's has gone as far as doing basic sanity test before a domain owner is allowed to transfer a domain. (industry term is to delegate a domain, since transfer is strictly about legal ownership) Thankfully there are initiatives to create standard tools and standard test. Zonemaster (https://zonemaster.net https://zonemaster.net) is one I recommend for testing, which is the result of a collaboration between .se and .fr. There is also initiatives for tooling that create multi-signing (https://github.com/DNSSEC-Provisioning/music https://github.com/DNSSEC-Provisioning/music), which is to have multiple keys operating for the same domain. Redundancy in HSM's are nice, but redundancy is not a replacement for testing and backup procedures. It was one of the hard lessons learned by the IT industry, especially with data. No amount of RAID will save a company if a rogue script deletes all the files, or if the database becomes corrupt. A lot of experts learned the hard way that redundancy is mostly just a complement to sanity tests and backup procedures.

tptacek 3y ago
This isn't new security technology. The service model for DNSSEC was designed in 1994.

tptacek 3y ago

The basic idea isn't excellent. It's wrong. It's firmly rooted in mid-1990s cryptography (the original design was a DOD contract to TIS); in particular, to the idea that cryptography is too expensive to do on edge systems. That's why DNSSEC's core design has offline signers (my belief is that the supposed security benefits of offline signing are back-rationalized --- remember that a best-practices "leaf" DNSSEC deployment today will have online signers, to foil enumeration attacks). If you were to scrap DNSSEC-ter and start from scratch in 2023, there is no chance the design would look anything like DNSSEC. It would be fully encrypted for privacy. It would strike a different balance between authenticated denial and offline keys. It would use different primitives, and it would probably have a different DNS RR schema. There are lots of implementation problems with DNSSEC, but the real issue is that the design is the best we could do in 1998, and that most of what's "improved" since then have been more effective ways to shoehorn the same model into the evolving core DNS infrastructure, rather than really improving the fundamental design.