17.5 Dynamic DNS Server Updates and TSIG Authentication

     

Now that we have configured a Dynamic DNS server, we should not manually update the database files. If we get it wrong, we are in big trouble. We have a utility called nsupdate that will perform updates for us. It's relatively straightforward to use. It is an interactive command. Once you have become familiar with the options, variables , and commands you need to supply to nsupdate , you could automate this process by constructing a shell " hear-script " to pass the relevant information to nsupdate using input redirection. Here I am adding a record for a node called frog021.maabof.com (the “d option is only to show you all the output from nsupdate ):

 

 root@hpeos004[dns]  nsupdate -d  >  server 192.168.0.35  >  update add frog021.maabof.com 86400 A 192.168.0.21  > >  show  Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0 ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: frog021.maabof.com.     86400   IN      A       192.168.0.21 >  send  Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:  60749 ;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;frog021.maabof.com.            IN      SOA ;; AUTHORITY SECTION: maabof.com.             0       IN      SOA     hpeos004.maabof.com. root.hpeos004.maabof graphics/ccc.gif .com. 18 10800 3600 604800 86400 Found zone name: maabof.com The master is: hpeos004.maabof.com Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  46015 ;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 >  quit  root@hpeos004[dns] root@hpeos004[dns]  nslookup frog021  Name Server:  hpeos004.maabof.com Address:  192.168.0.35 Trying DNS Name:    frog021.maabof.com Address:  192.168.0.21 root@hpeos004[dns] 

The TTL value (86400) is a required field. If I had multiple updates, I would add/delete them and then perform one send operation.

This update does not make use of the TSIG security features. To perform a secure update, we must use the key files that we created some time ago with the dnssec-keygen command:

 

 root@hpeos004[dns]  ll K*  -rw-------   1 root       sys       110 Oct 21 15:26 Krndc.+157+65409.key -rw-------   1 root       sys       145 Oct 21 15:26 Krndc.+157+65409.private root@hpeos004[dns] 

The domain name (really a key name ) that we used to create these keys was rndc . This is listed in the .key file:

 

 root@hpeos004[dns]  cat Krndc.+157+65409.key    rndc   . IN KEY 0 2 157 L4Et2wOlxj6CYKIf8g2AbOjBaa+DSDhmGoDOARdsx4WfBbkbiwyKT+BFZ5d FBNrPY7XBDa/uSluKmfyB3kUPeQ== root@hpeos004[dns] 

This key was given a name in the /etc/rndc.conf file of TSIGkey . It's the same as the key name we referenced in the /etc/named.conf file. We need to update the Krndc.+157+65409.key file to reflect this key name.

 

 root@hpeos004[dns]  vi Krndc.+157+65409.key   TSIGkey  . IN KEY 0 2 157 L4Et2wOlxj6CYKIf8g2AbOjBaa+DSDhmGoDOARdsx4WfBbkbiwyKT+BF Z5dFBNrPY7XBDa/uSluKmfyB3kUPeQ== root@hpeos004[dns] 

As long as we have this updated key file, we can perform an authenticated update using Transaction Signatures. Even though we have updated the .key file, we specify the .private file on the nsupdate command line:

 

 root@hpeos004[dns]  nsupdate -d -k Krndc.+157+65409.private  Creating key... >  server 192.168.0.35  >  update add frog022.maabof.com 86400 A 192.168.0.22  >  show  Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0 ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: frog022.maabof.com.     86400   IN      A       192.168.0.22 > >  send  Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:   6083 ;; flags: qr aa rd ra ; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;frog022.maabof.com.            IN      SOA ;; AUTHORITY SECTION: maabof.com.             0       IN      SOA     hpeos004.maabof.com. root.hpeos004.maabof graphics/ccc.gif .com. 20 10800 3600 604800 86400 Found zone name: maabof.com The master is: hpeos004.maabof.com Reply from update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  38968 ;; flags: qr ra ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1 ;; TSIG PSEUDOSECTION: tsigkey.                0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1066758248 300 graphics/ccc.gif 16 LpgrzhaPjrkqSpSo5nfnnw== 38968 NOERROR 0 >  quit  root@hpeos004[dns]  nslookup frog022.maabof.com  Name Server:  hpeos004.maabof.com Address:  192.168.0.35 Trying DNS Name:    frog022.maabof.com Address:  192.168.0.22 root@hpeos004[dns] 

We can see the update transaction in netdaemon.log :

 

 root@hpeos004[dns]  tail -1 /var/adm/syslog/netdaemon.log  Oct 23 14:44:08 hpeos004 named[12156]: client ::ffff:192.168.0.35#50523: updating zone graphics/ccc.gif 'maabof.com/IN': adding an RR root@hpeos004[dns] 

This seems to be working fine.

17.5.1 TSIG authentication for zone transfers

We can use the same idea of authentication for zone transfers between master and slave servers. The configuration relies on the same key and the same secret being known on both servers, i.e., configured in the /etc/named.conf file.

 

 root@hpeos002[dns] #  cat /etc/named.conf  # # type domain source file # options {         directory "/etc/dns";         listen-on { any; };         listen-on-v6 { any; };         random-device "/dev/random"; }; key TSIGkey {         algorithm "hmac-md5";         secret  "L4Et2wOlxj6CYKIf8g2AbOjBaa+DSDhmGoDOARdsx4WfBbkbiwyKT+BFZ5dFBNrPY7XBDa/uSluKmfyB3kUPeQ==";  }; controls {         inet 127.0.0.1 allow { 127.0.0.1; } keys { TSIGkey; };         };  server 192.168.0.35 {   transfer-format many-answers;   keys { TSIG-key; };   };  zone "0.0.127.IN-ADDR.ARPA" {         type master;         file "db.127.0.0"; }; zone "IP6.INT" {         type slave;         file "db.IP6.INT";         masters {                 192.168.0.35;         }; }; zone "maabof.com" {         type slave;         file "db.maabof";         masters {                 192.168.0.35;         }; }; zone "168.192.IN-ADDR.ARPA" {         type slave;         file "db.192.168";         masters {                 192.168.0.35;         }; }; zone "." {         type hint;         file "db.cache"; }; root@hpeos002[dns] # 

You will need to ensure that your / etc/rndc.conf file has the same key to ensure that the nsupdate command works. You will also notice that I have included the key in the definition of our master server. I now update my master server to specify which hosts are allowed to perform transfers and which key to use:

 

 root@hpeos004[dns]  cat /etc/named.conf  # # type domain source file # options {         directory "/etc/dns";         listen-on { any; };         listen-on-v6 { any; };         random-device "/dev/random";         forwarders { 213.1.119.101; 213.1.119.102; }; }; acl MASTER {         localhost;         ::ffff:192.168.0.35;         ::ffff:192.168.0.66;         }; key TSIGkey {         algorithm "hmac-md5";         secret "L4Et2wOlxj6CYKIf8g2AbOjBaa+DSDhmGoDOARdsx4WfBbkbiwyKT+BFZ5dFBNrPY7XBDa graphics/ccc.gif /uSluKmfyB3kUPeQ==";         }; controls {         inet 127.0.0.1 allow { 127.0.0.1; } keys { TSIGkey; };         }; zone "0.0.127.IN-ADDR.ARPA" {         type master;         file "db.127.0.0"; }; zone "IP6.INT" {         type master;         file "db.IP6.INT";         allow-update { MASTER; };  allow-transfer { 192.168.0.34; key KSIGkey; } ;  }; zone "maabof.com" {         type master;         file "db.maabof";         allow-update { MASTER; };  allow-transfer { 192.168.0.34;  key KSIGkey; }  ; }; zone "168.192.IN-ADDR.ARPA" {         type master;         file "db.192.168";         allow-update { MASTER; };  allow-transfer { 192.168.0.34; key KSIGkey; } ;  }; zone "." {         type hint;         file "db.cache"; }; root@hpeos004[dns] 

On restarting, the named daemon, we should monitor the netdaemon.log file to ensure transfers are occurring as normal.

 

 Oct 22 23:27:41 hpeos004 named[21538]: client 192.168.0.34#50363: transfer of 'IP6.INT/IN' graphics/ccc.gif : AXFR started Oct 22 23:27:41 hpeos004 named[21538]: client 192.168.0.34#50365: transfer of '168.192 graphics/ccc.gif .IN-ADDR.ARPA/IN': AXFR started Oct 22 23:27:41 hpeos004 named[21538]: client 192.168.0.34#50364: transfer of 'maabof.com graphics/ccc.gif /IN': AXFR started root@hpeos004[dns] 

If you see a transfer being refused , a common problem will be that the servers are not in time synchronization; they must be; ensure that NTP is set up, running, and synchronized with a reliable time source.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net