FreeBSD 7.1 and BIND exploit

Wed Jul 23 02:30:50 UTC 2008

Jeremy, I can't agree with you more, for some reason
crypto people seem to believe that in order to drive
a car you should have to know how to rebuild a carb.

Makes no sense.

The funny part is that your comparison with setting up
IPsec is the same thing that I compare these things to.

Back in 2003 I tried to set up a "shared key" IPSEC dhcp
at home, basically I'd just make a key and sneaker-net it
to the hosts that wanted to connect, after about 6 hours
I just gave up and used "wep".

*sigh*

-Alfred

* Jeremy Chadwick <koitsu at FreeBSD.org> [080722 18:59] wrote:
> On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote:
> > --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton 
> > <dougb at FreeBSD.org> wrote:
> >
> >> Matthew Seaman wrote:
> >>
> >>> Are there any plans to enable DNSSEC capability in the resolver built
> >>> into FreeBSD?
> >>
> >> The server is already capable of it. I'm seriously considering enabling the
> >> define to make the CLI tools (dig/host/nslookup) capable as well (there is
> >> already an OPTION for this in ports).
> >>
> >> The problem is that _using_ DNSSEC requires configuration changes in
> >> named.conf, and more importantly, configuration of "trust anchors" (even for
> >> the command line stuff) since the root is not signed. It's not hard to do
> >> that with the DLV system that ISC has in place, and I would be willing to
> >> create a conf file that shows how to do that for users to include if they
> >> choose to. I am not comfortable enabling it by default (not yet anyway), it's
> >> too big of a POLA issue.
> >>
> >
> > I just played around with it recently.  It's not that easy to understand  
> > initially *and* the trust anchors thing is a royal PITA.
> 
> I completely agree on both points.  To give you some idea of how much of
> an annoyance DNSSEC is, a friend of mine who used to work at Nominum
> stated that one of their software engineers, when signing, on had a
> clause appended to his employee agreement stating he would not be
> required to work on DNSSEC code, due to the absurd complexity of it all.
> 
> For what it's worth, I went looking into DNSSEC last week, and after a
> few hours of skimming then reading, I concluded it's over-engineered and
> adds too much hassle for it to be considered a worthwhile "upgrade".  In
> no way am I putting down the need for security, but the added complexity
> is what's going to turn people off to this, and because of such, very
> likely ignore it.  You can call me ignorant/lazy -- I welcome such --
> but I guarantee others feel the same way.
> 
> DNS, for most people, is expected to be a "simple thing".  They like it
> to be simple, and it's generally not rocket science.  People have come
> to expect that, and while I think most are willing to accept change
> (take TSIG for example), it has to be easy to set up, simple to
> maintain, troubleshooting outlined step-by-step with easy-to-follow
> output, and in the case of a hard failure, the documentation easy to
> understand.
> 
> This is not the case with DNSSEC; I feel like I'm setting up a bloody
> IPsec VPN.  IPsec: AH or ESP across tunnel/transport using AES or 3DES
> with IKE/ISAKMP or static secrets, and don't forget GRE.  DNSSEC: trust
> anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its
> phases, KSK and its phases, etc...
> 
> There's the "how to make it work in 6 minutes" PDF by the ISC, which
> appears to have been made/used for/as presentation material -- meaning
> you're missing the verbal explanations that go along with each item.
> There's also inconsistencies in configuration syntax within the PDF,
> making you wonder how much time someone put into it.
> 
> There also appears to be an assumption made throughout all of the
> documentation that I've read: that your recursive and non-recursive DNS
> servers are separate.  I'm still trying to understand why that
> assumption is made; sure, the majority of the "enterprise-class" world
> has segregated DNS servers (public authoritative vs. internal recursive
> resolvers), but the runner-up would be administrators who simply run
> BIND on their servers and use two simple configuration lines:
> 
>   acl "trusted" { my.net.block/cidr; 127.0.0.1; };
>   options { 
>     allow-recursion { trusted; }
>   };
> 
> If DNSSEC really requires that your recursive and non-recursive servers
> be separate, then it will fail.
> 
> And I still cannot get over the fact that this "HOWTO" is 47 pages long:
> http://www.nlnetlabs.nl/dnssec_howto/
> 
> Let's not forget this packet flow diagram, which is quite legible and
> easy to understand:
> http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png
> 
> > Once you implement DNSSEC you *must* generate keys every 30 days.  So, I 
> > think, if you're going to enable it by default, there needs to be a 
> > script in periodic that will do all the magic to change keys every 30 
> > days.  Maybe put vars in /etc/rc.conf to override the default key lengths 
> > and other portions of the commands that could change per installation.
> 
> I believe you're talking about re-signing the zones.  The duration is
> adjustable, but 30 days appears to be what the documentation and howto
> site defaults to/recommends using:
> 
> http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html
> http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4
> 
> > But until root is signed, it's not worth it for those of us who don't 
> > have dedicated staff doing dns only.
> 
> Bingo.
> 
> -- 
> | Jeremy Chadwick                                jdc at parodius.com |
> | Parodius Networking                       http://www.parodius.com/ |
> | UNIX Systems Administrator                  Mountain View, CA, USA |
> | Making life hard for others since 1977.              PGP: 4BD6C0CB |
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"

-- 
- Alfred Perlstein