Dynamic DNS

[Irina Goble]

> > But it seems you don't care if there is
> > another RR for that name, right? So you can send the following update
> > message:
> > 	update: {delete} domain.name. IN A ....
> > 	update: {add} domain.name. IN A ip.address.
> 
> I believe that would result in unecessary zone SOA updating however.
> 
	If the domain names are in the same DNS zone, it is one update 
message with two update sections. It looks like this:
	1. delete the A RR for domain.name if there is one, 
	2. add a new A RR,
	3. increment the serial number.

However If the domain names are in different DNS zones then there are two
update messages.

> > 	I agreed, the dhcp server should guarantee that the IP address -
> > domain name mappings are valid if it is responsible for dyn. updates.
> > It should send update requests for every DHCPOFFER/ACK.
> 
> DHCPOFFER/ACK?  Do you mean DHCPREQUEST/ACK?  This is where traffic volume
> gets perhaps unecessarily high (which I have tried to avoid) and this is
> where I wonder about SOA serial number churn.  If we send an update for a
> given name to IP mapping and prerequire that it not exists already that
> should prevent the churn.  But what happens if we prerequire that A -> B
> not exist, but A -> C does somehow exist?  I think we need to map out all
> of the possiblities and plan on how to keep the DNS transactions to a
> minimum while maintaining absolute integrity of the mappings.
> 
	Yes, DHCPREQUEST/ACK, sorry for confusion. By the way, there is no
prerequisite "A -> C does not exist", only "RRset does not exist" and 
"name is not in use".
	
> Some experimentation with DDNS is required as well to determine when SOA
> serial numbers are actually updated.
> 
	I have to reread the RFCs and draft, maybe there could be some tricks.
Right now in my understanding it could look like this:
	
dns_delete (lease):

	/* delete all RRs for the name */
	update: {delete} a.test.com. IN
	
	/* delete all RRs for the IP address */
	update: {delete} 1.1.168.192.in-addr.arpa. IN 
	free lease -> ddns_fwd_name, lease -> ddns_rev_name

dns_add (lease)

	if (lease -> ddns_fwd_name && lease -> ddns_fwd_name == hostname)
	/* make sure that the RRs exist */
		update: {add} a.test.com. TTL IN A 192.168.1.1
		update: {add} 1.1.192.168.in-addr.arpa. TTL IN PTR a.test.com.
	else if (lease -> ddns_fwd_name) 
	/* the IP address is assigned to a different DN */
		dns_delete (lease);
	if (!lease -> ddns_fwd_name)
		prereq: {nxdomain} a.example.com. IN
		update: {add} a.test.com. TTL IN A 192.168.1.1
		
		update: {add} 1.1.168.192.in-addr.
		alloc lease -> dns_fwd_name, lease -> dns_rev_name

For every zone:
Min. update requests: 1		Min serial number incr. : 0
Max. update requests: 2		Max serial number incr. : 2

	Serial numbers are incremented only when the DNS db was changed.
If there is a request to add a RR that already exists (with the same
name and rdata) named will skip such update.

> > 	DHCP-DNS is in alpha-beta yet, right?.
> 
> Still under development actually.  There is a working implementation, but
> IMNSHO it is not as robust as it needs to be.  It is only robust enough to
> work in my current operational environment, and even at that I hacked in a
> "pre-rr-add cleanup" that I have been trying so hard to avoid late on
> Friday afternoon.  The use of which causes the serial number of the zone to
> be updated twice for essentially what is one operation.
> 
	Maybe, in your environment you can skip checkings and if 	
lease -> ddns_fwd_name was changed do just:

	update {delete} a.test.com. IN 
	update {add} b.test.com. IN A 192.168.1.1
	
	update {delete} 1.1.168.192.in-addr.arpa. IN
	update {add} 1.1.168.192.in-addr.arpa. TTL IN PTR b.test.com.
	
	But this is not a common case.
	
> 
> I was wondering what the status of IXFR is.  Does it work?  Is it reliable?
>  The reason to worry now, is that I am in operation with this stuff now. 
> :-)
> 
	I don't know about the status of IXFR.
	
> b.
> 
> 
> 
> --
> Brian J. Murrell                                        
Brian_Murrell at bctel.net
> BCTel Advanced Communications                                      604 454 
5279
> Vancouver, B.C.
>