| Well said. Being one of those "DNS people" (having given a few talks etc on the subject), I also have been telling people that I cannot privately deploy DNSSEC, simply because the failure model is too high. Currently with BIND and Knot one can setup automatic signing of zones, which makes things a bit easier, but it relies on setting up a master-slave relationship. My current deployment of auth dns servers is simply a bunch of master nsd's, that get rsynced with their configs and reloaded (after a config test :). If one of them breaks, the others keep on running happily. In the case of master-slave though, if the master (the sole thing with the current keys), breaks (box dead, IP down, routing issue), the slaves after a while also do not know what to do anymore.... Thus, after all your hard work you go on vacation for a bit.... you come back and everything is gone, as your domain does not properly resolve anymore, no valid keys are there, not properly signed, not properly rotated... The failure model is too big; even if you run a 24/7 NOC, they will only notice problems when they hit you; and they will have to monitor DNSSEC verification specifically to notice them, and not get notified through twitter about it. From a client perspective the failure model is a whole lot worse: when DNSSEC verification fails the answer is a flat-out denial of service. At least with TLS when a cert is invalid the client gets a chance to peek at it and go 'meh, looks okay to me' (even though that is a 'badidea' for chrome users ;) ) The problem with DNSSEC though is that with how the DNSSEC system works, with delegation in mind, it is hard to come up with something 'better' than NSEC3, this as you want to be able to avoid people from listing your whole DNS zone, but you also want to be able to delegate subdomains to other folks. And that is also what makes the root special: the keys have to be deployed in the resolvers world-wide and everybody needs them before they can use them. (Similar to TLS root certs); but the same goes for crypto-options: everything needs it before they can upgrade; for the Web, that is 'solved' by having aggressive browser-updates, though as can be seen from ssllabs those are not the only clients, and people primarily update their Chrome and Firefox, thus there is a long-tail there too, hence why people do not normally configure the Mozilla Modern TLS configuration as they break those other, not updated, clients. For resolvers this is worse getting new crypto in there, let alone keys: they are embedded typically in the OS (OSX mDNSResponder (which has bunches of problems over the years), Windows has it's own, on Linux it depends on the day which one you get); but worse: large swaths of people rarely run upgrades on those systems... Plus to add more pain to this: there are these people running Docker and other container images that never ever get updates. Oh, and then there is this magic called Android, congrats on 15% deployment for a 1 year old OS.... To finalize, my rant: unless somebody figures out an easy way to 'upgrade the world' in a relatively short time frame (~2 to 3 months), we'll always be stuck with older software/configs(keys,etc) And older software means: broken implementations that do not rotate keys properly, that do not have the latest keys, that do not have the latest TLS certs, that do not have security properties fixed. And thus also, that even if somebody replaced/fixed DNSSEC: there will always be clients that will not work along... |