Mailinglist Archive: opensuse-security (757 mails)

< Previous Next >
RE: [suse-security] Is bind 9.1.0 secure?
  • From: "Reckhard, Tobias" <tobias.reckhard@xxxxxxxxxxx>
  • Date: Mon, 21 Jan 2002 13:11:07 +0100
  • Message-id: <96C102324EF9D411A49500306E06C8D1A56CD6@xxxxxxxxxxxxxxxxx>
Re Steffen

> > > We had a discussion about djbdns on a local maillinglist in
> > > Berlin. It's not offering all features that bind offers.
> >
> > While this may well be true, many people probably don't need certain
> > features at all. And there are workarounds or patches for
> quite a few of the
> > 'problems' that a certain number of people have with the
> pure djbdns.
> I know from qmail, that most of the patches are "inofficial" and
> not security-checked sometimes, so a patched djbdns may not
> secure at all, who knows.

True, this could very well be. Which is why I'd try to come by without
patching djbdns if I can. However, the djbdns is very compact, as are the
patches, so auditing either or both is much more acceptable than is the case
for BIND (shudder..).

> > Perhaps you could point out which specific features you miss?
> Well, I have some hundert zones on currently a few primary and a
> few secondaries, but not any zone is on any secondary.
> Secondaries keep track what to transfer when, and this is
> controlled by serial number which is not bad. I don't now how
> much work it is to set up a secondary for djbdns, i.e. adding new
> zones. With bind, it's only a thing of adding them to
> configuration, they get the new zone automatically. Well, and the
> logging is nice, I see it when something fails, without watching
> if zone files are up to date or not, it's in the logs when a zone
> transfer failed. This are details but for me they are important.

DJB suggests to modify the Makefile used to create the database to rsync&ssh
automatically and provides instructions on the Makefile entries to make.
There was a discussion on the (DJB)DNS mailing list recently on how to keep
separate zones in separate data files - you can do that with scripts or by
modifying the Makefile.

Actually, with djbdns most things are *different* from BIND, they're not
necessarily more work. In fact, djbdns makes a lot of things easier, such as
resource record generation, and less error-prone, e.g. by automatic
generation of reverse records and automatic handling of serial numbers (if
you let it).

> > Zone transfers are supported in the current version (djbdns
> 1.05), but you
> > need the separate ucspi-tcp package to provide TCP client
> and server.
> I think that ucspi-tcp is a nice package, but I think it's a
> little more efford setting it up than having "native" TCP
> support. On the other hand, you have a stable, tested TCP
> implementation.

It follows the UNIX concept of having lots of small, dedicated and
specialised utility programs instead of monster applications.

> > DJB argues against zone transfers and urges people to use rsync
> > (preferrably over SSH) instead, for several reasons outlined on
> > his web page.
> I read it a long time ago IIRC. Rsync+ssh is more secure and so
> on, but it's more efford to set up and to watch if it fails I
> think.

I guess that depends on your abilities to postprocess it. You have more
options to intervene into the process.

> > transfers just fine. tinydns does not pull zones per zone
> > transfer automatically, so you need to use cron jobs to pull
> > from the clients on a regular basis to emulate AXFR behaviour.
> Well, with bind I don't need to do anything, it works out of the
> box. This is comfortable and cheap.

True. I wouldn't mind djbdns to support AXFR myself, but it probably won't,
since Dan doesn't like it.

> > IMHO, that depends on what you favour: a relatively bloated piece of
> > software with a pretty poor security track that most
> organisations and
> > documents expect,
> This is really a pitty, and I don't like to quality of bind,
> really. But on the other hand, I don't have time to do so much
> details by hand for so much servers and zones.

Actually, after initial setup, the amount of work involved in managing DNS
zones with djbdns can very well be less than with BIND.

> > than the former and may require some scripting around them
> to achieve the
> > same features, however usually implemented with higher quality.
> I feel that scripting solutions often seem not as stable as "real
> servers", often it's not trivial to do the right error checking
> and so on. On rsync cron jobs, I had to take care that error
> messages get into syslog, and if I forget somethink, I may not
> notice some errors and such.

Well, the coders of the 'real servers' needed to get their error-checking
stuff right, too, which is just as non-trivial. And I don't know how much
faith I'd put into the quality of the BIND code in particular with regards
to this respect...

Yes, you need to know your tools. But IMHO, that's a prerequisite anyhow and
goes without saying. I wager that only a small fraction of the people
employing BIND know how to configure it properly, lest the zone data...

> > configured to support FreeS/WAN's opportunistic encryption by
> > handing out KEY records, and the FreeS/WAN docs speak of
> > SecDNS...
> KEY records without SecDNS (signed records and zones) makes not
> much sense. I think djbdns can work with KEY records but they are
> unsigned, so you cannot use them, since you cannot trust them.

As I said below, I don't know enough about SecDNS to be able to say a lot
here. It's on my list of interests, though. :)

> Ohh, and one thing I forgot: does djbdns support dynamic zone
> update? Well, usually I don't like it, and I have the dynamic
> names in own zones, but I won't live without it. Well, it's not
> really secure (and I use it with a bad script via SSH :(), but
> needed for dynamic IP accounts.

Yuck! I honestly do not know, but don't think so. It doesn't support NOTIFY,
so it probably won't support client-triggered zone updates.

I currently see no use in dynamic DNS, I think it's A Bad Thing (TM). It was
the first option I disabled on the ISC DHCP server I use. BTW, does anyone
know a DHCP server from someone else, with the focus on security, perhaps?


< Previous Next >
Follow Ups