nsupdate and round robin

[Mark Andrews]

> 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.

	Current named's and nsupdate's will handle DHCID just fine.
	They will just treat it as a unknown type until you update
	to BIND 9.5 which knows about DHCID.
 
> 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.

	Clean out old records.

	for (oldip in www.example.com A) {
		if (<oldip> == <currentip>)
			continue;
		// blow away any addresses we used to own.
		update {
			prereq exists <oldip>._.www.example.com DHCID <value>
			delete <oldip>._.www.example.com DHCID
			delete www.example.com A <oldip>
		}
	}

	Whenever you get a new lease just add a new entry blowing way
	any existing DHCID.

	update {
		delete <newip>._.www.example.com DHCID
		add <newip>._.www.example.com DHCID value
		add www.example.com A value
	}

	You endup with one DHCID record per address under _.www.example.com.

	Each "update" block above is executed atomically (one update
	request).

	We use _.www.example.com. as it is in the same zone as
	www.example.com which allows the prereq to work.  The
	underscore keeps it out of the legal hostname namespace.
 
	You will still want a watchdog process(es) to pull
	non-responsive (dead) instances.  If you do that have each
	machine periodically re-add itself.

> 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
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org