Dynamic DNS

[Irina Goble]

Brian,

> 
> Well not quite.  What I meant was have only say the first of two "commands"
> (i.e. add/delete) rely on the prerequisite being true.  Kind of a:
> 
> if a exists
>     delete a;
> add new rr for a;
> 
> What I want to effect is to have one update, one serial number change, but
> do multiple "operations" in that update.
> 
	What you want is impossible. 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.

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

> > I think it can have a several RRs in the update section as well 
> > as in the prerequisite section (it is in RFC 2136!).
> 
> Yes, it seemed to me unclear although the implication was the entire
> "Update" section got turfed if the Prequiste section was not satisfied.
> 
	Yes, named does not apply updates if the prerequisites are failed.
Here is what rfc2136 says:

"UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place...."
 
> 
> I am thinking before we go any further (indeed, if I can find the time) we
> need to get input from Ted, as he will be the final approval on what kind
> of interface he would like.  The dns-upate() expression is nice, I will
> agree from a granularity of control POV, but it's non-atomicity of A/PTR
> add/delete's is very troublesome.
> 
> I am also wondering if trying to avoid uneccessary updates as I have tried
> to do by carrying around the fwd-name/rev-name baggage in a lease is worth
> it.  Perhaps we should be sending updates on every single DHCP transaction,
> crafted carefully with prerequisites and let the DNS server decided if an
> update is necessary.  Maybe the load on the DNS server doing this is
> insignificant compared to our efforts in trying to mitigate it.
> 
	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.

> What I can tell you from experience though is that unecessary updates that
> cause SOA serial number churn must be avoided, or your master and slave DNS
> servers' will start to diverge and will only get worse as the demand on
> DHCP services increases.  Synchronicity of information between master and
> slave DNS services is important!!
> 
	DHCP-DNS is in alpha-beta yet, right?. When it will be released,
BIND could have a stable IXFR implementation. Why worry about that now?

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