Jan Lentfer’s committed support for DNSSEC. It’s supported by default, meaning you can use it right now on a 2.5.1+ system. He’s tested it locally using these instructions, which I link to for everyone’s edification. Is this important? A lot of people seem to think so.
2 Replies to “DNSSEC now supported”
Comments are closed.
A security extension that is full of security advisories? :-)
http://security.FreeBSD.org/advisories/FreeBSD-SA-10:01.bind.asc
http://www.google.com/search?q=dnssec+site:cr.yp.to
http://cr.yp.to/talks.html#2009.08.10
http://cr.yp.to/talks/2009.08.10/slides.pdf
Yeah, it’s the same with all old protocols using old standards/RFCs and old software.
See email for example. It was not intended to have crypto support, SPF, domainkeys. There was no intention to make it secure from wrong sender-addresses, spam, etc.
They patch it with tons of additional stuff (domainkeys, SPF, greylisting, blacklisting, whitelisting). They use hacks instead of a new protocols with native support for this kind of stuff. And all this stuff causes problems if you use stuff like mailing list software or you do use a wrong email address, because you somehow need or want to.
This is not very easy for DNS, because replacing it with something different would change the whole internet and applications wouldn’t work without changes.
I guess it is a lot easier with email, because there is a smaller dependency. But what is even better about it, is that I think it would be easier to create something with backward compatibility for everything that relies on emails.
DNSSEC is not so easy to set up, but I guess it will be easier when it gets widely adopted and the right tools get created. Of course it is a hack with its own problems. Maybe someone finds a better solution. Oh and it is by _far_ not the only security extension that is full of security advisories.
It is one of the problems when comparing incremental changes/patches vs. new solutions. Both come with positive and negative effects.