need help with dynamic DNS updates [SOLVED]

[Ross Boylan]

Executive summary:
dhcpd was not updating dns.  There were 2 problems:
1) The client was not sending its name, and the server was not using
any other method to decide on a name.  So the server never attempted
to update dns.  My solution was to set an option into the client dhcp
config to transmit the hostname.
2) I was missing one of the necessary security declarations.

I changed a number of additional parameters as well (see previous
emails); conceivably one or more of them mattered too.

More discussion follows.

On Sun, Mar 12, 2006 at 11:36:40PM +1100, Glenn Satchell wrote:
> 
> Simon Hobson wrote:
> >
> >Ross Boylan wrote:
> >
> >>Mar 10 20:17:32 wheat named[7080]: client 127.0.0.1#33008: view 
> >>inside: update 'betterworld.us/IN' denied
> >>Mar 10 20:17:32 wheat dhcpd: Unable to add forward map from 
> >>corn.betterworld.us to 192.168.40.25: timed out
> >
> >OK, this tells us a lot. The second line is logged by dhcpd and says 
> >that it attempted an update, but it timed out. Not overly helpful as 
> >it tells us it failed (useful in itself) but not why ...
> 
> If named gets an update request that is not permitted, it ignores it
> and does not reply, hence the requesting process times out.

Ah.  I thought one referred to the forward and one to the reverse
update.  Looking more closely, they both look like the forward
update. (I hope I've got the terms right: forward is from name to IP,
backward the reverse.)

So when dhcpd's request for a forward update fails, it gives up and
doesn't try to do the reverse update?

> 
> >... but the first line, from named, does tell us why - the update was 
> >denied. That means either the zone doesn't have the right "allow 
> >update ..." statement OR the statement is there but the key doesn't 
> >match (not actually sure if mismatched keys causes a more specific 
> >message or not).
> >
> -->8--snip-->8--
> >
> >You now need to figure out why the dns server is denying the update requests.
> >
> >Simon
> 
> Perhaps this was a copy/paste typo in an earlier email? But
> there is no allow-update in the betterworld.us zone, the one in
> the 192.in-addr.arpa looks correct though ...
> 
That's it!  Thank you for your very keen spotting.

I had a different zone I had put the allow-update into by mistake.

Also, Simon's explanation of why different machines would do the
forward and reverse updates made things clearer.  I see the logic of
the current approach, even if it is MS's :)

Thanks to everyone for your help.

There are a couple of lingering issues.

First, should the default behavior of the dhcp client be to transmit
the system's hostname to the dhcp server?  My first set of problems
was caused by its failure to do so.  I added a manual configuration
option on the cient to correct it.  I see a lot of code in the Debian
package that looks as if it's trying to get the hostname, so there
might be a problem there.  I can report that, if it is a problem.
Also, any opinions on whether this is a bug or merely a desirable
missing feature would be good (if it is actually desirable).

Or perhaps the server should be asking for the name explicitly?

Second, my logging in bind9 didn't capture the failures, though I see
it has now captured the successful update.  I realize this is a bind
issue, but I did copy the config from the dhcpd.conf man page :)
logging {
  channel update_debug{
    file "/var/log/dnsupdate.log";
	severity debug 3;
	print-category yes;
	print-severity yes;
	print-time yes;
    };
  channel security_info {
    file "/var/log/dnssec.log";
	severity info;
	print-category yes;
	print-severity yes;
	print-time yes;
    };
  category update {update_debug;};
  category security {security_info;};
};

It's too much to expect bind to log the dns updates that are never
sent because dhcp lacks a hostname, but I'm surprised the earlier
security violations (when I lacked the key) didn't produce a log.

Ross