No subject

one at a time), or non-interactive mode (commands are read from a file).
 
Here is a sample session:
> update delete states.sub.foo.com. in a
> update add states.sub.foo.com. 333 in a 192.168.43.16
>
(that extra line feed is needed to tell nsupdate to execute the commands
entered previously)
 
This tells the sever who is SOA for sub.foo.com to delete
the A record for states.sub.foo.com, and insert a new A record pointing
states.sub.foo.com to the 192.168.43.16 ip address.  The 333 is the TTL for
the A record (required).
 
Make sure the user running the named server process has write access to the
zone files if you want the nsupdate changes to be permanent.  After executing
the nsupdate, the bind server updates the information in it's memory, and
flushes it out to the zone file.  This flushing process holds the same
information (plus the nsupdate changes), but places it into the zone file in
it's own ugly format instead of the pretty one you had before.  Because of
this, I'd limit the size of the zone that is going to accept dynamic updates
to just those zones that need the dynamic feature.
 
The in-addr.arpa entry is also easily updated.  Here is an example session:
> update delete 5.43.168.192.in-addr.arpa. PTR
> update add 16.43.168.192.in-addr.arpa. 333 PTR states.sub.foo.com.
>
 
This session updated the in-addr.arpa entry so states.sub.foo.com's new
IP will resolve to the correct host.
 
Currently (12/10/1999), I've not been able to find a good way to do nsupdate
(application layer) encryption. So instead I've opted to limit the
allow-update (named.conf) to the local ip of the DNS server.  Then we can
run the nsupdate command through a 1 line remote ssh from any trusted remote
host.
 
To allow the ssh command to go through without getting prompted for a
password, you could place the ip of the remote machine into the ~/.shosts file
of the user running nsupdate on the dns server
Example:
If you're running nsupdate on the DNS server as user pak,
su - pak
echo '<Ip of remote host>' >> .shosts
 
Or you could do a ssh-keygen on the remote host, and have a 0 length
pass-phrase.  That would generate a file ~/.ssh/identity.pub.  Take this file
and append it to ~/.ssh/authorized_keys on the DNS server.
 
To test:
ssh <Ip of DNS Server> ls
 
Should return the output without prompting for a password.
 
Here is a sample script to update the name to ip, and ip to name entries:
<BEGIN SCRIPT>
#!/bin/sh
# Change these to the values they need to be
SSH_USER="pak"
DNS_SERVER="192.168.1.1"
HOST="$1"
ADD_IP="$2"
 
if [ X$HOST = X"" ]; then
        echo "Usage: $0 <host to update> <add ip>"
        exit 1
fi
 
DELETE_IP=`nslookup $HOST $DNS_SERVER | grep -v $DNS_SERVER | grep Address | sed 's/^Address://g'`
DELETE_IN_ADDR=`echo $DELETE_IP | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}'`
ADD_IN_ADDR=`echo $ADD_IP | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}'`
 
ssh -l $SSH_USER $DNS_SERVER "(echo "update DELETE $HOST. in a" ; echo "update ADD $HOST. 333 in a $ADD_IP" ; echo "") | nsupdate"
ssh -l $SSH_USER $DNS_SERVER "(echo "update DELETE $DELETE_IN_ADDR PTR" ; echo "update ADD $ADD_IN_ADDR 333 PTR $HOST" ; echo "") | nsupdate"
<END SCRIPT>
 
There are a few problems in doing it this way.  1st off, it's only encrypting
the connection between remote host and dns server, and not checking
authority on the application layer.  Because of this, any user on the DNS
server can send nsupdates to the server.  Secondly, the magic of nsupdate
being able to find the dns server that is SOA for the needed zone is
circumvented by forcing all updates to go through the dns server specified by
the script.  This is not the ONLY way .. and indeed may not be the best way...
but it is a way to get slightly more security than just leaving the
allow_update to just ip based screening without encryption.