nsupdate and round robin

[Kevin Darcy]

Victor Hugo dos Santos wrote:
> 2007/1/2, Kevin Darcy <kcd at daimlerchrysler.com>
>
> look this records of  one zone:
>
> www     60      IN      A       50.50.50.50
> www     60      IN      A       100.100.100.100
> www     60      IN      A       200.200.200.200
> www     60      IN      A       222.222.222.222
> www     60      IN      A       111.111.111.111
>
> this five records is update for distintis clients/machines.. and the
> "idea" is that each machine update your own record and not others.
> now, supposing that your is one my clients/machines, how your know as
> of the registries (in the example of above) it he is yours ???
>
> remember that the IP address of clients/machines is dynamic and is
> changed constantly.
>
> they understand my problem now or no ???
>   
OK, I see what you're saying now. The client's address changes and it 
wants to delete the previous address and add the new address. There's no 
convenient way to do that currently within the widely-deployed DNS 
protocol, that's what http://www.rfc-editor.org/rfc/rfc4701.txt is all 
about, but apparently BIND does not yet support that RR type. I don't 
know that any DHCP clients natively support DHCID either, but then I 
haven't researched the subject in any depth.

In the meantime, the only option that comes to mind would be to keep 
track of those old assignments on your own. You could use a separate 
database for the purpose, or you could encode the data directly in DNS 
as, say, TXT records enumerating MAC-address/IP-address pairings, which 
would be Dynamically Updated in parallel with the regular A/PTR updates 
associated with dynamic address assignment. If you encode the data 
directly in DNS, then, in order to avoid exposing potentially-sensitive 
network information to untrusted parties, you'd probably want to put 
that data in a separate subzone with controlled access, however, e.g. 
dynamic.www.example.com. If you use MAC address or something similarly 
mutable to uniquely identify your clients, then you'd probably also want 
to supplement the mechanism with some sort of periodic "scavenging" 
process which deletes obsolete records, which implies adding some sort 
of timestamping format to the records as well.

If on the other hand you decide to use a database outside of DNS itself, 
then ideally it should at least be a _shared_ database (with appropriate 
locking mechanisms, e.g. a modern RDBMS system) so that clients don't 
step on each other by deleting an "old" A RR of their own which happens 
to have been re-assigned to another client which is legitimately using 
it. Thus, it probably wouldn't be a good idea to try something as crude 
as simply saving the last-assigned dynamic address in a local text file 
on the client.

                                                                         
                  - Kevin