Re: nsupdate and round robin
Victor Hugo dos Santos
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 ???
tanks and happy holidays !!!
--
--
Victor Hugo dos Santos
Linux Counter #224399
Kevin Darcy
> 2006/12/14, Mark Andrews <Mark_A...@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 ???
>
>
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
Victor Hugo dos Santos
> Victor Hugo dos Santos wrote:
[...]
> 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)
noo.. in the example is only one recorder.. but in the real life, are
very much !! :-(
mmmm.. ok.. other example:
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 ???
very, very thanks
Kevin Darcy
>
> 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 ???
>
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
Mark Andrews
> Victor Hugo dos Santos wrote:
> > 2007/1/2, Kevin Darcy <k...@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_A...@isc.org
Victor Hugo dos Santos
[...]
> > 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.
cool.. DHCID is exactly the option what i needed....but, where is
documentation about this ??? I was reading the RFCs (4701), but theu
are not very clear !!!
very, very tanks for any information.
Kevin Darcy
> 2007/1/4, Mark Andrews <Mark_A...@isc.org>:
>
>>> Victor Hugo dos Santos wrote:
>>>
>>>> 2007/1/2, Kevin Darcy <k...@daimlerchrysler.com>
>>>>
>
> [...]
>
>
>>> 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.
>>
>
> cool.. DHCID is exactly the option what i needed....but, where is
> documentation about this ??? I was reading the RFCs (4701), but theu
> are not very clear !!!
>
http://www.rfc-editor.org/rfc/rfc4703.txt. Hopefully that should make
things clearer.
If you need more "user-level" documentation than that, then, since as I understand it (probably not very well), DHCID is something that is used primarily by DHCP clients, your best bet would probably be to look at your DHCP client documentation, if it already has DHCID capability. If it doesn't, then you need to consider switching to a different DHCP client, getting a third-party modification to your client, or modify your DHCP client yourself. If you're going to implement this yourself, then the RFC(s) already cited should give one sufficient information to accomplish the task (complain to the RFC author(s) if that isn't the case :-)
When I said that BIND didn't support DHCID, I was basing this on the
fact that it doesn't recognize a DHCID RR in a master zone file. But,
this was misguided, since DHCID is intended exclusively for *dynamic*
records, one would never been hand-editing DHCID records into a master
zone file, thus it is sufficient -- as Mark pointed out -- that named
and/or nsupdate can handle it properly as an "unknown" type. So, please
disregard my previous statement about BIND not supporting DHCID...
- Kevin