DHCPD issues.
Glenn Satchell
glenn.satchell at uniq.com.au
Thu Jan 19 12:54:13 UTC 2012
On 01/19/12 23:43, ~Stack~ wrote:
> On 01/19/2012 05:43 AM, Glenn Satchell wrote:
>> There are a few things wrong in a few different places. I've tried to
>> put corrections near each of the files below:
>
> Thank you for your help!
>
>> On 01/19/12 14:04, ~Stack~ wrote:
> [snip]
>>> Problem #1:
>>>
>>> When I start named/dhcpd and then boot a PXE client the client gets the
>>> proper IP but it dumps an error message that I have been unable to track
>>> down a solution for. The client is unable to determine its name so the
>>> hostname is set to "localhost" instead of its proper name (in this
>>> example it should be "aa001.project.local"). I really need to figure out
>>> what is wrong but I am stumped and I have been for a few hours now.
>>>
>>> Here is the syslog file as I boot the TFTP client.
>>>
>>> dns dhcpd: DHCPDISCOVER from 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPOFFER on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: Unable to add forward map from aa001.project.local to
>>> 172.31.202.1: connection refused
>>
>> This indicates that the key you are using for authentication does not
>> match between /etc/rndc.key and dhcpd.conf. Please check you have it
>> matching. Also make sure the syntax is correct - it is slightly
>> different between dhcpd anbd named. An example is in dhcpd.conf man page.
>>
>>> dns dhcpd: DHCPREQUEST for 172.31.202.1 (172.31.200.2) from
>>> 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPACK on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns xinetd[1773]: START: tftp pid=3470 from=172.31.202.1
>>> dns in.tftpd[3471]: tftp: client does not accept options
>>> dns dhcpd: DHCPDISCOVER from 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPOFFER on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: Unable to add forward map from aa001.project.local to
>>> 172.31.202.1: connection refused
>>> dns dhcpd: DHCPREQUEST for 172.31.202.1 (172.31.200.2) from
>>> 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPACK on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: Unable to add forward map from aa001.project.local to
>>> 172.31.202.1: connection refused
>>> dns dhcpd: DHCPREQUEST for 172.31.202.1 from 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPACK on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>>
>>> The 'solutions' I have found online for this 'connection refused' error
>>> I don't think apply to me (at least not in my limited understanding).
>>> Can someone please provide me with some input on where I may have gone
>>> wrong?
>>>
>>> Problem #2.
>>> By changing the next-server line in dhcpd.conf to
>>> next-server 127.0.0.1;
>>> from
>>> next-server 172.31.200.2;
>>> I can crash named with this error when I do a tftp boot:
>>>
>>> dns dhcpd: DHCPDISCOVER from 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPOFFER on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: Unable to add forward map from aa001.project.local to
>>> 172.31.202.1: connection refused
>>> dns dhcpd: DHCPREQUEST for 172.31.202.1 (172.31.200.2) from
>>> 08:00:27:15:bf:f5 via eth0
>>> dns dhcpd: DHCPACK on 172.31.202.1 to 08:00:27:15:bf:f5 via eth0
>>> dns xinetd[1773]: START: tftp pid=3470 from=172.31.202.1
>>> dns in.tftpd[2910]: tftp: client does not accept options
>>> dns named[2900]: failed to create new zone: already exists
>>> dns named[2900]: zone.c:1377: REQUIRE((((zone) != ((void *)0))&&
>>> (((const isc__magic_t *)(zone))->magic == ((('Z')<< 24 | ('O')<< 16 |
>>> ('N')<< 8 | ('E')))))) failed, back trace
>>> dns named[2900]: #0 0x7f56158b532f in ??
>>> dns named[2900]: #1 0x7f561428273a in ??
>>> dns named[2900]: #2 0x7f56151f960e in ??
>>> dns named[2900]: #3 0x7f560fb4890b in ??
>>> dns named[2900]: #4 0x7f560fb4c998 in ??
>>> dns named[2900]: #5 0x7f56142a0fe8 in ??
>>> dns named[2900]: #6 0x7f5613e5b7f1 in ??
>>> dns named[2900]: #7 0x7f56133ad70d in ??
>>>
>>> The fix is simply not to point tftp to localhost (dur) but I found it
>>> odd that it would tank named. I don't know why it was trying to create a
>>> new zone. This is a question for someone who knows far more about this
>>> named/dhcpd then I do.
>>
>> That looks like a bug in named, and since a remote request, no matter
>> how badly configured, should not be able to crash it. What version are
>> you running? I suspect that this would be fixed in newish releases, or
>> you have just found a security hole (congratulations if you have!)
>
> According to `rpm -qa`. I am running on Scientific Linux 6.2 (rolling).
> bind-9.7.3-8.P3.el6.x86_64
> dhcp-4.1.1-25.P1.el6_2.1.x86_64
>
> If someone wants me to run a few tests, I can as I have been able to
> reproduce this. See below.
>
>>> I would really appreciate anyone who can help me out on problem 1.
>>>
>>> Thank you.
>>>
>>> ~Stack~
>>>
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> /etc/named.conf
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> include "/etc/rndc.key";
>>> acl "project.local" { 172.31.0/16; 127.0.0.1; };
>>> controls { inet 127.0.0.1 allow { any; } keys { "rndc-key"; }; };
>>> logging {
>>> channel default_debug {
>>> file "data/named.run";
>>> severity dynamic;
>>> };
>>> };
>>> options {
>>> directory:
>>> directory "/var/named"; // the default
>>> dump-file "data/cache_dump.db";
>>> statistics-file "data/named_stats.txt";
>>> memstatistics-file "data/named_mem_stats.txt";
>>> forward first;
>>> forwarders { };
>>> // Any host is permitted to issue recursive queries
>>> allow-recursion { any; };
>>> tkey-gssapi-credential "DNS/dns.project.local";
>>> tkey-domain "PROJECT.LOCAL";
>>> };
>>> zone "project.local" {
>>> type master;
>>> file "data/project";
>>> allow-update { key rndc-key; };
>>
>> Try adding this to see if the rest of the update procedure works. If so
>> then it is a problem with the rndc-key setting - most likely the key
>> strings do not match. Same for the reverse zone too.
>>
>> allow-update { key rndc-key; 127.0.0.1; };
>
> Done.
>
>>> };
>>> zone "31.172.in-addr.arpa" {
>>> type master;
>>> file "data/project.reverse";
>>> allow-update { key rndc-key; };
>>> };
>>> dynamic-db "ipa" {
>>> library "ldap.so";
>>> arg "uri ldapi://%2fvar%2frun%2fslapd-PROJECT-LOCAL.socket";
>>> arg "base cn=dns, dc=project,dc=local";
>>> arg "fake_mname dns.project.local.";
>>> arg "auth_method sasl";
>>> arg "sasl_mech GSSAPI";
>>> arg "sasl_user DNS/dns.project.local";
>>> arg "zone_refresh 30";
>>> };
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> /var/named/data/project
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> $ORIGIN .
>>> $TTL 86400 ; 1 day
>>> project.local IN SOA dns.project.local. project.local. (
>>> 1 ; serial
>>> 86400 ; refresh (1 day)
>>> 3600 ; retry (1 hour)
>>> 604800 ; expire (1 week)
>>> 10800 ; minimum (3 hours)
>>> )
>>> NS dns.project.local.
>>> $ORIGIN project.local.
>>> $TTL 43200 ; 12 hours
>>> aa001 A 172.31.202.1
>>> TXT "0054986fe9177c6cb8eb9e8e395511b039"
>>> $TTL 86400 ; 1 day
>>> dns A 172.31.200.2
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> /var/named/data/project.reverse
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> $ORIGIN .
>>> $TTL 10800 ; 3 hours
>>> 31.172.in-addr.arpa IN SOA dns.project.local.
>>> 31.172.in-addr.arpa. (
>>> 1 ; serial
>>> 86400 ; refresh (1 day)
>>> 3600 ; retry (1 hour)
>>> 604800 ; expire (1 week)
>>> 10800 ; minimum (3 hours)
>>> )
>>> NS dns.project.local.
>>> $ORIGIN 31.172.in-addr.arpa.
>>> $TTL 43200 ; 12 hours
>>> 1.202.31.172 PTR aa001.project.local.
>>
>> This should be only the missing bits of the address, the rest of the
>> domain "31.172.in-addr.arpa" is appended. This may be a hangover fron an
>> earlier mis-configured update. Maybe just remove the line and let dhcpd
>> add it back in next time?
>>
>> 1.202 PTR aa001.project.local.
>
> Done.
>
>> Test by using
>>
>> nslookup 172.31.202.1
>
> Server: 172.31.200.2
> Address: 172.31.200.2#53
>
> 1.202.31.172.in-addr.arpa name = aa001.project.local.
>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> /etc/resolve.conf
>>
>> That should be /etc/resolv.conf - no trailing 'e'
>
> My typo in email. :-)
>
>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> search project.local
>>> nameserver 172.31.200.2
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> /etc/dhcp/dhcpd.conf
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> option domain-name "project.local";
>>> option domain-name-servers 127.0.0.1;
>>> authoritive;
>>> ddns-updates on;
>>> update-static-leases on;
>>> ddns-domainname "project.local";
>>> ddns-rev-domainname "in-addr.arpa.";
>>> ddns-update-style interim;
>>> key rndc-key {
>>> algorithm hmac-md5;
>>> secret 8VDl3xORCQlIXZvAs/UgSQ==;
>>> };
>>> zone project.local. {
>>> primary 127.0.0.1;
>>> key rndc-key;
>>> }
>>> zone 31.172.in-addr.arpa. {
>>> primary 127.0.0.1;
>>> key rndc-key;
>>> }
>>> option routers 172.31.255.254;
>>> default-lease-time 86400;
>>> max-lease-time 86400;
>>> deny unknown-clients;
>>> subnet 172.31.0.0 netmask 255.255.0.0 {}
>>> group {
>>> filename "pxelinux.0";
>>> next-server 172.31.200.2;
>>> option domain-name "project.local";
>>> host dev001 { ddns-hostname "dev001"; hardware ethernet
>>> 08:00:27:11:4B:E8; fixed-address 172.31.201.10; }
>>> host aa001 { ddns-hostname "aa001"; hardware ethernet 08:00:27:15:BF:F5;
>>> fixed-address 172.31.202.1; }
>>> host hp001 { ddns-hostname "hp001"; hardware ethernet 08:00:27:15:A3:1D;
>>> fixed-address 172.31.203.1; }
>>> }
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>
>> See how that goes now.
>>
>> regards,
>> -glenn
>
> I no longer have the "connection refused" error. That line reads "added
> reverse map from 1.202.31.172.in-addr.arpa. to aa001.project.local"
That's the expected behaviour. So that points the finger definitely at a
key probem, either a dfinition, or something doesn't match between the
two. Check dhcpd.conf man page for syntax examples.
> However, the nodes are still not picking up their name and I now get the
> exact same named crash. Even the hex values are the same.
That named crash is a serious bug. You should post to the bind-users
mailing list so that it can be fixed.
> I am not sure about the crash part, but I am going to review everything
> I have done and see if I can figure out why the nodes are not picking up
> their name.
Next steps are to use tcpdump or wireshark to do a network sniff while
the client boots, and look at what settings and options are in the dhcp
packets.
What OS are the PXE clients installing? Maybe they just work this way?
> Thanks for the help! It is much appreciated.
>
> ~Stack~
>
No problem.
regards,
-glenn
More information about the dhcp-users
mailing list