[Techtalk] Re: Server was hacked into; all DNS servers reek!

[Carla Schroder]

On Monday 24 February 2003 11:06 am, Raven Alder wrote:
> Heya --
>
> Quoth Carla Schroder (Mon, Feb 24, 2003 at 10:18:30AM -0800):

>
> 	Also, djb assumes scripting and sysadmin competency as a
> prerequisite to running his software, as opposed to showing you how.
> For example, this weekend I was making my nameserver (running djbdns) a
> secondary for a friend's new domain.  I used tcpclient to invoke
> axfr-get to pull down the zone file.  I had to write a script to
> regularly get the zone file, and compile the little database -- there's
> nothing in djb's docs that tells you how to do that.  And in my opinion,
> getting the secondary to regularly poll the primary nameserver and
> update its config is the sort of thing that should at least be covered
> in the documentation, if sample scripts are not provided for you.

Well now you hit on an interesting subject: mixing djbdns and BIND for 
primaries and secondaries. That is the most difficult job, because BIND uses 
weirdo proprietary methods, and djb has no patience with what he considers 
nonsense. Just running a DNS server is easy with djbdns. I shall quote my 
fave dns guru on this subject:

"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 <deleted> 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."

I'm not into going to war over this, them's my thoughts. ;-)
Hopefully some will find this informative and entertaining!

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~
Carla Schroder
www.tuxcomputing.com
this message brought to you
by Libranet 2.7 and Kmail
~~~~~~~~~~~~~~~~~~~~~~~~~