4 ms·

the only thing better than one way to authenticate DNS queries is N ways to authenticate DNS queries! "standards are great everyone should have some" snark asi

by munin 15y ago

the only thing better than one way to authenticate DNS queries is N ways to authenticate DNS queries! "standards are great everyone should have some" snark aside, I guess it's nice to see someone really stepping forward and giving a crap about cryptographic authentication of DNS? the DNSSEC people don't seem to care that much and are perfectly willing to move at glacial speeds on implementation ...

tptacek 15y ago
That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that: * failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence) * required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted * requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis * is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic. * Will require upgrades to every "sockets"-style program ever written to properly function. If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.

by munin 15y ago

tptacek 15y ago

That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that: * failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence) * required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted * requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis * is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic. * Will require upgrades to every "sockets"-style program ever written to properly function. If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.