[Dibbler] Dibbler FQDN+TA version

Karl Auer kauer at biplane.com.au
Fri Jun 30 04:21:33 CEST 2006


Hi Tomasz.

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

Store it where? Also, the machine can have many names, depending on what
interface is being used and what name that interface is using. I don't
have a problem with the name not being "used" by the client. It might be
useful to have a config option, "use received name as hostname" (which
is what DHCPv4 does in Linux), but otherwise I wouldn't worry about it
too much.

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

Given that the client can request ANY name, the server MUST check that
no-one is trying to claim names that are already in the DNS. Otherwise
my desktop can just grab "www.mydomain.com" any time it likes! This is
another reason why DDNS from the server is better, because you can't
guarantee that the client will check (or that a malicious client won't
deliberately do things like that).

Not needed for testing, but essential for production.

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

There are several approaches. One is to do nothing, but that can be
messy.

Another is if the the DHCP server writes expiry information into the
marker record, and updates the marker record every time the address is
renewed or updated. Then you can write an external program that checks
all the entries in the DNS, and deletes names and addresses that are a)
DDNS entries and b) out of date. You can run the program after a crash,
or just do it at regular intervals.

Leases have to be stored on disk, otherwise the server loses all that
information even when it is stopped properly. The registered name is
stored with the lease information. If the lease information is keyed on
expiry time, it is easy to process all leases that expired earlier than
the current time. Depending on how long the server was down for, this is
work the server would have had to do anyway.

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

Again, there is a simple solution and a more complicated solution. The
simple solution is to specify one server address (or name) and one TSIG
key, and assume that all updates will go to the same server and use the
same TSIG key (that is, they will all go to the same view on the same
server).

There is another complication: Updates need to specify the zone they
apply to, so you really need to have stored zone information. That is,
you need to be able to configure tuples like (zone name, server name,
TSIG key). You then match requested names to the most specific zone
possible, and use that info for the update.

So if the client asks for "foo.bar.mydomain.com", and you have zone
information for mydomain.com and bar.mydomain.com, you would choose
"bar.mydomain.com" and update "foo" using the server and key you have
for that zone. If you had no "bar.mydomain.com", you would choose
"mydomain.com" and update "foo.bar".

Having zone info like this is actually a really big benefit, because you
don't even attempt to do an update if you don't have a zone for it.

And once you have it, it opens the way for all sorts of cool things -
like supporting sites that have internal and external views or even
internal and external servers, and which need different updates to go to
different servers, or different views for different zones. No problem!

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

DDNS updates are a low-priority task, so it doesn't matter if this extra
thread lags a bit.

All this stuff can be done implemented a step at a time. Simple updates
are enough for testing.

Regards, K.

PS: The ISC DHCP client (GPL I think) already does DDNS for IPv4, so the
code might be useful to look at if you haven't already. www.isc.org.

PPS: Have you thought about failover? :-)

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

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