Dynamic DNS

[Brian J. Murrell]

from the quill of Irina Goble <irinag at ims.com> on scroll
<199908091907.MAA28823 at speed.ims.com>
> 
> 	What you want is impossible.

Indeed.

> 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.

> Just be careful it is harmful! Any host can choose any name and the last
> host
> wins.

In our case, we are prescribing host names, and it is not the name of the
remote machine, so this is not an issue for us, although I agree it is an
issue and should likely be dealt with as per section 3.4 of the dhcp-dns
draft.

> 	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.

Some experimentation with DDNS is required as well to determine when SOA
serial numbers are actually updated.

> 	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.

> When it will be released,
> BIND could have a stable IXFR implementation. Why worry about that now?

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. 
:-)

b.



--
Brian J. Murrell                                        Brian_Murrell at bctel.net
BCTel Advanced Communications                                      604 454 5279
Vancouver, B.C.