[Dibbler] Dibbler FQDN+TA version

[Tomasz Mrugalski]

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

[snip]
> 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
> expiry.
>
> 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.

Cheers,

-- 
Tomasz Mrugalski,              | "We all know Linux is great...it does    |
thomson(at)klub(dot)com(dot)pl |  infinite loops in 5 seconds."           |
                                |                           Linus Torvalds |