Dynamic DNS

[Brian J. Murrell]

from the quill of Irina Goble <irinag at ims.com> on scroll
<199908070034.RAA26899 at speed.ims.com>
> 
> 	If you mean by a "command" a Resource Record in the update section, 
> then yes,

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.

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

> 	Sorry, I was thinking about the fix and didn't respond more detailed.
> Here is another diff, it does not need nsupdate from BIND :-)

I don't use the "nsupdate" binary either.  I was using the syntax passed to
it as a way of demonstrating what I would do.  This is the same syntax that
appears in the "<zone>.log" file when an update is processed.  I just
thought using that syntax would make exactly what I was talking about
perfectly clear.

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.

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

b.



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