I have a small network setup and I cannot get DNS to work. DHCP is functioning normal and working fine but it cannot update the DNS pointers for some reason. My files are below.
dhcpd.conf -----------------------
ddns-updates on;
ddns-domainname "mydomain.lan";
ddns-update-style ad-hoc;
allow unknown-clients;
option domain-name "mydomain.lan";
option domain-name-servers 192.168.0.1, 4.2.2.4;
option routers 192.168.0.1;
option ntp-servers time.nist.gov;
option netbios-name-servers 192.168.0.1;
option netbios-dd-server 192.168.0.1;
option netbios-node-type 8;
authoritative;
default-lease-time 172800;
subnet 192.168.0.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
authoritative ;
range 192.168.0.200 192.168.0.220;
default-lease-time 172800;
max-lease-time 345600;
host babyuigi {
hardware ethernet 00:11:11:**:bb:**;
fixed-address 192.168.0.***;
}
}
named.conf---------------------
zone "." in {
type hint;
file "root.hint";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "mydomain.lan" {
type master;
notify no;
file "charnigo.lan";
allow-update { 192.168.0.0/24; };
};
zone "0.168.192.in-addr.arpa" {
type master;
notify no;
file "192.168.0.zone";
allow-update { 192.168.0.0/24; };
};
I also noticed these errors:
Jul 22 08:28:43 NIKKI named[3336]: the working directory is not writable
Aug 11 04:10:25 NIKKI dhcpd: if TheBeast.mydomain.lan IN A rrset doesn't exist add TheBeast.mydomain.lan 86400 IN A 192.168.0.210: timed out.
Aug 11 07:33:02 NIKKI named[5680]: zone 'mydomain.lan' allows updates by IP address, which is insecure
Thanks.
You need to define an update key and configure it in both dhcpd.conf and named.conf. The manpage for dhcpd.conf gives an example and, I believe, the standard named.conf contains a commented example.
On openSUSE setting the DHCP hostname in the interface settings doesn’t seem to work you need to use the send host-name “hostname” feature of dhclient.conf but beware that hostname should not be fully qualified as the dhclient.conf example suggests.
I followed this but I don’t seem to get any errors or updates…
Dynamic Dns Update Security
When you set your DNS server up to allow updates from the DHCP server, you may be exposing it to unauthorized updates. To avoid this, you should use TSIG signatures - a method of cryptographically signing updates using a shared secret key. As long as you protect the secrecy of this key, your updates should also be secure. Note, however, that the DHCP protocol itself provides no security, and that clients can therefore provide information to the DHCP server which the DHCP server will then use in its updates, with the constraints described previously.
The DNS server must be configured to allow updates for any zone that the DHCP server will be updating. For example, let us say that clients in the sneedville.edu domain will be assigned addresses on the 10.10.17.0/24 subnet. In that case, you will need a key declaration for the TSIG key you will be using, and also two zone declarations - one for the zone containing A records that will be updates and one for the zone containing PTR records - for ISC BIND, something like this:
key DHCP_UPDATER {
algorithm hmac-md5;
secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone "example.org" {
type master;
file "example.org.db";
allow-update { key DHCP_UPDATER; };
};
zone "17.10.10.in-addr.arpa" {
type master;
file "10.10.17.db";
allow-update { key DHCP_UPDATER; };
};
You will also have to configure your DHCP server to do updates to these zones. To do so, you need to add something like this to your dhcpd.conf file:
key DHCP_UPDATER {
algorithm hmac-md5;
secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone EXAMPLE.ORG. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 17.127.10.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
The primary statement specifies the IP address of the name server whose zone information is to be updated.
Note that the zone declarations have to correspond to authority records in your name server - in the above example, there must be an SOA record for "example.org." and for "17.10.10.in-addr.arpa.". For example, if there were a subdomain "foo.example.org" with no separate SOA, you could not write a zone declaration for "foo.example.org." Also keep in mind that zone names in your DHCP configuration should end in a "."; this is the preferred syntax. If you do not end your zone name in a ".", the DHCP server will figure it out. Also note that in the DHCP configuration, zone names are not encapsulated in quotes where there are in the DNS configuration.
You should choose your own secret key, of course. The ISC BIND 8 and 9 distributions come with a program for generating secret keys called dnssec-keygen. The version that comes with BIND 9 is likely to produce a substantially more random key, so we recommend you use that one even if you are not using BIND 9 as your DNS server. If you are using BIND 9's dnssec-keygen, the above key would be created as follows:
dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
That documentation is correct (you should generate your own key using dnssec-keygen) but the mechanism only works if the client machine sends its hostname to the DHCP server. This is why I mentioned the use of send host-name in my post.
Oh yeah I did update that part as well but all but one of my machines are windows machines. I think something is really screwy with my dns because I also have a site-to-site vpn to my office (I work from home) and I cannot resolve any of the dns entries for the office computers either, I added those dns servers to the vpn tunnel properties.
I suggest trying to debug your DNS separate from any VPN integration.
I use dynamic DNS updates on my network and my Linux and Windows machines all appear in DNS correctly. Incidentally, so does my HP Photosmart printer and Nintendo Wii.
Ok now were making progress, im getting an obvious error but I don’t see why… here is the error:
Aug 12 14:39:53 nikki dhcpd: Unable to add forward map from PD-003.charnigo.lan to 192.168.0.212: bad DNS key
Aug 12 14:46:23 nikki squid: Could not determine fully qualified hostname. Please set 'visible_hostname'
Aug 12 14:59:26 nikki named[4391]: the working directory is not writable
named.conf
options {
include "/etc/named.d/forwarders.conf";
};
logging {
category queries { log_file; };
channel log_file { file "/var/log/dns" size 0M; };
category xfer-in { log_file; };
category xfer-out { log_file; };
category default { log_file; };
};
zone "0.168.192.in-addr.arp" in {
file "dyn/0.168.192.in-addr.arp";
type master;
allow-transfer { any; };
allow-update { key nikki; };
};
zone "mydomain.lan" in {
file "dyn/mydomain.lan";
type master;
allow-transfer { any; };
allow-update { key nikki; };
};
dhcpd.conf
option domain-name "mydomain.lan";
option domain-name-servers 192.168.0.1;
option routers 192.168.0.1;
option ntp-servers 192.168.0.1;
option netbios-name-servers 192.168.0.1;
default-lease-time 14400;
include "/etc/named.d//dyn_dns.key";
authoritative ;
ddns-update-style interim;
ignore client-updates;
ddns-updates on;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.200 192.168.0.254;
default-lease-time 14400;
max-lease-time 172800;
zone mydomain.lan. { primary 192.168.0.1; key nikki; }
zone 0.168.192.in-addr.arpa. { primary 192.168.0.1; key nikki; }
host babyuigi {
fixed-address 192.168.0.100;
hardware ethernet 00:00:00:00:00:00;
}
}
It looks like there’s a permissions problem on the working directory. That should be easily fixed.
I see you include the dynamic dns update key in dhcpd.conf but it doesn’t appear to be defined in named.conf. This might explain the error relating to the bad DNS key or did you leave that out of your post for security reasons?
Wow well now I feel dumb, I included the file and it WORKED! In one direction. I also changed the directory permission to chmod g+w named and cleared up that error. Cleared the squid error. now I get this error:
Aug 13 04:10:58 nikki dhcpd: unable to add reverse map from 211.0.168.192.in-addr.arpa. to mininikki.mydomain.lan: not authorized
I used YaST to configure the servers, seems there is a bug where it doesn’t include the key file in named.conf, but the above doesn’t make sense, both the zones look the same to me the forward/reverse.
Thanks.
There’s a typo error in named.conf for your reverse zone.
You have zone “0.168.192.in-addr.arp” in {
file “dyn/0.168.192.in-addr.arp”;
It should be zone “0.168.192.in-addr.arpa” in {
file “dyn/0.168.192.in-addr.arpa”;
Actually, you can name the zone file whatever you like but conventionally it is named the same as the zone.
Is there a way to force a client to update the reverse zone, I am still receiving sporadic errors from named that the directory is not writable, but I do not see any other errors after making the change you suggested. However doing a dig by ip does not return results out of the reverse zone.
Thanks,
Dan
Check your configuation and named directory/file structure for agreement.
A DHCP-triggered update should update both the forward and reverse zone by creating A and TXT records in the forward zone and PTR records in the reverse zone.
There is no point in just updating one of the forward or reverse zones because the DNS would not be consistent.
Thanks for all the help everything seems to be working fine now, sure was an experience.