4 ms·

I'm not actually an expert on this, so I can't say for sure. I know of only 2 compatibility issues, by order of decreasing importance (IMHO): 1) Some DNS serve

I'm not actually an expert on this, so I can't say for sure. I know of only 2 compatibility issues, by order of decreasing importance (IMHO): 1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?) Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of. 2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync. As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem. Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.

akerl_ 4y ago
Maybe it’s not compatibility issue, and DNSSEC doesn’t provide meaningful security improvements, so deploying it increases the risk of breakage without any tangible benefit to the threat model.
tptacek 4y ago
This is such a weird analysis. Again: less than 4% of .com is signed. It's not just a question of people updating their server software; it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done. Further: when Apple and Microsoft operating systems rely on the `AD` bit for DNSSEC verification, they are using the protocol as it was designed. That's what the bit is there for. The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers. You can see that this fully-recursive verification thing isn't what the DNSSEC designers want just from the fact that they themselves attempted to solve this problem, over a decade ago, with TSIG (iirc; it might have been a different weirdo DNS subprotocol). There was an actual stub-to-server DNS protocol. Nobody uses it because nobody in the real world cares about DNSSEC. What you're really saying is that Linux nerds can just run their own DNS servers. They can! But we don't design global Internet security to serve people who want to sysadmin their own phones. It has to work for normal people.
- wizeman 4y ago
  > it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done. You mentioned yourself that DNSSEC can be activated automatically by registries, like what has been done in Europe, so I don't really see that as being an issue. Sure, you can fuck up if you start messing around with DS records and whatnot, like Slack did (and BTW, they're still using DNSSEC even after experiencing that outage), but once you start messing around with DNS you can also fuck up in many other ways that have nothing to do with DNSSEC. So that is not really a problem with DNSSEC itself. > The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers. Sure, but we're not in 1995 anymore, so there's no issue with running a resolver with DNSSEC validation at the client level anymore. > What you're really saying is that Linux nerds can just run their own DNS servers. No, I'm saying OS manufacturers like Google, Apple and Microsoft can implement DNSSEC validation on the DNS resolvers of their OSes, just like Google implemented DNS-over-HTTPS transport (which also wasn't an option in 1995). > But we don't design global Internet security to serve people who want to sysadmin their own phones. Fortunately, that's not what I'm proposing. > It has to work for normal people. Agreed :)
  - tptacek 4y ago
    Registrars auto-sign the zones that randos create in Europe. They don't fuck with the important zones. That's part of what makes registrar auto-signing so silly.

akerl_ 4y ago

Maybe it’s not compatibility issue, and DNSSEC doesn’t provide meaningful security improvements, so deploying it increases the risk of breakage without any tangible benefit to the threat model.

tptacek 4y ago

This is such a weird analysis. Again: less than 4% of .com is signed. It's not just a question of people updating their server software; it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done. Further: when Apple and Microsoft operating systems rely on the `AD` bit for DNSSEC verification, they are using the protocol as it was designed. That's what the bit is there for. The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers. You can see that this fully-recursive verification thing isn't what the DNSSEC designers want just from the fact that they themselves attempted to solve this problem, over a decade ago, with TSIG (iirc; it might have been a different weirdo DNS subprotocol). There was an actual stub-to-server DNS protocol. Nobody uses it because nobody in the real world cares about DNSSEC. What you're really saying is that Linux nerds can just run their own DNS servers. They can! But we don't design global Internet security to serve people who want to sysadmin their own phones. It has to work for normal people.

wizeman 4y ago
> it's getting a critical mass of the Internet to reconfigure their DNS, in an environment where the last several years shows well-funded shops blowing themselves up just trying to get this done. You mentioned yourself that DNSSEC can be activated automatically by registries, like what has been done in Europe, so I don't really see that as being an issue. Sure, you can fuck up if you start messing around with DS records and whatnot, like Slack did (and BTW, they're still using DNSSEC even after experiencing that outage), but once you start messing around with DNS you can also fuck up in many other ways that have nothing to do with DNSSEC. So that is not really a problem with DNSSEC itself. > The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers. Sure, but we're not in 1995 anymore, so there's no issue with running a resolver with DNSSEC validation at the client level anymore. > What you're really saying is that Linux nerds can just run their own DNS servers. No, I'm saying OS manufacturers like Google, Apple and Microsoft can implement DNSSEC validation on the DNS resolvers of their OSes, just like Google implemented DNS-over-HTTPS transport (which also wasn't an option in 1995). > But we don't design global Internet security to serve people who want to sysadmin their own phones. Fortunately, that's not what I'm proposing. > It has to work for normal people. Agreed :)
- tptacek 4y ago
  Registrars auto-sign the zones that randos create in Europe. They don't fuck with the important zones. That's part of what makes registrar auto-signing so silly.