RE: [suse-security] Is bind 9.1.0 secure?
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? Cheers Tobias
On Mon, Jan 21, 2002 at 13:11 +0100, Reckhard, Tobias wrote:
BTW, does anyone know a DHCP server from someone else, with the focus on security, perhaps?
In the FreeBSD ports tree there is (next to versions 2 and 3 of the ISC daemon) the WIDE implementation ("This release includes DHCP server, relay agent, and client." plus "You can get the latest version from; ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/"). Although I've never used it in production, just set it up once to have it run when I diagnosed (sort of, tried to ...) why the clients didn't like the ISC server. So I can confirm it runs, but I cannot judge its long time behaviour. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (2)
-
Gerhard Sittig
-
Reckhard, Tobias