2

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 :P ).

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.

Improve this question
9
  • 2
    I'm probably wrong but it seems you are setting this up as an authoritative server and I think that they never recurse, that's the task of the client's resolver. Use a dedicated resolver for your tests: Client->resolver (caching only named)->dns.lan.group4.org. The resolver should in the second iteration ask iodine. The glue record you supplied seems fine (proper delegation).
    – AndreasM
    Feb 10, 2012 at 13:12
  • I thought about doing that, then discarded it since I thought it can't really matter whether there's a relay DNS-server involved or whether I directly ask the authoritative server that then delegates to iodine. Will try that though, anything to get this moving, thanks :) Btw, what do you mean by "task of the client's resolver"? Currently, the iodine-client asks my local DNS, who then is supposed to forward those requests to the iodine-server.
    – G. Bach
    Feb 10, 2012 at 13:58
  • The delegation works in a hierarchy and the resolver (caching-only nameserver) goes down the . -> org -> group04 -> lan -> tunnel list to find the record. None of the authoritative servers will (normally) forward the request but simply send the answer back. So in your case, the "iodine-client asks your local DNS" as you put it and the gets the answer "tunnel NS tunnel" plus the glue record "iodine A 10.10.1.5", then it asks iodine for a name in tunnel.
    – AndreasM
    Feb 10, 2012 at 14:11
  • The problem is, the DNS for lan.group04.org never sends back the information "tunnel NS is @ 10.10.1.5" - somehow it doesn't resolve that request. When I go "dig ns tunnel.lan.group04.org" on the LAN DNS server which should know the answer from its own records, I get NXDOMAIN for an answer.
    – G. Bach
    Feb 10, 2012 at 14:16
  • Ah i think I understand what you mean, you mean the DNS resolution works iteratively instead of recursively, did I understand that correctly? In that case, I have allowed recursive DNS resolution on my local DNS, so that should not be the problem (I think?).
    – G. Bach
    Feb 10, 2012 at 14:18

2 Answers 2

Reset to default
2

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

Improve this answer
2
  • It's fine for "just internal" domains, but it can't be used from outside. For that you need proper delegation: Org registrar -> group04 authorative dns servers -> lan dns server (maybe the same) -> tunnel dns server (iodine)
    – AndreasM
    Feb 10, 2012 at 15:33
  • It's only a local setup, so I'm happy with the partial solution for now :)
    – G. Bach
    Feb 10, 2012 at 15:42
0

Ok problem solved; I had not set up 10.10.1.5 as a forwarder for my local DNS server; in the named.conf.options of my local DNS, it needed to be:

forwarders {
    ...
    10.10.1.5;
    ...
}

That (and of course the subsequent bind restart) solved my problem.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .