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.

G. Bach
  • 278
  • 3
  • 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 '12 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 '12 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 '12 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 '12 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 '12 at 14:18
  • That's difficult to say without the configuration. bind9 tries to separate the resolver from the zone auth serving functionality, but in your case it can't decide whether the question should be handled in resolver mode or auth mode. That's why I said use an additional resolver to avoid that problem. Does your client get the proper answer or do you get an error message? – AndreasM Feb 10 '12 at 14:23
  • Ah I see what you mean. The client also gets back the NXDOMAIN response. Apart from setting up another DNS server, do you know a way to tell the DNS when to use resolver mode and when to use auth mode? Btw, please respond in an answer, you need to get at least my upvote for your help :) – G. Bach Feb 10 '12 at 14:28
  • I am oh so stupid - I didn't list 10.10.1.5 in the forwarders in named.conf.options - that solved this problem. Still, please write an answer so I can give you upvotes, because your suggestions really were what helped me find this solution. Thanks! – G. Bach Feb 10 '12 at 14:36
  • Please post your solution as an answer and not as an edit to your question – user9517 Feb 10 '12 at 14:42

2 Answers2

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

AndreasM
  • 1,083
  • 8
  • 13
  • 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 '12 at 15:33
  • It's only a local setup, so I'm happy with the partial solution for now :) – G. Bach Feb 10 '12 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.

G. Bach
  • 278
  • 3
  • 9