DHCPD issues.
~Stack~
i.am.stack at gmail.com
Thu Jan 19 12:43:49 UTC 2012
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"
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.
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.
Thanks for the help! It is much appreciated.
~Stack~
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120119/10c4f032/attachment.bin>
More information about the dhcp-users
mailing list