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