nsupdate and round robin

[Kevin Darcy]

Victor Hugo dos Santos wrote:
> 2006/12/14, Mark Andrews <Mark_Andrews at isc.org>:
>
> hello,
>
>   
>>> i need setup dns with option of "round robin" and this is my actual
>>> zone file (only relevant lines):
>>>       
>
> [...]
>
>   
>>> www     60      IN      A       200.200.200.201
>>> www     60      IN      A       200.200.200.202
>>> www     60      IN      A       200.200.200.203
>>> --------------------------------------------
>>>       
>
> [...]
>
>   
>>> but, i don't know how delete/update the specific host (www 60 IN A
>>> DINAMIC_IP) and not other www hosts for this zone with round robin
>>> options !!!
>>>       
>> nsupdate
>> update delete www.<zone> A <oldaddress>
>> update add www.<zone>. 60 A <newaddress>
>> send
>>     
>
> but.. the "oldaddress" is dynamic !!!
> or you know one secure alternative for get the host with dynamic
> "oldaddress" in middle of other hosts/registers ???
>
>   
I'm not sure what you're saying here. nsupdate doesn't care whether an 
address is "dynamic" or not, it treats all of the records it manipulates 
as "dynamic" in the sense that they are subject to change. Any given 
invocation/instance of nsupdate doesn't inherently know about any other 
processes or subsystems that might be trying to update the same data.

If what you're saying is you have a mixture of "static" entries and 1 
"dynamic" entry associated with a particular domain name, then the 
algorithm I'd follow would be:
1. do a lookup of the name and enumerate all of the addresses
2. identify the "dynamic" one through process of elimination (i.e. it's 
the only one not from the "static" list)
3. submit a record-specific (as Mark described above) Dynamic Update of 
that record with also a _prerequisite_ that the old "dynamic" record 
exists with the value determined from Step #2.
4. If the  Dynamic Update fails because the prerequisite  is not met, 
then presumably this is because the record is being updated by some 
other process or subsystem while you are trying to make your update. 
Repeat the sequence at Step #1, but you might want to put a limit on the 
number of such "restarts" so as not to get in an "infinite" loop.
5. Otherwise, if the update is successful, then you're done.

Alternatively, you might potentially be able to co-ordinate these 
disparate processes/subsystems by using some sort of "flag" record to 
control update access. But I don't know the capabilities of these other 
processes/subsystems in your environment, so I don't know if that's even 
feasible.

                                                                         
                              - Kevin