Doug Barton wrote:
Clifton Royston wrote:I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix.Dan didn't write postfix, he wrote qmail.If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC
Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD?
(which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5).
That big announcement Dan Kaminsky was going to make at the Blackhat Conference in August? Unfortunately the cat has already been let out of the bag: http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html There's no implementation of DNS that can be any /more/ proof against thisthan BIND+latest patches because the problem is intrinsic to the design of the DNS protocol. You'ld better be patched up or using alternative DNS implementations equally secure already. Even so that just increases the search space from about 16bits to about 30bits, which should make it not really feasible given current network and server capabilities.
Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature