Bind9 not forwarding to subdomain NS

bindsubdomainzones

I'm running bind9 on Ubuntu 10.04, managing the (LAN)domain lan.group04.org – see the following zone file

lan.group04.org.    IN  SOA dns.lan.group04.org. admin.lan.group04.org. (
2006081401
28800
3600
604800
38400
)
lan.group04.org.    IN  NS  dns.lan.group04.org.
gateway     IN  A   10.10.1.1
wlan-access IN  A   10.10.1.2
dns         IN  A   10.10.1.3
payment     IN  A   10.10.1.4
iodine      IN  A   10.10.1.5
tunnel      IN  NS  iodine.lan.group04.org.

As you may have guessed from those cleverly chosen names, I'm trying out iodine (this is coursework, not trying to hack the Gibson here 😛 ).

My trouble now is that my DNS-server never sends out DNS-requests to 10.10.1.5. For iodine to work, I need the DNS to to forward any request for anything in tunnel.lan.group04.org to that IP; for example, a request for hello.tunnel.lan.group04.org should be forwarded to the iodine-machine.

I have tried multiple variations of the above that I could come up with that seem to be semantically identical and syntactically valid, but could not get the subdomain requests forwarded to the iodine-machine. I know they aren't forwarded there from wiresharking on both machines.

About the network: it's all in 10.10.1.0/17, no routers/firewalls/switches between 10.10.1.4 (the local DNS) and 10.10.1.5 (iodine), ports are open, ping, http,…. works. iodine.lan.group04.org resolves correctly.

Do I need to setup the iodine server as the master for that subdomain in the named.conf.local? I already tried that once but may have messed it up, so I'm going to try that again right after posting this question.

Anyone any ideas what I'm doing wrong here?

EDIT solved; see my own answer. Accepted answer was for giving AndreasM credit for helping me solve this.

Best Answer

Responding in an answer for the upvote ;) . I don't know off hand how bind9 does it, normally it should first check it's views (in configured order) to decide if it should act as a resolver or authorative. I agree with you that it should have acted in resolver mode in your case (assuming that other queries (like www.google.com) worked) and then answered from auth mode, but apparently it didn't. That's why I always use a dedicated resolver when I test this stuff.

Your solution is only a partial one, you never test if this works also from the outside. It's a "short-cut" for your tests saying "also ask this one if you don't get an answer".

Related Topic