Dynamic DNS

Brian J. Murrell brian_murrell at bctel.net
Fri Sep 3 23:43:59 UTC 1999


from the quill of Irina Goble <irinag at ims.com> on scroll
<199909032230.PAA10914 at ims.com>
> 
> 	I did not dig it either. But as named starts xfer/ixfr by calling
> named-xfer it needs these files.

Wow, I guess I have not looked recently, but I would have thought named
would have "sucked up" and integrated the functionality of named-xfer a
while ago.  Hmmmmmph.

> 	Really I like res_sendsigned() because it is not so expensive.
> Just imagine a few dns requests off! 

Yes, in the context of the DHCP server, you are of course right.

> What I meant in the tsig patch is to have an internal cache of
> authoritative
> NS for every zone.

You are correct that this is the most efficient way of doing this.  My
context has been updating the nsupdate utility to accept a "-k keyfile"
parameter to sign "one off" updates.  res_nupdatesigned() makes more
sense in that context.

Did you look at res_nfindprimary() at all?  I did but could not make
sense of how or more accurately what (out of the update request list) it
was trying to find the SOA of.  I brought a couple of problems with that
function to the attention of bind-workers too.

>  There are some problems:
> 	1. if the primary server from a SOA RR (aka a primary master) is not 
> 	listed in NS RRs.
> 	2. there are some subdomains, the patch will not recognize them.
> 	(if "test.example.com" is in the cache, the patch will send requests
> 	for "dhcp.test.example.com" zone to the primary for
> "test.example.com")
> It just needs more code to check for rcode="not authoritative".

I guess I did not look deeply enough at your code to discover that.

> 	I grew up and now understand that ddns transactions for forward and
> reverse names should be independent.

Oh?  I am close to agreeing.  The thing that is lacking in keeping them
independant is a proper cleanup on (DHRELEASE?  I don't recall) lease
expiry (without renewal).  Right now without it, the "add lease" process
needs to worry about cleanup of prior DNS entries.

> It is logical to have FQDN in the lease structure as the dhcp-dns
> draft
> introduces the client FQDN option (code 81).
> With this option updates for
> forward (if any) and reverse domain names can be done independent.

Yes, indeed.

> 	I have a question. If an administrator wants to control hostnames
> (assign a fixed name or use a pattern, wharever).

With respect to offering that name back to the client (which windows
will ignore, but let's not discount all clients as being that stupid) or
just with respect to updating the DDNS?

> There is a host-name option
> but how can I use it without "on commit if dns-update"? 

I think I am lost on what you want to do.

> What is a scope of the host-name option?

I think I am still lost.  :-)

b.


--
Brian J. Murrell                              InterLinx Support Services, Inc.
North Vancouver, B.C.                                             604 983 UNIX
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD


More information about the dhcp-hackers mailing list