Hey guys, hoping one of you gurus can help me clear up my understanding of how DNS is working on my home lan.
I have bind9 running on a debian etch system to provide internal DNS to our home LAN, for various reasons (caching nameserver on our side of the firewall, more consistent name resolution, wanted to do it... yada yada). After getting it set up I am getting mostly correct results, but want to understand one anomaly. First, here is named.conf from the etch system (I have hand-included named.conf.options and named.conf.local to make it easy to read):
root@mambazo:/etc/bind# more named.conf
acl xxxx-lan { 192.168.0.0/24; 127.0/8; };
options {
directory "/var/named";
allow-query { xxxx-lan; };
// forward to opendns
forwarders {
208.67.222.222;
208.67.220.220;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
zone "localhost" {
type master;
file "db.local";
};
zone "127.in-addr.arpa" {
type master;
file "db.127";
};
zone "xxxx.home" {
type master;
file "db.xxxx.home";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "db.0.168.192";
};
Now here is the forward zone file from /var/named. I've removed all but one host and the name server which I will use for the example below:
$TTL 86400
xxxx.home. IN SOA mambazo.xxxx.home. markxxxx.yyyy.net. (
2004011522 ; Serial no., based on date
21600 ; Refresh after 6 hours
3600 ; Retry after 1 hour
604800 ; Expire after 7 days
3600 ; Minimum TTL of 1 hour
)
@ IN NS mambazo.xxxx.home.
mambazo.xxxx.home. IN A 192.168.0.105
mariner.xxxx.home. IN A 192.168.0.100
Finally, this is the /etc/resolv.conf from mambazo:
domain xxxx.home
search xxxx.home
nameserver 127.0.0.1
On the windows clients I set mambazo (.105) as the primary DNS, and the gateway router (.1) as the secondary DNS, and they are set to append the xxxx.home suffix. Both the router and mambazo are set up to forward to opendns, though in normal operation the router will no longer recieve dns queries from inside the lan, since everyone will point to mambazo. Anyway...
Here is the anomaly. When I execute nslookup on mambazo, I get the following result:
root@mambazo:/etc# nslookup mariner
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: mariner.xxxx.home
Address: 192.168.0.100
All appears well. But if I execute dig, I get the following result:
root@mambazo:/etc# dig mariner
; <<>> DiG 9.3.4 <<>> mariner
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43759
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
;; QUESTION SECTION:
;mariner. IN A
;; ANSWER SECTION:
mariner. 0 IN A 208.67.217.130
;; AUTHORITY SECTION:
. 513294 IN NS H.ROOT-SERVERS.NET.
. 513294 IN NS I.ROOT-SERVERS.NET.
. 513294 IN NS J.ROOT-SERVERS.NET.
. 513294 IN NS K.ROOT-SERVERS.NET.
. 513294 IN NS L.ROOT-SERVERS.NET.
. 513294 IN NS M.ROOT-SERVERS.NET.
. 513294 IN NS A.ROOT-SERVERS.NET.
. 513294 IN NS B.ROOT-SERVERS.NET.
. 513294 IN NS C.ROOT-SERVERS.NET.
. 513294 IN NS D.ROOT-SERVERS.NET.
. 513294 IN NS E.ROOT-SERVERS.NET.
. 513294 IN NS F.ROOT-SERVERS.NET.
. 513294 IN NS G.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
L.ROOT-SERVERS.NET. 171123 IN A 199.7.83.42
;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 9 14:37:41 2008
;; MSG SIZE rcvd: 268
Obviously not correct. It's going to the root servers for some reason. However if I fully qualify mariner then I get what I would expect:
root@mambazo:/etc# dig mariner.xxxx.home
; <<>> DiG 9.3.4 <<>> mariner.xxxx.home
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3205
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;mariner.xxxx.home. IN A
;; ANSWER SECTION:
mariner.xxxx.home. 86400 IN A 192.168.0.100
;; AUTHORITY SECTION:
xxxx.home. 86400 IN NS mambazo.xxxx.home.
;; ADDITIONAL SECTION:
mambazo.xxxx.home. 86400 IN A 192.168.0.105
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 9 14:38:33 2008
;; MSG SIZE rcvd: 89
Thing is, I swear that last night dig was working correctly without a fully qualified name for the internal host. Last night we had several power outages due to wind, and when I got up this morning all our machines were down. When I brought mariner up initially I checked DNS and saw that several of the machines on the internal lan were resolving to the bogus 208.xxx addresses. I flushed the dns cache, and tried a few more times, and it started working, i.e from mariner "ping someinternalsys" would result in packets from the correct 192.xxx address.
That's all still working, and who knows maybe bind was still initializing or something (I brought mambazo up at the same time but it boots much faster than mariner, an XP system). That's when I popped over to mambazo and noticed the behavior above. I should also point out that from mambazo either "ping mariner" or "ping mariner.xxxx.home" work correctly.
Sorry for the wall of text, but if anyone can further educate me on the subtleties here I would very much appreciate it.
I have bind9 running on a debian etch system to provide internal DNS to our home LAN, for various reasons (caching nameserver on our side of the firewall, more consistent name resolution, wanted to do it... yada yada). After getting it set up I am getting mostly correct results, but want to understand one anomaly. First, here is named.conf from the etch system (I have hand-included named.conf.options and named.conf.local to make it easy to read):
root@mambazo:/etc/bind# more named.conf
acl xxxx-lan { 192.168.0.0/24; 127.0/8; };
options {
directory "/var/named";
allow-query { xxxx-lan; };
// forward to opendns
forwarders {
208.67.222.222;
208.67.220.220;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
zone "localhost" {
type master;
file "db.local";
};
zone "127.in-addr.arpa" {
type master;
file "db.127";
};
zone "xxxx.home" {
type master;
file "db.xxxx.home";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "db.0.168.192";
};
Now here is the forward zone file from /var/named. I've removed all but one host and the name server which I will use for the example below:
$TTL 86400
xxxx.home. IN SOA mambazo.xxxx.home. markxxxx.yyyy.net. (
2004011522 ; Serial no., based on date
21600 ; Refresh after 6 hours
3600 ; Retry after 1 hour
604800 ; Expire after 7 days
3600 ; Minimum TTL of 1 hour
)
@ IN NS mambazo.xxxx.home.
mambazo.xxxx.home. IN A 192.168.0.105
mariner.xxxx.home. IN A 192.168.0.100
Finally, this is the /etc/resolv.conf from mambazo:
domain xxxx.home
search xxxx.home
nameserver 127.0.0.1
On the windows clients I set mambazo (.105) as the primary DNS, and the gateway router (.1) as the secondary DNS, and they are set to append the xxxx.home suffix. Both the router and mambazo are set up to forward to opendns, though in normal operation the router will no longer recieve dns queries from inside the lan, since everyone will point to mambazo. Anyway...
Here is the anomaly. When I execute nslookup on mambazo, I get the following result:
root@mambazo:/etc# nslookup mariner
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: mariner.xxxx.home
Address: 192.168.0.100
All appears well. But if I execute dig, I get the following result:
root@mambazo:/etc# dig mariner
; <<>> DiG 9.3.4 <<>> mariner
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43759
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
;; QUESTION SECTION:
;mariner. IN A
;; ANSWER SECTION:
mariner. 0 IN A 208.67.217.130
;; AUTHORITY SECTION:
. 513294 IN NS H.ROOT-SERVERS.NET.
. 513294 IN NS I.ROOT-SERVERS.NET.
. 513294 IN NS J.ROOT-SERVERS.NET.
. 513294 IN NS K.ROOT-SERVERS.NET.
. 513294 IN NS L.ROOT-SERVERS.NET.
. 513294 IN NS M.ROOT-SERVERS.NET.
. 513294 IN NS A.ROOT-SERVERS.NET.
. 513294 IN NS B.ROOT-SERVERS.NET.
. 513294 IN NS C.ROOT-SERVERS.NET.
. 513294 IN NS D.ROOT-SERVERS.NET.
. 513294 IN NS E.ROOT-SERVERS.NET.
. 513294 IN NS F.ROOT-SERVERS.NET.
. 513294 IN NS G.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
L.ROOT-SERVERS.NET. 171123 IN A 199.7.83.42
;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 9 14:37:41 2008
;; MSG SIZE rcvd: 268
Obviously not correct. It's going to the root servers for some reason. However if I fully qualify mariner then I get what I would expect:
root@mambazo:/etc# dig mariner.xxxx.home
; <<>> DiG 9.3.4 <<>> mariner.xxxx.home
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3205
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;mariner.xxxx.home. IN A
;; ANSWER SECTION:
mariner.xxxx.home. 86400 IN A 192.168.0.100
;; AUTHORITY SECTION:
xxxx.home. 86400 IN NS mambazo.xxxx.home.
;; ADDITIONAL SECTION:
mambazo.xxxx.home. 86400 IN A 192.168.0.105
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 9 14:38:33 2008
;; MSG SIZE rcvd: 89
Thing is, I swear that last night dig was working correctly without a fully qualified name for the internal host. Last night we had several power outages due to wind, and when I got up this morning all our machines were down. When I brought mariner up initially I checked DNS and saw that several of the machines on the internal lan were resolving to the bogus 208.xxx addresses. I flushed the dns cache, and tried a few more times, and it started working, i.e from mariner "ping someinternalsys" would result in packets from the correct 192.xxx address.
That's all still working, and who knows maybe bind was still initializing or something (I brought mambazo up at the same time but it boots much faster than mariner, an XP system). That's when I popped over to mambazo and noticed the behavior above. I should also point out that from mambazo either "ping mariner" or "ping mariner.xxxx.home" work correctly.
Sorry for the wall of text, but if anyone can further educate me on the subtleties here I would very much appreciate it.
Facebook
Twitter