[Dibbler] Dibbler FQDN+TA version

Karl Auer kauer at biplane.com.au
Thu Jun 29 02:01:06 CEST 2006

Hi Tomazs.

> > Does anyone have a sample client and sample server config file,
> > preferably commented, that I could use as a stating point? The sample
> > files included don't make sense to me.
> There are none at this time. But since there's at least one person (i.e. 
> you), who is interested in, I'll prepare improved version with docs. I'll 
> do that in this weekend, so expect new version around 2nd July.

Fantastic! Thanks!

> This will be a development version, not a stable one. Do you need windows 
> version, too? It would be great if you could check if everything works in 
> Windows, as my testing capabilities under windows are rather limited.

Yes, Windows is important to us. There is no real problem testing a
linux-only setup, but we need to get started with a mix of operating
systems, and XP is probably the most important.

So far, all the features supported seem to work very well under Windows
XP (I'm not interested in Windows 2000 or NT).

I can't compile on Windows, so I'd need a binary if that's possible.

> > Also, is a FQDN+TA client version of the software needed, or is the
> > "standard" Dibbler WinXP client enough?
> Development (fqdn+ta) version is required. Take note that at this time, 
> only client is able to perform updates.

OK. I've got more comments on that, see below.

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

> > - the server does two dynamic updates to register the name
> >   (forward lookup) and the address (reverse lookup) in the DNS.
> In fact, FQDN specs say that it is a matter of negotiation between server 
> and client, who will perform update. Currently only forward update is 
> done (AAAA record). But I suppose it is easy to extend the code to perform 
> also reverse update.

>From the perspective of the DNS server, it doesn't matter whether the
update comes from the DHCP client or the DHCP server. From the point of
view of the administrator, it makes a big difference.

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

> > - when the lease expires, the server does dynamic updates to
> >   remove these entries from the DNS
> That will be more problematic. When client shuts down, it will remove its 
> name from DNS. However, when client has crashed, went out of range or a 
> power failure occured, this update will not be performed. But if I 
> understand DNS Updates mechanism correcly, each record has its own TTL. 
> When this TTL expires, DNS will remove this record by itself. Did I get it 
> right?

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.

> I'd also like to write a few words about server/client DNS updates. From 
> the security point of view, it is better to let server perform all 
> updates. DNS configuration is simpler, as there is only one IPv6 address 
> which is allowed to perform updates. On the other hand, this approach does 
> not scale well.

I have to disagree with you there. From the point of view of an
administrator of a large network, allowing the clients to do their own
updates is not acceptable.

If updates come from the DHCP server instead then (as you say) filtering
is simpler. Updates, if they work, are typically very fast. Only a
timeout on the update would impact performance, and you will not expect
timeouts between your DHCP server and your DNS server. If you get them,
you have very big problems anyway :-) Hundreds or thousands of clients,
possibly misconfigured, are far more likely to put adverse loads on the
network or the servers.

With only one allowed updater, and that under our control, there is no
problem opening up many, many domains for updates. That is very risky if
DHCP clients are doing the updates, especially if some parts of the
network are public or semi-public (like wireless nets).

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.

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.

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.
> Hey, people! What do you think? Should dibbler support both methods? Or 
> the client-side update only?

Client side is nice, but server side is essential.

Regards, K.

Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (w/h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

More information about the Dibbler mailing list