[PLUG] Re: [PLUG-WEB] [PLUG Website 0000018]: DNS configuration is not up to par

Ed Sawicki ed at alcpress.com
Fri Jan 10 21:10:02 UTC 2003


On Fri, 2003-01-10 at 18:27, Carla Schroder wrote:
> So what's this mean in the real world? My cranky DNS guru, who uses djbdns, 
> likes to rant about what a horrid hack TSIG is, and he doesn't think much of 
> DNSSEC either. Are they necessary for DNS to work, or are they lame BIND 
> hacks, as the aforementioned cranky guru says?

Hi Carla,

Is the cranky DNS guru me or someone else you know?
I do get cranky at times - and when I do I write a
book. :-) Here's one:

No, TSIG and DNSSEC are not necessary for DNS to work.
Tens of thousands of DNS servers in the world are
running without them. But are they BIND hacks? Well,
that's a great question. The answer is a difficult
one because the DNS world is quite political and
controversial.

TSIG, DNSSEC. NOTIFY, IXFR, and other DNS-related
features are IETF efforts. Many of the people on the
IETF committees have relationships with the people
and companies that have an interest in BIND doing well. 
Some think that the committees make decisions that
ensure the popularity of BIND at the expense of better
software.

Critics of BIND, including the creator of djbdns, Dan
Bernstein - the king of cranky DNS gurus - are critical
of BIND's design. There are numerous reasons why djbdns
enthusiasts think that there's the BIND way and the
right way.

Lets take zone transfers as an example, since I recall
this being the root of the issue with PLUG's decision
to abandon it's non-BIND 9 secondary. A secondary DNS
server needs to stay synchronized with its master so it
gives out the same information (records) as the master.
It does this by asking the primary (master) for a new
copy of the zone file. The master sends the zone file
and the two are synchronized.

Zone files are plain text files, so it doesn't take
much sophistication to move them between computers.
There's no shortage of file transfer protocols. Yet,
BIND uses a file transfer protocol that is unique to
it - and unique to DNS since it was specified in an
IETF RFC. The protocol uses a silly serial number
mechanism to ensure that file transfers only occur
when the master's zone file has changed. Whoever
designed this should be bitch-slapped. Even
experienced DNS administrators update their zone files
but forget to advance the serial number and wonder why
the secondaries are giving out outdated/wrong information.

Normally, secondaries ask the masters if zone files
have changed at fixed intervals, say once an hour.
If the administrator changes a zone file, it could take
up to 59 minutes and 59 seconds for the secondary to
synchronize to the master's zone. During that time, the
secondary will be giving out old/wrong information. So,
the BIND folks created yet another mechanism specific
to BIND and DNS called NOTIFY. When the administrator
reloads a zone on the master, a message is sent to the
secondary telling it "Something has happened here. Try
to guess what it was." The secondary then contacts the
master and discovers it must do a zone transfer.

If zone files are large, such as on the root or gtld
servers, you don't want to move entire files when only
a tiny percentage of the zone file has changed. So the
BIND folks developed yet another BIND-specific protocol
called IXFR, which only moves the changes.

Since BIND has been successfully attacked for years,
the BIND folks need some way to reduce the perception
that BIND (and DNS) is insecure. So, they create yet more
BIND-specific mechanisms to try to improve security. TSIG
and DNSSEC are two of them.

The djbdns folks think it's silly to use these BIND-specific
mechanisms when we already have excellent general purpose
protocols and software to do these things. If you want to
move zone files between computers and they might be large,
you can use rsync, which only moves changes. If you're
concerned that these file transfers should be secure, run
rsync on top of SSL. If you want to be sure you're sending
a zone file to a legitimate secondary and you're not being
spoofed, configure your firewall and, optionally, use
certificates.

BIND zone transfers are backward. They're secondary pull
instead of master push. NOTIFY is a band aid to fix this
ass-backward behavior. With djbdns, administrators are
told to simply push the updated zone file to the secondary
using whatever protocols/software does the job:

rsync
rsync over SSL
scp
cp over a VPN
whatever...

Using these simpler protocols, BIND's silly serial numbers
go away. For a good laugh, read the details of BIND serial
number arithmetic and how you can convince a BIND secondary
to start using a new serial number.

Eliminate BIND and you don't have to worry about drilling a
TCP/53 hole in your firewall to allow zone transfers. Things
get simpler without the BIND nonsense. There are other issues,
such as cache poisoning, that are greatly reduced with common
sense design and implementation.

We don't need no steenking TSIG.

-- 
Ed Sawicki <ed at alcpress.com>
ALC





More information about the PLUG mailing list