- Dynamic DNS
- Of Masters and Slaves
- Accepting and Doing Updates
- TSIG
- The Dynamic Zone
- The Client
- Update Prerequisites
- Update Actions
- Using nsupdate
- Slave Server Issues
- Reverse Zones
- A One Host Zone
- DHCP
- Mixing DNS and DHCP Implementations
- DHCP and Static DNS Entries
- DHCP and Dynamic DNS Entries
- Dynamic Updates by the Client
Using nsupdate
Knowing all this should allow us to operate nsupdate safely. I'm going to sign the update requests using the key generated earlier in this chapter. This command assumes I left the keys in /etc. The part after the colon (:) specifies the name of the key, not the name of the key file:
# nsupdate -k /etc:ns.penguin.bv. > update add magellan.dyn.penguin.bv 1h A 192.168.55.200 > (blank line)
Upon getting the empty line, nsupdate sends an update request to the primary master server. The primary master server will check whether the client is allowed to perform the specified edits and, if so, check the prerequisites. Then, if they are met, it performs the updates all at once. You can now exit nsupdate, press Ctrl+D. Note that pressing Ctrl+D without entering the empty line first will abort the operation. It will not be submitted to the server. You can now test whether the update had any effect:
# dig @ns.penguin.bv. magellan.dyn.penguin.bv. ANY +pfmin ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62041 ;; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUERY SECTION: ;; magellan.dyn.penguin.bv, type = ANY, class = IN ;; ANSWER SECTION: magellan.dyn.penguin.bv. 1H IN A 192.168.55.200
The A record I submitted with nsupdate is in place, so it worked. If you're not using TSIG, but rather IP number authentication, the –k option should not be used. Now the next job is getting the change to the slave servers.
nsupdate is not very good about displaying errors unless you specify the -d (debug) switch. But keeping an eye on the standard messages log file on the server will let you know whether the update was rejected due to authentication problems:
unapproved update from [192.168.55.2].2391 for dyn.penguin.bv
The contents in the zone log and ixfr files will tell you what updates arrive and are approved. This is the content of the dyn.penguin.bv.ixfr file after adding the record shown previously:
;BIND LOG V8
[DYNAMIC_UPDATE] id 27514 from [192.168.55.2].2390 at 958316354
(named pid 3814):
zone: origin dyn.penguin.bv class IN serial 9
update: {add} magellan.dyn.penguin.bv. 60 IN A 192.168.55.200Similar information can be found in the zone log file. If you look at the zone file right after the update, it will (probably) not have been updated with the new information. Rewriting large zone files whenever they are updated is resource consuming. Instead the ixfr and log files are appended with the changes done, and upon occasion BIND will roll all the changes into the zone file and rewrite it. The log and ixfr files are transaction logs as used in databases and modern file systems. When an update is applied to the zone, BIND writes the updates to the logs at once. That way, if the server or BIND crashes, BIND can do a roll forward of the transaction log when BIND restarts and no changes will be lost.
The SOA serial number is updated automatically when an update is received. You do not need to update the SOA record.