bind: how to accept authoritative answers only?

Jim Reid jim at rfc1035.com
Sat Jan 27 20:03:14 UTC 2001


>>>>> "Andre" == Andre Dietisheim <dietisheim at gmx.net> writes:

    Andre> I tried to figure out how to configure bind (on my TSL1.2)
    Andre> to accept authoritative answers only, but I didn't succeed.

Hardly suprising as BIND provides no way of doing this. Given the huge
number of lame delegations and messed-up name servers in the world,
deliberately configuring a server to only accept authoritative answers
would cause operational problems. Lookups returning valid data could
be ignored just because 1 bit wasn't set in the header, so working web
sites appear non-existent, mail that could have been sent goes
undelivered, etc, etc. This is not wise. What if you're trying to mail
the hostmaster to tell them they have a lame delegation or broken name
server?

Not that the setting of the aa bit means much as far as spoofing
attacks are concerned anyway. It's trivial to fake an answer with
incorrect data and set the aa bit to indicate that the reply is
authoritative. That simply means the setting of the aa bit has no
significance if a server or answer is spoofed. Even a genuine answer
that sets the aa bit has no great meaning. All it means is the server
was authoritative for the zone containing the name was looked
up. That's easy to fake too. My server could be authoritive for the
.net zone (say) simply by adding a suitable zone{} statement to
named.conf and reloading. [Or the equivalent set up for other DNS
implementations.] I can even make my server load my version of .net
containing whatever I want. Of course this is no problem unless
somehow I can convince other servers to query my server instead of the
real servers for .net.

    Andre> This should help against IP-Spoofing as named would't
    Andre> accept answers of a hijacked cache that is used to spoof
    Andre> addresses. DJBDNS (Bernstein stuff) behaves that way, and I
    Andre> would have liked to configure bind to work that way.

Er no. Once a reply leaves any name server, anyone intercepting that
packet can change its contents on its way back to whoever asked the
query. The packets can still be spoofed and their source addresses
faked. djbdns is just as vulnerable to this as any other name
server. This attack can be detected if Secure DNS (DNSSEC) is used and
each packet contains a digital signature. But djbdns does not support
DNSSEC.


More information about the bind-users mailing list