Dynamic DNS

[Brian J. Murrell]

from the quill of Irina Goble <irinag at ims.com> on scroll
<199908061624.JAA26353 at speed.ims.com>
> 
> 	I'm not sure what the first DDNS method means but there is 
> definitely a problem with the new DDNS methodology.

The first was the method based on your code.

> 	calling updatePTR(1.1.168.192.in-addr.arpa, masha.test.com, 600, lease)
> at this point: nsupdate(1.1.168.192.in-addr.arpa, masha.test.com, DELETE)
> but
> we have 1.1.168.192.in-addr.arpa. IN PTR vasya.test.com.
> 
> 	Brian, I don't see how it can work, Please explain this.

You are right.  Ted has some code from me right now that corrects this
problem.  My opinion of it was that it is hacky, but I am not sure how to
deal with it otherwise.  The essence of it is that if the fwd-name changes,
then that is remembered on one update and checked on the subsequent update.
I believe the updatePTR also sets the rdata to NULL to remove all PTRs for
the address too.

> I think update should be done as a single transaction when we have all
> data (ddns_fwd_name and ddns_rev_name are the base for all updates) and
> during the transaction it is possible to do all additional RRs for those
> names (ddns_fwd_name, ddns_rev_name).

But how to be flexible in dealing with the different needs of different
people.  Karl's request today being an example.  He wants to be able to
install differing MX records too.

This thing could get quite ugly.  I think we need to set up a data
structure and methodology to remember what has to be "undone" when a lease
is changed or released, etc.

b.



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