Dynamic DNS

[Brian J. Murrell]

from the quill of Irina Goble <irinag at ims.com> on scroll
<199908061744.KAA26462 at speed.ims.com>
> 
> 	What is the difference between A and PTR RRs?

Hmmmm.  Normally I would start to explain the difference between a DNS A
and PTR record, but you know that, so I am not sure what you are asking.

> I still think there should be only two transactions: add and delete.
> 
> 	ddns_add (lease)
> 	ddns_delete (lease)

Hmmmm.  Perhaps.  Ted, since the dns-update() expression is your
"brainchild"  :-) would care to jump in with reasoning, etc.  This
non-atomicness of updates is starting to get ugly.  When a client roams
from one subnet to another his new A record gets rejected because his old
one is still in place.  I am thinking that perhaps a nsupdate(remove A)
needs to be stacked on top of the nsupdate(add A), but I don't think you
can remove an A record with NULL rdata to effect a removal of all names. 
Do you know Irina?

> on DHCPACK call ddns_add()
> on DHCPRELEASE call ddns_delete()
> on "ABANDON LEASE" call ddns_delete()
> ddns_add can call ddns_delete to remove some leftovers.

I think some careful design needs to be done here to map out all of the
possible reasons for adds/changes/deletes and make sure that we have all of
the possibilities covered.  Impact on the DNS server is one of the items of
major importance.  From having run a not very large but larger than average
DHCP/DDNS service for a year, I can tell you that gratuitous updates to the
DNS will kill your servers.  You need to only perform updates when they are
absolutely necessary.

> 	I agreed that there is a need for additional RRs (MX, TXT, KEY, etc),
> that is what I meant by "additional RRs". All these "additional RRs" are
> related to ddns_fwd_name or ddns_rev_name, right? So it is not only a
> trigger
> it is a base domain name for update requests. It could be easy to 
> connect add. RRs to PTR by having some parameters/declarations in 
> global/subnet/host declarations? But e.g. for MX RRs it is logical to 
> connect add. RRs to DNS domains and it could be some additional syntax
> in dhcpd.conf. Then _somehow_ we can have all this ns_updrec connected to
> a lease structure. 
> 	struct lease {
> 	...
> 	char *ddns_fwd_name;
> 	char *ddns_rev_name;
> 	struct ns_updrec *ddns_fwd_upd;	/* additional RRs for a ddns_fwd_name */
> 	struct ns_updrec *ddns_rev_upd;	/* additional RRs for a ddns_rev_name */
> 	...
> 	int flags;
> #	define SOME_GOOD_NAME /* for a flag saying who is responsible for
> dyn. updates for a forward name, client or server */

Ted.  At this point I think some direction is needed.  Have you thought any
further than where we are now about the dns-update() expression?  It is
troublesome as it is right now because all updates are not done atomically.

b.



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