BIND 9.3.1 Forwarder Behavior

Tim Wilde twilde at dyndns.com
Sun Dec 11 05:00:07 UTC 2005


I've just discovered a very strange (to me) behavior with a forwarder 
zone on BIND 9.3.1.  I have a view set up on this forwarder as follows:

view "rbldns" {
         match-destinations { 63.208.196.10; };
         match-clients { our_servers; };
         recursion yes;

         zone "spamikaze.dnsbl.mailhop.org" IN {
                 type forward;
                 forward first;
                 forwarders { 127.0.0.1 port 5335; };
         };
};

I'm forwarding queries from BIND to a local rbldnsd server, which is 
serving up a local blacklist (don't try to query that from outside, it's 
not in production or allowed through our firewalls at this point, nor 
would you match the ACL if it were).  When I query the server 
recursively, it works fine:

$ dig 2.0.0.127.spamikaze.dnsbl.mailhop.org. @63.208.196.10

; <<>> DiG 9.3.1 <<>> 2.0.0.127.spamikaze.dnsbl.mailhop.org. @63.208.196.10
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7180
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.spamikaze.dnsbl.mailhop.org. IN A

;; ANSWER SECTION:
2.0.0.127.spamikaze.dnsbl.mailhop.org. 600 IN A 127.0.0.2

;; AUTHORITY SECTION:
spamikaze.dnsbl.mailhop.org. 43200 IN   NS      rbldns.mailhop.org.

;; Query time: 3 msec
;; SERVER: 63.208.196.10#53(63.208.196.10)
;; WHEN: Sat Dec 10 23:53:12 2005
;; MSG SIZE  rcvd: 92

But if I flush out the cache and do a non-recursive query, I get a 
referral to the roots:

$ dig 2.0.0.127.spamikaze.dnsbl.mailhop.org. @63.208.196.10 +norec

; <<>> DiG 9.3.1 <<>> 2.0.0.127.spamikaze.dnsbl.mailhop.org. 
@63.208.196.10 +norec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55772
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;2.0.0.127.spamikaze.dnsbl.mailhop.org. IN A

;; AUTHORITY SECTION:
.                       518400  IN      NS      A.ROOT-SERVERS.NET.
.                       518400  IN      NS      B.ROOT-SERVERS.NET.
.                       518400  IN      NS      C.ROOT-SERVERS.NET.
.                       518400  IN      NS      D.ROOT-SERVERS.NET.
.                       518400  IN      NS      E.ROOT-SERVERS.NET.
.                       518400  IN      NS      F.ROOT-SERVERS.NET.
.                       518400  IN      NS      G.ROOT-SERVERS.NET.
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
.                       518400  IN      NS      L.ROOT-SERVERS.NET.
.                       518400  IN      NS      M.ROOT-SERVERS.NET.

;; Query time: 3 msec
;; SERVER: 63.208.196.10#53(63.208.196.10)
;; WHEN: Sat Dec 10 23:56:18 2005
;; MSG SIZE  rcvd: 266

This is not what I expected, and in fact it took me a ton of debugging 
to figure out that this was happening, because I was originally querying 
a local recursive server for the zone, and getting SERVFAIL, because it 
was sending a query without the "rd" flag when acting on my behalf.

It seems logical to me that a forward zone would always forward, whether 
or not recursion was requested.  Otherwise, what's the point of a 
forward zone?  And how does this work for other people?  You certainly 
can't rely on recursive servers to set "rd" when doing the work on a 
client's behalf, because BIND 9.3.1 doesn't.

I assume it DOES work for some people, because this is exactly a 
recommended configuration as published in a number of places, such as:

http://www.surbl.org/rbldnsd-bind-freebsd.html

Any thoughts?  Is this something that maybe changed in 9.3 (or some 
other more recent BIND 9 revision)?  Is this intended?  Should it be?

Thanks!

Tim Wilde

-- 
Tim Wilde
twilde at dyndns.com
Systems Administrator
Dynamic Network Services, Inc.
http://www.dyndns.com/



More information about the bind-users mailing list