Please help me write a /var/named/named.local that works!

Question

Dear Mac Wizards,
named.local in /var/named is severely broken, as a result reverse-lookup does not work. Here is the output of
$ sudo named-checkzone named.local /var/named/named.local
dnsmasterload: /var/named/named.local:3: ignoring out-of-zone data (0.0.127.in-addr.arpa)
dnsmasterload: /var/named/named.local:9: ignoring out-of-zone data (0.0.127.in-addr.arpa)
dnsmasterload: /var/named/named.local:11: ignoring out-of-zone data (1.localhost)
zone named.local/IN: could not find NS and/or SOA records
zone named.local/IN: has 0 SOA records
zone named.local/IN: has no NS records
Here is what named.local looks like for the moment. It SHOULD contain reverse-lookup info for the head node, 192.168.1.1, and all the subsequent nodes up to 192.168.1.11. Please assist! I don't want to hose my dns by doing this incorrectly. Thank you very much!
$ more named.local
$ORIGIN localhost.
$TTL 86400
0.0.127.in-addr.arpa. IN SOA localhost. root. (
2006102335 ; Serial
3H ; Refresh
15M ; Retry
1W ; Expire
1D ) ; Minimum
0.0.127.in-addr.arpa. IN NS localhost.
1 IN PTR localhost.
xserve   Mac OS X (10.4.8)   cluster configuration

Answer 1

The answer to this question eventually came from a combination of this short discussion (http://discussions.apple.com/thread.jspa?messageID=660760) and a lot of document reading.
named.local SHOULD look like this:
$TTL 86400
@ IN SOA localhost. root. (
2006102436 ; Serial
3H ; Refresh
15M ; Retry
1W ; Expire
1D ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
If you use server admin to configure DNS zones, extra lines get inserted:
$ORIGIN localhost.
$TTL 86400
0.0.127.in-addr.arpa. IN SOA @.0.0.127.in-addr.arpa. root. (
2006102436 ; Serial
3H ; Refresh
15M ; Retry
1W ; Expire
1D ) ; Minimum
0.0.127.in-addr.arpa. IN NS @
1 IN PTR localhost.
“What's that ‘$ORIGIN localhost.’ on the first line? And why has the SOA turned into ‘@.0.0.127.in-addr.arpa.’ ?” Asks a previous discussion. No one seems to know-we only know that when these lines appear, your reverse-lookup gets hosed and BIND doesn't work like it should.
In case anyone cares, you can write your own zone files by hand. I'll translate one here as an example:
db.192.168.1
$TTL 86400
1.168.192.in-addr.arpa. IN SOA XXXX.XXX.private. sgifford.brown.edu. (
2006102400 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1h ) ; minimum
1.168.192.in-addr.arpa. IN NS xxxx.xxxx.private.
11.1.168.192.in-addr.arpa. IN PTR node11.xxxx.private.
1.1.168.192.in-addr.arpa. IN PTR hebb.xxxx.private.
8.1.168.192.in-addr.arpa. IN PTR node08.xxxx.private.
2.1.168.192.in-addr.arpa. IN PTR node02.xxxx.private.
both zone files start with the phrase “$TTL 86400”. This stands for “Time To Live”. This tells the domain server how long to cache the records retrieved from the zone file. You could just as easily say “$TTL 1440m” or “$TTL 24h” or “$TTL 1d”. It’s all the same to the server. However, if you want changes that you make to the zone to propagate quickly, you might which to make this time shorter.
The next section is called the SOA, which stands for “start of authority”. The first line declares that zone’s primary domain name is hebb.private, that the class of zone is IN, and that the email address of the person responsible for maintaining the domain is [email protected], with a “.” instead of a “@”.
Then comes the SOA and a series of mysterious lines, all of which are conveniently labeled in English. The serial # is an interesting one. It is used by the BIND demon, which loads the DNS zones at startup. If you change the zone file but do NOT change the serial number, Bind will ignore the changes. This is key. So, how do you write a new one? Fortunately, there is a standard format to these numbers: serial number = YYYYMMDDNN. So the serial number in db.192.168.1 is 2006102400, meaning that it is the first version of this file written on 10-24-2006. If you look at the hebb.private.zone file, you will see that the serial number is 2006102413. This was the 13th version of this file written on 10-24-2006. Ironically enough, it was the one that finally worked. I hope that you never have to use this piece of information, but FYI the maximum number of versions per day is 100.
Below the serial number is a short list that looks like this:
3h; refresh
1h; retry
1w; expiry
1h); minimum
These mean pretty much what they look like they should mean. Refresh is how often the BIND will come looking for a new serial number: in this case every 3 hours. If the master DNS server fails to accept changes to the zone-as it will if this file is not written correctly-BIND will Retry every hour. If BIND fails to update the master DNS server with the new zone information, the DNS server will continue to act on the last valid information that it had until its Expiry, which I have set here for 1 week. That’s probably the shortest period of time that I would choose-any shorter and you may or may not have time to catch and correct the changes before dns comes crashing down. The last field, the minimum, has a singular purpose: to cache negative TTL answers. If you take a node offline, but leave its record in the zone file, BIND will continue to query for that node, despite there being no answer. How long BIND continues to query is set here. Unlike the expiry, I would set this value to be something small, because BIND will continue to query and take up system and network resources until it gets an answer, or until the Minimum amount of time passes.
Now that you understand what amounts to the header information in this file, we get into the real meat of it: where it defines the nameserver and lays out the map of the domain. All of this takes place in the lines:
xxxx.private. IN NS xxxx.xxxx.private.
xxxx.private. IN A 192.168.1.1
node11 IN A 192.168.1.11
xxxx IN A 192.168.1.1
node08 IN A 192.168.1.8
node02 IN A 192.168.1.2
node03 IN A 192.168.1.3
node04 IN A 192.168.1.4
node05 IN A 192.168.1.5
node06 IN A 192.168.1.6
node07 IN A 192.168.1.7
node09 IN A 192.168.1.9
node10 IN A 192.168.1.10
fileserver IN A 192.168.1.xxx
The first line contains the “NS” – the nameserver used to lookup a domain. The next line begins a series of lines, each of which are “A” record that is used to link the fully qualified domain name to an IP address. In the reverse map, db.192.168.1, you will see, instead of “A” record, “PTR”:
1.168.192.in-addr.arpa. IN NS xxxx.xxxx.private.
11.1.168.192.in-addr.arpa. IN PTR node11.xxxx.private.
1.1.168.192.in-addr.arpa. IN PTR hebb.xxxx.private.
8.1.168.192.in-addr.arpa. IN PTR node08.xxxx.private.
2.1.168.192.in-addr.arpa. IN PTR node02.xxxx.private.
3.1.168.192.in-addr.arpa. IN PTR node03.xxxx.private.
4.1.168.192.in-addr.arpa. IN PTR node04.xxxx.private.
5.1.168.192.in-addr.arpa. IN PTR node05.xxxx.private.
6.1.168.192.in-addr.arpa. IN PTR node06.xxxx.private.
7.1.168.192.in-addr.arpa. IN PTR node07.xxxx.private.
9.1.168.192.in-addr.arpa. IN PTR node09.xxxx.private.
10.1.168.192.in-addr.arpa. IN PTR node10.xxxx.private.
109.1.168.192.in-addr.arpa. IN PTR fileserver.xxxx.private.
PTR stands for “DNS Pointer”, and makes reverse-mapping possible.
Now that you know what you’re looking at, you can begin to see how straightforward it is to edit a zone by hand. You can change any of these values, change the serial number and wait for BIND to come around and refresh in 3 hours. Or, you can stop and restart the nameserver using the following commands:
$ sudo serveradmin stop dns
$ sudo serveradmin start dns
BIND should come around looking for the zone file. If it doesn’t, you can call:
# named –f
Named reads the default configuration of /etc/named.conf, which will direct it to look in the zone files for configuration information. If you are having major troubles with DNS, run named in the foreground with the highest level of debugging possible, level 9:
# named –g -d 9
You can also redirect the output to a file for easier inspection:
# named –g -d 9 >& /tmp/named.out &
Good luck-may the force be with you.
xserve Mac OS X (10.4.8) cluster configuration
xserve Mac OS X (10.4.8) cluster configuration