nsupdate and round robin
kcd at daimlerchrysler.com
Thu Jan 4 03:58:44 UTC 2007
Victor Hugo dos Santos wrote:
> 2007/1/2, Kevin Darcy <kcd at daimlerchrysler.com>
> look this records of one zone:
> www 60 IN A 220.127.116.11
> www 60 IN A 100.100.100.100
> www 60 IN A 18.104.22.168
> www 60 IN A 22.214.171.124
> www 60 IN A 126.96.36.199
> 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.
More information about the bind-users