Dynamic DNS

[Brian J. Murrell]

from the quill of Irina Goble <irinag at ims.com> on scroll
<199908062009.NAA26539 at speed.ims.com>
> 
> 	Sorry, I had to say from ddns update's point of view.

Ahhhh.  Should be nothing then.

> 	You can remove all RR sets for a name with TYPE=ANY, TTL=0,
> CLASS=ANY, RDLENGTH=0, RDATA=emtpy (there is no difference between A and
> PTR RR updates :-) 

OK.  I really didn't want to get into a situation of having to "clear the
decks" before doing updates for a client but I think that is going to be
necessary.  In the case of a roaming client, if he is on subnet "A" and has
a lease for address "a" and an update is done and then he moves to subnet
"B" and requests a lease for address "b" there is no way to know that the
update for "b" is going to fail because his name is already in use to point
to "a".  I can see nothing short of a "clear all RRs for this name" before
trying to apply the new RR as fixing this problem.  As much as I didn't
want to have that sort of thing.

> But from draft-ietf-dhc-dns-10 section 3.4.3:
> 	"The first rule in removing DNS entries is be sure that an
> 	antity removing a DNS enrty is only removing an enrty for 
> 	which it is responsible"

Yes, that is a level of conformance that I am not ready to implement right
now.  I am afraid I have bigger fish to fry.  Roaming is one of them.

> It could be nice to have asynchronous ddns support, doesn't it?

That is coming, but how would it help deal with our issues?

On another note... I have not done much with prereqs in DDNS.  Does a
prereq apply to all updates in the same transaction or just to the RR
update immediatly following?

I am seeing a need to send the following in order to update a given name
address pair of h.example.com @ 192.168.1.1:

1	prereq: {yxdomain} h.example.com. IN A 
2	update: {delete} h.example.com IN A
3	update: {add} h.example.com. 600 IN A 192.168.1.1
4	prereq: {yxdomain} 1.1.168.192.in-addr.arpa. IN PTR 
5	update: {delete} 1.1.168.192.in-addr.arpa. IN PTR 
6	update: {add} 1.1.168.192.in-addr.arpa. 600 IN PTR h.example.com.

The question is can I sent them all in one request, or do they have to be
split 1, 2 & 3 in one request 4, 5 & 6 in another, or even worse 4 seperate
requests made up of 1 & 2, then 3 then 4 & 5, and then 6?

The last is the ugliest case, because it means more traffic, more
processing on behalf of both the dhcp and dns servers and it also means
twice as much zone churn as is necessary as the serial number on each zone
will change twice.

I have to implement this this weekend as I have just been bitten by subnet
roaming and step #2 above is not being done and therefore step 3 is
failing.  ~sigh~

b.



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