Date: Tue, 22 Jul 2008 18:58:55 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Paul Schmehl <pschmehl_lists_nada@tx.rr.com> Cc: freebsd-stable@freebsd.org, Doug Barton <dougb@FreeBSD.org> Subject: Re: FreeBSD 7.1 and BIND exploit Message-ID: <20080723015855.GA36829@eos.sc1.parodius.com> In-Reply-To: <34182EE347F910EA2A64DF03@utd65257.utdallas.edu> References: <200807212219.QAA01486@lariat.net> <200807221552.m6MFqgpm009488@lurza.secnetix.de> <20080722162024.GA1279@lava.net> <48860CBA.6010903@FreeBSD.org> <488615F5.80405@infracaninophile.co.uk> <4886188E.6090805@FreeBSD.org> <34182EE347F910EA2A64DF03@utd65257.utdallas.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080723015855.GA36829>