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 this
than 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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to