need help with dynamic DNS updates, better mysteries

Simon Hobson dhcp at thehobsons.co.uk
Sat Mar 11 23:19:07 UTC 2006


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

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


>On "ignore client-updates;" I am currently using the default (allow,
>according to the man page).  However, I'm a little confused about what
>this means.  The man says "The FQDN options includes a flag which,
>when sent by the client, indicates that the client wishes to update
>its own A record."  That sounds as if the client (corn) will directly
>contact the DNS server.  But it continues "the server can be
>configured either to honor the client's intentions or ignore them."
>That makes it sound as if the DHCP server always does the update of
>DNS, and the option just affects how it decides what the hostname is.
>That is reinforced by "If the server is configured to allow client
>updates, the if the client [sends a FDQN], the server will use that
>name .. to update the PTR record."
>
>Or maybe the server updates the PTR and the client updates the A?  But
>that seems really odd.

It might seem odd, but that is the default for Windows clients. One 
argument is that you may be visiting somewhere and want 
somehost.mydomain.com to still point to you - therefore you configure 
your client to update the A record (at YOUR dns server), and let the 
dhcp server update the PTR record. The DHCP server in 
someotherdomain.com can't update mydomain.com unless you've made 
prior arrangements to allow it, so it makes sense for the client 
(which is presumably managed by the owner of mydomain.com) to update 
"it's own" dns server. Similarly, it doesn't make sense to have the 
client update the PTR record since the dhcp server will already have 
an established relationship with the dns server for the subnet 
reverse zone.

In the request, the client will say if it intends doing it's own dns 
update, and if it says it will then the dhcp server only does teh PTR 
record. The "ignore client-updates;" flag tells the dhcp server to 
ignore what the client says and do the A record as well.

>This digression aside, I haven't set up the client to update DNS, so 
>I doubt it is doing so.  It certainly doesn't have the keys.

IIRC it's the default for Windows clients, and on the basis that 
there is no such thing as a non-Windows DNS server, and all Windows 
machines are part of an Active Directory then it does have the keys. 
At least, that is the Microsoft view of the world !

>Why one request was denied and the other timed out (in the exchange at
>the top) I don't know.

See the first comment - one line is from dhcpd, the other is from named.


Then Ross wrote :

>I took the following steps, in this order:
>1. dhcpd.conf gets ignore client-updates;  No change.
>2. client upgrade to dhcp3.  No change.
>3. client config file gets
>    send host-name "corn";
>    This causes the client name to appear in the dialogues with the server and
>Mar 11 11:47:37 wheat named[7080]: client 127.0.0.1#33017: view 
>inside: update 'betterworld.us/IN' denied
>Mar 11 11:47:37 wheat dhcpd: Unable to add forward map from 
>corn.betterworld.us to 192.168.40.49: timed out in the logs.

So when you tell the linux client to send a hostname, you see the 
same update attempts - as (IIRC) Glenn pointed out, you need a 
hostname for dhcp to be able to set an A record. There's been a few 
examples from time to time of how to write a statement which will 
'make one up' based on MAC and/or IP address if nothing is supplied 
by the client.


You now need to figure out why the dns server is denying the update requests.

Simon


More information about the dhcp-users mailing list