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