[Dibbler] Dibbler FQDN+TA version
thomson at klub.com.pl
Fri Jun 30 00:26:21 CEST 2006
On Thu, 29 Jun 2006 somebody known as Karl Auer wrote:
>>> - it sends that name to the server as part of its request
>> hmmm, it can send its name to the server as a hint only. Server can take
>> this into consideration or ignore this hint completely and provide other
> Yes, correct. Likewise the client can ignore the name delivered by the
> server. With DHCPv4, WindowsXP does not update its internally configured
> DNS name if the server provides some other name.
Hmmm, so basically its fdqn name is ignored, right? Well, setting up
hostname in Linux is quite easy - just invoke "hostname" command. But on
Windows systems... hmmm. Anyway, I suppose dibbler should act like this:
- obtain name via DHCPv6
- get current name and store it
- set name obtained from DHCPv6
And then during shutdown:
- set previously stored name
> A reverse update is essential these days; most DHCP servers that support
> DDNS do it this way:
> - attempt to insert the forward lookup
> - if that works, attempt to insert the reverse lookup
> - repeat the above on renew/rebind
> - attempt to delete both entries when the lease expires
> - failed update attempts are logged, but do NOT affect
> the allocation of addresses
Seems ok. Thanks for this algorigtm. That's the way it will be working in
dibbler. Well, soon.
> - when making an update, mark the update with a
> hashed TXT record
> - don't overwrite, delete or modify any entry unless
> it is marked as "yours".
Nice trick. But such mechanism might be implemented in future versions.
>>> - when the lease expires, the server does dynamic updates to
>>> remove these entries from the DNS
> No :-) The TTL is just how long a query may be cached for. It has
> nothing to do with removing the entry. Once made, the entry will be
> there forever until explicitly removed.
And what about server crashes/shutdowns/power outages? How, in your
oppinion, should look like a disaster recovery procedure? I mean, after
server is started and it detects that it was not shutdown properly?
> If the DHCP client is doing the updates, then it can ignore the server
> and add whatever name it likes. Depending on the clients, they may also
> do bad things, like delete names they should not delete! And of course
> their users may run other update software, and use that other software
> to do any kind of DDNS update. It is better to have updates coming from
> a source you can control.
> Also, letting the DHCP server deal with it puts an extra layer between
> the client and the DNS server. The server can (for example) append
> specific domains to incomplete names. Also, the server can be configured
> to bypass some aspects of the protocol if needed - for example, to
> update a specified nameserver rather than the server named in the MNAME
> field of the SOA record. In fact, that feature is pretty much essential
> in a big network.
I see. I think this will be quite easy to implement. Just another option
in the server's config. file. Administrator will specify target DNS
server, which perform updates at.
> And finally (and this is the MOST important point) a DHCP client cannot
> remove its DNS entries at the end of a lease! Or if it crashes, loses
> power or goes out of range on a wireless network, as you pointed out.
> Those entries remain, even when the DHCP client is no longer on the net
> and its lease is no longer valid. Only the DHCP server can manage lease
> So we would MUCH prefer to see the server doing DDNS on behalf of the
> clients. We can test some things with the DHCP clients doing the
> updates, but will never go that way in production.
You have convinced me. DDNS on the server side will be the default mode
and client side updates will be optional.
> Doing the DNS adds and deletes should be done in at least one separate
> thread (or a thread pool) so that address allocation is not delayed. DNS
> updates do not have to be a high-priority task within the server. The
> DNS server will not propagate dynamic updates to its secondaries for
> quite a long time anyway - typically many minutes.
Well, up to this point, dibbler was single threaded. It had major
benefits: easy portability, simple desing, no race conditions/inter-thread
lockdowns etc. But if the new thread will only be doing updates and
logging its results, it should work ok.
Thanks for details explanation. I only have limited experience as a
network admin, so your suggestions are much appreciated.
Tomasz Mrugalski, | "We all know Linux is great...it does |
thomson(at)klub(dot)com(dot)pl | infinite loops in 5 seconds." |
| Linus Torvalds |
More information about the Dibbler