Local DNS not working.

hepburnenthorpe · 03-12-2008, 09:33 PM

I have three physical machines (running debian) on the same network/domain.

Code:

192.168.10.1 firewall.tsp
192.168.10.2 oblivion.tsp
192.168.10.6 toshi.tsp

Within oblivion.tsp I am trying to setup a vps (using openVZ) as a caching nameserver and local DNS for my network following this article as a guide.

Code:

192.168.10.100 dns.tsp

All machines can ping each other via ip no problems.

dns.tsp has my isp's nameserver listed within its /etc/resolv.conf file while oblivion.tsp has the nameserver listed as 192.168.10.100

I am able to ping domains outside of my network (ie google) without any issue from oblivion.tsp.

However, trying to ping dns.tsp, firewall.tsp or any other machine on my network (by name) fails (unknown host).

Here are the files that make up my bind configuration on dns.tsp (they vary slightly from the guide because that is how debian etch has them setup by default).

named.conf

Code:

include "/etc/bind/named.conf.options";

// reduce log verbosity on issues outside our control
logging {
	category lame-servers { null; };
	category cname { null; };
};

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
	// added by thorpe
	allow-update {
		none;
	};
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

// add local zone definitions here
include "/etc/bind/named.conf.local";

named.conf.options

Code:

options {
        directory "/var/cache/bind";
	fetch-glue no;
	listen-on {
		127.0.0.1;
		192.168.10.0/24;
	};
};

I'll leave out db.root as it is maintained by InterNIC and is (as far as I'm aware) fine.

db.local

Code:

$TTL	604800
@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	localhost.
@	IN	A	127.0.0.1

db.127

Code:

$TTL	604800
@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	localhost.
1.0.0	IN	PTR	localhost.

named.conf.local

Code:

zone "tsp" IN {
	type master;
	file "db.tsp";
};
zone "10.168.192.in-addr.arpa" {
	type master;
	file "db.192.168.10";
};

db.tsp

Code:

$ORIGIN tsp.
$TTL 1D
@	IN SOA	dns	hostmaster (
			200803132	; serial
			8H		; refresh
			4H		; retry
			4W		; expire
			1D		; minimum
			)
		NS	dns
localhost	A	127.0.0.1
dns		A	192.168.10.100
firewall        A       192.168.10.1
oblivion	A	192.168.10.2
toshi		A	192.168.10.6

db.192.168.10

Code:

$ORIGIN 10.168.192.in-addr.arpa.
$TTL 1D
@	IN SOA	dns.tsp. hostmaster.tsp. (
		; YYYYMMDDI
		200803132	; serial
		28800		; refresh
		14400		; retry
		2419200		; expire
		86400		; minimum
		)
		NS	dns.tsp.
1               PTR     firewall.tsp.
2		PTR	oblivion.tsp.
6		PTR	toshi.tsp.
100		PTR	dns.tsp.

Ive looked around in /var/log but don't seem to be able to find any log file. If anyone can see any discrepancies or has any ideas it would be much appreciated. Thankyou.

leebrent · 03-12-2008, 10:55 PM

First question, is inbound UDP Port 53 open, and do you have any IPtables rules on the box in place?

dkm999 · 03-12-2008, 11:02 PM

I must confess that I did not read the entire article you referred to as your guide; perhaps there is something there that led you into extra complexity.

As far as I can see, your machine oblivion has the address 192.168.10.2. If it is to function as a local cacheing nameserver, then the other machines on your local net need the following resolv.conf content

Code:

nameserver 192.168.10.2

This will inform these machines that they need to consult oblivion for resolution of names that they cannot resolve themselves.

The rest of your config files look like they should be correct. You can always check whether that is true with the program nslookup on oblivion. That program will let you see the results of various DNS queries, aimed at particular DNS servers. I recommend starting it up, issuing the command

Code:

>nameserver 192.168.10.2

and seeing what the named daemon can resolve. It should be able to resolve not only the names in your local net, but also names like www.google.com.

Good luck

hepburnenthorpe · 03-13-2008, 11:26 AM

Ok, thanks for the replies. Firstly, no there are no iptables rules enabled on any of these machines.

quote]As far as I can see, your machine oblivion has the address 192.168.10.2. If it is to function as a local cacheing nameserver, then the other machines on your local net need the following resolv.conf content[/quote]

Its not oblivion (the hardware node) I want configured as the dns but dns.tsp (192.168.10.100) which is a VE within oblivion.

Ive logged in and issued an nslookup, here is the result.

Code:

root@dns / # nslookup 192.168.10.100
Server:         203.0.178.191
Address:        203.0.178.191#53

** server can't find 100.10.168.192.in-addr.arpa: NXDOMAIN

Any ideas?

dkm999 · 03-14-2008, 12:32 AM

Well, the nslookup output is pretty explicit: it says that the server you are talking to has no idea about the address 192.168.10.100. That is not very surprising, since the server you are talking to (203.0.178.191) is not your cacheing nameserver (that would be 127.0.0.1), but some server out on the Internet. Public Internet routers are all set up to prohibit access to 192.168.x.y addresses, since those are a reserved block used exclusively for Private Networking; your network address translation, wherever it occurs, allows you to use these addresses locally. But no public DNS server is going to admit to knowing anything about such an address.

So the first problem is that oblivion (or the virtual whatever within it) needs to have its resolv.conf altered, so that it uses 127.0.0.1 as the nameserver. Then the experiment that you reported will give us some information that we can actually use to see if it is doing what your config files indicate.

Then, as I recommended in my last post, if you log onto a different machine and want to see what that machine's view of the resolution is, you start nslookup on that machine, and explicitly tell it to use 192.168.10.100 for consultation, by first giving the nameserver command to nslookup. Then that machine will subsequently report on what it hears from your daemon, rather than from wherever it normally gets its DNS replies. You can ask for either forward or reverse resolution, depending on whether you next input a text string or an IP address. I recommend the fine manpage for further reading.

By taking this stepwise approach, you can establish how much of the resolution is working the way it should, and then as a last step change the clients so that they use the (newly debugged) nameserver in their resolvers.

konsolebox · 03-14-2008, 01:24 AM

First make sure that you are really using your local dns as your default dns and not other foreign dns like your ISP dns then make sure you have configured your domain properly.

btw can you try to remove this from your db.tsp?

Code:

localhost	A	127.0.0.1

restart your dns server then do
# dig dns.tsp.
# dig firewall.tsp. @dns.tsp.

show us the output if you like

hepburnenthorpe · 03-14-2008, 07:23 PM

Thankyou, it all appears solved. All I did was change my dns servers /etc/resolv.conf file to point to 127.0.0.1 and now it is working.

Thankyou all.

hepburnenthorpe · 03-14-2008, 07:44 PM

Sorry, just realised its not working. I still had firewall.tsp listed in oblivions /etc/hosts file, got a little excited.

Ok, so what I have done. I have removed my isp's nameserver from dns.tsp's /etc/resolv.conf file, replacing it with 127.0.0.1. I have also removed this....

Code:

localhost	A	127.0.0.1

line form db.tsp and restarted the server. Here are the outputs of the dig commands, firstlt ran from oblivion.tsp then again from dns.tsp.

Code:

thorpe@oblivion ~ # sudo dig dns.tsp.

; <<>> DiG 9.3.4 <<>> dns.tsp.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11087
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dns.tsp.			IN	A

;; AUTHORITY SECTION:
.			3460	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2008031400 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 192.168.10.100#53(192.168.10.100)
;; WHEN: Sat Mar 15 11:38:48 2008
;; MSG SIZE  rcvd: 100

thorpe@oblivion ~ # sudo dig firewall.tsp. @dns.tsp.
dig: couldn't get address for 'dns.tsp.': not found
thorpe@oblivion ~ #

Code:

root@dns / # dig dns.tsp.

; <<>> DiG 9.3.4 <<>> dns.tsp.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23413
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dns.tsp.			IN	A

;; AUTHORITY SECTION:
.			3182	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2008031400 1800 900 604800 86400

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Mar 15 11:43:26 2008
;; MSG SIZE  rcvd: 100

root@dns / # dig firewall.tsp. @dns.tsp.
dig: couldn't get address for 'dns.tsp.': not found
root@dns / #

Thanks for the help.

dkm999 · 03-14-2008, 08:19 PM

It appears from the DiG reports that there is some strangeness associated with your virtual whatever (which I still have not fathomed any reason for). When you actually got a response (for the name dns.tsp), you got it from a server responding to the address 192.168.10.100 (presumably DiG figured out to ask this address from your /etc/resolv.conf setup, maybe with some help from /etc/hosts). But when you asked it to speak explicitly to the server dns.tsp and ask for resolution of another name, that failed because DiG could not resolve the server name according to what was in /etc/resolv.conf.

So I stand corrected: you should not be using 127.0.0.1 as the nameserver address, but should rather be using 192.168.10.100. See if that does not solve your problem. And then I would recommend reviewing the reasons that led you to set up a virtual environment around a nameserver in the first place. It appears that this is causing you headaches, and I see no particular benefit. A nameserver is pretty much confined in what it can do by its configuration file; if you want extra protection against breakins, the chroot scheme has been proved to work pretty well without any change to how the rest of the operating system deals with the nameserver.

Oh well, free advice is worth every penny you pay for it.

konsolebox · 03-14-2008, 11:32 PM

Code:

;; SERVER: 192.168.10.100#53(192.168.10.100)
;; SERVER: 127.0.0.1#53(127.0.0.1)

seems to me that you're able to connect to your local dns but the local dns doesn't seem to have a data about your *.tsp. Probably it's a misconfiguration in your named.conf or your dns zonefiles that your local dns bypassed your files. this also happened to me before.

Code:

file "db.tsp";
file "db.192.168.10"

shouldn't these two in your named.local be something like

Code:

file "/etc/bind/db.tsp";
file "/etc/bind/db.192.168.10";

scowles · 03-15-2008, 07:02 AM

I created the two zone files "db.tsp" and "db.192.168.10" using copy/paste to a FC6 based test server running bind. I also appended the correspnding zone entries from the OP named.conf to the test servers named.conf file. After starting named, all queries for tsp and 192.168.10.x SOA, PTR, NS and A records worked fine. So the zone files and zone entries in named.conf are correct.

Based on the results above, I would check the following:

1) On server 192.168.10.100, /etc/resolv.conf should point to 127.0.0.1

2) On all other hosts, /etc/resolv.conf should point to 192.168.10.100

3) I have never used debian, so I do not know how they configure named to start (chroot'd or not). But I would check file permissions on the zone files db.tsp and db.192.168.10. On my test system, these files must be owned by named.named (owner.group). Otherwise they will not load.

4) Make sure the zone files are in the proper location. Based on the posted options file and the way you have the file name listed in the zone definition for tsp and 192.168.10 (relative to directory specifed in options section), it looks like they need to be in "/var/cache/bind"

5) Check /var/log/messages (or whatever file it is on debian) for named entries on startup

hepburnenthorpe · 03-16-2008, 07:40 AM

Quote:

Originally Posted by konsolebox

shouldn't these two in your named.local be something like

Code:

file "/etc/bind/db.tsp";
file "/etc/bind/db.192.168.10";

Its always the simple things. That fixed it thankyou. All is definately working now.

Thanks everyone for you help.