The following has been tested on an OpenBSD snapshot
Code:
dmesg | head -4
OpenBSD 4.6-current (GENERIC) #446: Thu Dec 3 01:27:24 MST 2009
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
The version of BIND
Code:
# named -v
BIND 9.4.2-P2
Personally I prefer DJBDNS, but because of some recent posts about name servers I decided to polish up my rusty BIND skills/memories
The configuration file "/var/named/etc/named.conf" :
Code:
options {
interface-interval 0 ;
listen-on {
192.168.222.245 ;
};
recursion no ;
allow-transfer {
none;
};
};
zone "localhost" {
type master;
file "standard/localhost";
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
zone "de.filo" in {
type master ;
file "master/de.filo" ;
};
zone "222.168.192.in-addr.arpa" in {
type master ;
file "master/222.168.192.in-addr.arpa" ;
};
The zone files for 'localhost' and '127.in-addr.arpa' are standard zones
already supplied in the directory '/var/named/master'.
The 'de.filo' zone file:
Code:
; Zone file for de.filo
$TTL 86400
@ IN SOA ns1.de.filo. j65.de.filo. (
2009120802 ; serial, todays date+todays
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
86400 ) ; minimum, seconds
IN NS ns1.de.filo.
IN NS ns2.de.filo.
IN MX 0 mail.de.filo.
localhost IN A 127.0.0.1
ns1 IN A 192.168.222.245
ns2 IN A 192.168.222.200
mail IN A 192.168.222.20
www IN A 192.168.222.20
ftp IN A 192.168.222.20
kant IN A 192.168.222.1
hegel IN A 192.168.222.2
nietzsche IN A 192.168.222.3
husserl IN A 192.168.222.4
heidegger IN A 192.168.222.5
marcuse IN A 192.168.222.6
adorno IN A 192.168.222.7
scheler IN A 192.168.222.8
jaspers IN A 192.168.222.9
The reverse zone file '222.168.192.in-addr.arpa' :
Code:
; Zone "222.168.192.in-addr.arpa"
$TTL 86400
@ IN SOA ns1.de.filo. hostmaster.de.filo. (
2009120801 ; serial, todays date+todays
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
86400 ) ; minimum, seconds
IN NS ns1.de.filo.
1 IN PTR kant.de.filo.
2 IN PTR hegel.de.filo.
3 IN PTR nietzsche.de.filo.
4 IN PTR husserl.de.filo.
5 IN PTR heidegger.de.filo.
6 IN PTR marcuse.de.filo.
7 IN PTR adorno.de.filo.
8 IN PTR scheler.de.filo.
9 IN PTR jaspers.de.filo.
20 IN PTR mail.de.filo.
200 IN PTR ns2.de.filo.
245 IN PTR ns1.de.filo.
For debugging I started named from the commandline as root with the '-g' option.
Code:
-g Run the server in the foreground and force all log-
ging to stderr.
Of course I made some mistakes in the configuration files:
Code:
Starting privilege separation
07-Dec-2009 06:18:23.281 starting BIND 9.4.2-P2 -g
07-Dec-2009 06:18:23.310 loading configuration from '/etc/named.conf'
07-Dec-2009 06:18:23.335 /etc/named.conf:7: option 'fetch-glue' is obsolete
07-Dec-2009 06:18:23.336 listening on IPv6 interfaces, port 53
Binding privsep
[priv]: msg PRIV_BIND received
Binding privsep
[priv]: msg PRIV_BIND received
07-Dec-2009 06:18:23.417 listening on IPv4 interface fxp0, 192.168.222.245#53
Binding privsep
[priv]: msg PRIV_BIND received
Binding privsep
[priv]: msg PRIV_BIND received
07-Dec-2009 06:18:23.440 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:18:23.441 couldn't add command channel 127.0.0.1#953: file not found
07-Dec-2009 06:18:23.441 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:18:23.441 couldn't add command channel ::1#953: file not found
07-Dec-2009 06:18:23.442 using pre-chroot entropy source /dev/arandom
07-Dec-2009 06:18:23.442 ignoring config file logging statement due to -g option
07-Dec-2009 06:18:23.443 zone 222.168.192.in-addr.arpa/IN: loading from master file 222.168.192.in-addr.arpa failed: file not found
07-Dec-2009 06:18:23.443 zone de.filo/IN: loading from master file de.filo failed: file not found
07-Dec-2009 06:18:23.444 running
After some editing in another SSH xterm, I gave a '-HUP' signal to tell named to reload the configuration file:
The result:
Code:
07-Dec-2009 06:26:34.260 loading configuration from '/etc/named.conf'
07-Dec-2009 06:26:34.260 /etc/named.conf:7: option 'fetch-glue' is obsolete
07-Dec-2009 06:26:34.270 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:26:34.271 couldn't add command channel 127.0.0.1#953: file not found
07-Dec-2009 06:26:34.271 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:26:34.271 couldn't add command channel ::1#953: file not found
07-Dec-2009 06:26:34.271 ignoring config file logging statement due to -g option
07-Dec-2009 06:26:34.271 zone 222.168.192.in-addr.arpa/IN: (master) removed
07-Dec-2009 06:26:34.271 zone de.filo/IN: (master) removed
07-Dec-2009 06:26:34.285 zone 222.168.192.in-addr.arpa/IN: loaded serial 2009120801
07-Dec-2009 06:26:34.287 zone de.filo/IN: NS 'ns1.de.filo' has no address records (A or AAAA)
07-Dec-2009 06:26:34.288 zone de.filo/IN: NS 'ns2.de.filo' has no address records (A or AAAA)
07-Dec-2009 06:26:34.288 zone de.filo/IN: loaded serial 2009120801
07-Dec-2009 06:26:34.291 zone de.filo/IN: sending notifies (serial 2009120801)
As you can see it is quite helpful to see these messages.
After fixing these omissions and '-HUPping' named:
Code:
07-Dec-2009 06:49:43.138 loading configuration from '/etc/named.conf'
07-Dec-2009 06:49:43.147 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:49:43.148 couldn't add command channel 127.0.0.1#953: file not found
07-Dec-2009 06:49:43.148 none:0: open: /etc/rndc.key: file not found
07-Dec-2009 06:49:43.148 couldn't add command channel ::1#953: file not found
07-Dec-2009 06:49:43.148 ignoring config file logging statement due to -g option
07-Dec-2009 06:49:43.151 zone de.filo/IN: sending notifies (serial 2009120802)
By running
netstat you can see what ports and/or protocols the nameserver is using:
Code:
# netstat -an -f inet
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 48 192.168.222.245.22 192.168.222.20.22030 ESTABLISHED
tcp 0 0 192.168.222.245.53 *.* LISTEN
tcp 0 0 192.168.222.245.22 192.168.222.20.30780 ESTABLISHED
tcp 0 0 127.0.0.1.587 *.* LISTEN
tcp 0 0 127.0.0.1.25 *.* LISTEN
tcp 0 0 *.37 *.* LISTEN
tcp 0 0 *.13 *.* LISTEN
tcp 0 0 *.113 *.* LISTEN
tcp 0 0 *.22 *.* LISTEN
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
udp 0 0 *.46423 *.*
udp 0 0 192.168.222.245.53 *.*
udp 0 0 127.0.0.1.512 *.*
udp 0 0 *.514 *.*
Standard DNS traffic is using UDP. If the answer wouldn't fit in 512 bytes the DNS server will tell the client the answer has been truncated. The client is then supposed to redo the query, but now using TCP.
This not so well known fact means that in a firewall configuration, you always have to allow both UDP and TCP traffic on port 53.
Some tests:
Code:
$ dig +norecurse hegel.de.filo @192.168.222.245
; <<>> DiG 9.4.2-P2 <<>> +norecurse hegel.de.filo @192.168.222.245
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48139
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;hegel.de.filo. IN A
;; ANSWER SECTION:
hegel.de.filo. 86400 IN A 192.168.222.2
;; AUTHORITY SECTION:
de.filo. 86400 IN NS ns1.de.filo.
de.filo. 86400 IN NS ns2.de.filo.
;; ADDITIONAL SECTION:
ns1.de.filo. 86400 IN A 192.168.222.245
ns2.de.filo. 86400 IN A 192.168.222.200
;; Query time: 3 msec
;; SERVER: 192.168.222.245#53(192.168.222.245)
;; WHEN: Mon Dec 7 06:51:30 2009
;; MSG SIZE rcvd: 115
The flag 'aa' (authoritative answer) tells us that the answer has been given by an authoritative nameserver, and not a recursive resolver. The so-called glue records are provided in the ADDITIONAL SECTION.
A reverse lookup:
Code:
$ dig -x 192.168.222.6 @192.168.222.245
; <<>> DiG 9.4.2-P2 <<>> -x 192.168.222.6 @192.168.222.245
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63453
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;6.222.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
6.222.168.192.in-addr.arpa. 86400 IN PTR marcuse.de.filo.
;; AUTHORITY SECTION:
222.168.192.in-addr.arpa. 86400 IN NS ns1.de.filo.
;; ADDITIONAL SECTION:
ns1.de.filo. 86400 IN A 192.168.222.245
;; Query time: 2 msec
;; SERVER: 192.168.222.245#53(192.168.222.245)
;; WHEN: Mon Dec 7 07:25:41 2009
;; MSG SIZE rcvd: 107
Here we forgot to specify the 'norecurse' flag,
so the server tells us that it doesn't do recursive queries. ('rd' stands for 'recursion desired')
To correct this omission
Code:
$ dig +norecurse -x 192.168.222.4 @192.168.222.245
; <<>> DiG 9.4.2-P2 <<>> +norecurse -x 192.168.222.4 @192.168.222.245
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32880
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;4.222.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.222.168.192.in-addr.arpa. 86400 IN PTR husserl.de.filo.
;; AUTHORITY SECTION:
222.168.192.in-addr.arpa. 86400 IN NS ns1.de.filo.
;; ADDITIONAL SECTION:
ns1.de.filo. 86400 IN A 192.168.222.245
;; Query time: 2 msec
;; SERVER: 192.168.222.245#53(192.168.222.245)
;; WHEN: Mon Dec 7 07:30:08 2009
;; MSG SIZE rcvd: 107
Again an authoritative answer (aa) flag.
You may wonder, why we have to specify the nameserver with '@192.168.222.245'.
The answer is simple. The only legitimate nameservers listed in "/etc/resolv.conf" are always recursive resolvers and never authoritative
.
So if we want to test our authoritative nameserver, we have to tell dig which server to use.