nsupdate fails with tsig error.
Glenn Satchell
Glenn.Satchell at uniq.com.au
Sun Dec 2 12:00:53 UTC 2007
One other thing I thought of. Can you snoop/tcpdump/wireshark the
traffic for a UDP and a TCP nsupdate onthe dns server? This might give
usa clue about other settings in the packet that are relevant.
regards,
-glenn
>Date: Sun, 2 Dec 2007 22:56:04 +1100 (EST)
>From: Glenn Satchell <Glenn.Satchell at uniq.com.au>
>Subject: Re: nsupdate fails with tsig error.
>
>>To: dhcp-users at isc.org
>>Subject: Re: nsupdate fails with tsig error.
>>Date: Sat, 1 Dec 2007 23:27:38 -0800
>>From: Anthony Ercolano <tony-keyword-dhcp.537659 at ercolano.com>
>>
>>Sorry for the multiple messages.
>
>That's ok. This is as tricky problem and we're finally starting to
>close in on the details.
>
>>Is there any way to force the DHCP server to only use TCP when sending
>>updates to the dns server?
>
>You could always hack the source. That may or may not be an easy or
>necessarily desirable thing to do...
>
>So let's summarise and see where we are:
>
>nsupdate from real IP using presumably udp works
>
>nsupdate from nat IP (10.x.x.x) using udp fails
>
>nsupdate from nat IP (10.x.x.x) using tcp works
>
>So, the key side of things is sorted out, since the command works in
>two locations. So we can eliminate the key settings in named.conf as a
>source of error.
>
>The issue seems to be when the key goes via UDP and NAT. Are there any
>NAT settings on the router where it is trying to be "helpful" in some
>way? Eg, rewriting dns requests or something similar. What type of
>router is it?
>
>regards,
>-glenn
>
>>On Dec 1, 2007, at 10:39 PM, Anthony Ercolano wrote:
>>
>>> Interestingly if I force nsupdate to commuicate with tcp instead of
>>> udp by using the -v option then the update works even if the update
>>> is requested from the machine at address 10.0.0.37 and going through
>>> NAT.
>>>
>>> On Dec 1, 2007, at 5:10 PM, Anthony Ercolano wrote:
>>>
>>>> Life becomes much more clear.
>>>>
>>>> If I run nsupdate on a machine with a network address of 10.0.0.37
>>>> and it sends the update commands to the bind server with a network
>>>> address 209.181.88.209 the update fails.
>>>>
>>>> If I take the same machine and give it a network address of
>>>> 209.181.88.213 and run the same series of commands with nsupdate
>>>> the update succeeds.
>>>>
>>>> Clearly I don't understand the ramifications of sending the update
>>>> through NAT to the server.
>>>>
>>>> Any thoughts?
>>>>
>>>> On Dec 1, 2007, at 8:43 AM, Glenn Satchell wrote:
>>>>
>>>>>
>>>>>> To: dhcp-users at isc.org
>>>>>> Subject: Re: nsupdate fails with tsig error.
>>>>>> Date: Fri, 30 Nov 2007 10:00:49 -0800
>>>>>>
>>>>>> I have made several changes to make the dhcpd.conf and the
>>>>>> named.conf
>>>>>> match more closely what is is the man page. Results are exactly
>>>>>> the
>>>>>> same.
>>>>>>
>>>>>> Question:
>>>>>>
>>>>>> In order to reduce possible configuration file "noise", on the
>>>>>> machine
>>>>>> that has the dhcp server I am testing out doing the dns update
>>>>>> using
>>>>>> the nsupdate program that comes with bind.
>>>>>>
>>>>>> So - Does the nsupdate program use ANY information from the
>>>>>> dhcpd.conf
>>>>>> (or any other settings external to what is given in the sequence of
>>>>>> comands) at all?
>>>>>
>>>>> No. nsupdateis part of the bind package, it has absolutely no
>>>>> dependancies on
>>>>> dhcp or indeed any knowledge of the dhcp package of programmes.
>>>>>
>>>>>> Trying to do the update via nsupdate on the dhcp server machine, it
>>>>>> fails with BADSIG
>>>>>>
>>>>>> Again, here is where I am puzzled: Using the EXACT same sequence
>>>>>> of
>>>>>> command to nsupdate on the bind server, the update works.
>>>>>>
>>>>>> I really wouldn't have thought it mattered at all where the
>>>>>> nsupdate
>>>>>> came from.
>>>>>>
>>>>>> This leads me to think that there MUST be something in by
>>>>>> named.conf
>>>>>> file that is letting "local" updates occur but is preventing non-
>>>>>> local. However, I just don't see what that might be.
>>>>>
>>>>> Yes. That is a good assumption.
>>>>>
>>>>>> Is there any default cryptographic information that is assumed on
>>>>>> the
>>>>>> bind server side that is not available to non-local clients?
>>>>>
>>>>> I don't think so.
>>>>>
>>>>> In named.conf you don't use quotes around the value of the secret,
>>>>> ie
>>>>> it should be:
>>>>>
>>>>> key ns1-dhcpsrc.ercolano.net. {
>>>>> algorithm hmac-md5;
>>>>> secret supersecretsecret==;
>>>>> };
>>>>>
>>>>> And in dhcpd.conf you also don't need quotes around the value of
>>>>> the secret.
>>>>>
>>>>> key ns1-dhcpsrc.ercolano.net. {
>>>>> algorithm hmac-md5;
>>>>> secret supersecretsecret==;
>>>>> };
>>>>>
>>>>> This is the only thing I can see in the included named.conf and
>>>>> dhcpd.conf files below that is not right. If this doesn't work, then
>>>>> there must be something else not right, but if there is I can't see
>>>>> it.
>>>>>
>>>>> The BIND ARM (available on the web) says about TSIG errors:
>>>>>
>>>>> If a TSIG aware server receives a message with a signature that
>>>>> does not validate, the response will be unsigned with the TSIG
>>>>> extended error code set to BADSIG.
>>>>>
>>>>> So, this says to me the key is invalid. If you use quotes in the
>>>>> conf
>>>>> files, then they will become part of the key and could cause it to
>>>>> be
>>>>> invalid as they are not valid base 64 characters.
>>>>>
>>>>> You did restart (not just kill -HUP) both dhcpd and named after
>>>>> changing the conf files? (clutching at straws here ... )
>>>>>
>>>>> regards,
>>>>> -glenn
>>>>>
>>>>>> On Nov 29, 2007, at 5:01 AM, Glenn Satchell wrote:
>>>>>>
>>>>>>> Hi Anthony
>>>>>>>
>>>>>>> Please have a look at the dhcpd.conf man page, in particular the
>>>>>>> section titled DNS UPDATE SECURITY. It has sample configurations
>>>>>>> for
>>>>>>> named.conf and dhcpd.conf. It also includes the statements to
>>>>>>> set up
>>>>>>> logging of dynamic DNS updates on the bind server.
>>>>>>>
>>>>>>> One thing to be careful with is the use of quotes. They vary
>>>>>>> between
>>>>>>> bind and dhcp for similar statements, eg zone and key.
>>>>>>>
>>>>>>> If you follow those examples closely it will work...
>>>>>>>
>>>>>>> regards,
>>>>>>> -glenn
>>>>>>>
>>>>>>>> From: Anthony Ercolano <anthony.ercolano at gmail.com>
>>>>>>>> To: dhcp-users at isc.org
>>>>>>>> Subject: nsupdate fails with tsig error.
>>>>>>>> Date: Wed, 28 Nov 2007 17:58:15 -0800
>>>>>>>>
>>>>>>>> Here is a copy of my dhcpd.conf (secrets obscured).
>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> option domain-name "ercolano.com";
>>>>>>>> option domain-name-servers 209.181.88.209,209.181.88.210;
>>>>>>>>
>>>>>>>> default-lease-time 2592000;
>>>>>>>>
>>>>>>>> ddns-update-style interim;
>>>>>>>> ddns-updates on;
>>>>>>>> ddns-domainname "ercolano.com";
>>>>>>>> ddns-rev-domainname "10.in-addr.arpa";
>>>>>>>> ignore client-updates;
>>>>>>>> authoritative;
>>>>>>>>
>>>>>>>> key ns1-dhcpsrc.ercolano.net. {
>>>>>>>> algorithm hmac-md5;
>>>>>>>> secret "supersecretsecret==";
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone 10.in-addr.arpa {
>>>>>>>> primary 209.181.88.209;
>>>>>>>> key ns1-dhcpsrc.ercolano.net.;
>>>>>>>> }
>>>>>>>>
>>>>>>>> zone ercolano.com {
>>>>>>>> primary 209.181.88.209;
>>>>>>>> key ns1-dhcpsrc.ercolano.net.;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> subnet 10.0.0.0 netmask 255.255.255.0 {
>>>>>>>> range 10.0.0.150 10.0.0.200;
>>>>>>>> option routers 10.0.0.1;
>>>>>>>> ddns-hostname =
>>>>>>>> pick ( option host-name,
>>>>>>>> concat("dhcp-",binary-to-ascii (10,8,"-",leased-
>>>>>>>> address)));
>>>>>>>>
>>>>>>>> host soekris1 {
>>>>>>>> option host-name "soekris1";
>>>>>>>> hardware ethernet 00:00:24:C4:7B:74 ;
>>>>>>>> fixed-address 10.0.0.61;
>>>>>>>> option root-path "/tftpboot";
>>>>>>>> filename "/pxeboot";
>>>>>>>> }
>>>>>>>> host soekris2 {
>>>>>>>> option host-name "soekris2";
>>>>>>>> hardware ethernet 00:00:24:C1:36:00 ;
>>>>>>>> fixed-address 10.0.0.62;
>>>>>>>> option root-path "/tftpboot";
>>>>>>>> filename "/pxeboot";
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> This dhcp server lives on an internal network address of
>>>>>>>> 10.0.0.xx
>>>>>>>>
>>>>>>>> Here is the named.conf file on 209.181.88.209
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> acl "frendsnameserver" { 192.0.0.0/24; };
>>>>>>>> acl trusted
>>>>>>>>
>>>>>
>{209.181.88.209;209.181.88.210;209.181.88.211;209.181.88.212;209.181.88.213;209
>>>>>>> .181.88.214
>>>>>>>> ;localhost;localnets;};
>>>>>>>>
>>>>>>>> key ns1-ns2.ercolano.net. {
>>>>>>>> algorithm hmac-md5;
>>>>>>>> secret "another super secret==";
>>>>>>>> };
>>>>>>>>
>>>>>>>> key ns1-dhcpsrc.ercolano.net. {
>>>>>>>> algorithm hmac-md5;
>>>>>>>> secret "supersecretsecret==";
>>>>>>>> };
>>>>>>>>
>>>>>>>> server 209.181.88.210 {
>>>>>>>> keys { ns1-ns2.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>> server 209.181.88.214 {
>>>>>>>> keys { ns1-dhcpsc.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>> options {
>>>>>>>> directory "/var/bind";
>>>>>>>>
>>>>>>>> // uncomment the following lines to turn on DNS forwarding,
>>>>>>>> // and change the forwarding ip address(es) :
>>>>>>>> //forward first;
>>>>>>>> //forwarders {
>>>>>>>> // 123.123.123.123;
>>>>>>>> // 123.123.123.123;
>>>>>>>> //};
>>>>>>>>
>>>>>>>> // listen-on-v6 { none; };
>>>>>>>> // listen-on { 127.0.0.1; };
>>>>>>>>
>>>>>>>> // to allow only specific hosts to use the DNS server:
>>>>>>>> //allow-query {
>>>>>>>> // 127.0.0.1;
>>>>>>>> //};
>>>>>>>>
>>>>>>>> allow-transfer { none; };
>>>>>>>> allow-query { any; };
>>>>>>>> allow-recursion { trusted; };
>>>>>>>> allow-query-cache { trusted; };
>>>>>>>> allow-update { none; };
>>>>>>>>
>>>>>>>> notify-source * port 53;
>>>>>>>>
>>>>>>>> // if you have problems and are behind a firewall:
>>>>>>>> query-source address * port 53;
>>>>>>>> pid-file "/var/run/named/named.pid";
>>>>>>>>
>>>>>>>> version "No";
>>>>>>>>
>>>>>>>> };
>>>>>>>>
>>>>>>>>
>>>>>>>> zone "." IN {
>>>>>>>> type hint;
>>>>>>>> file "named.ca";
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "localhost" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/localhost.zone";
>>>>>>>> notify no;
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "127.in-addr.arpa" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/127.zone";
>>>>>>>> notify no;
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "10.IN-ADDR.ARPA" {
>>>>>>>> type master;
>>>>>>>> file "pri/10.zone";
>>>>>>>> allow-update { key ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> allow-transfer { key ns1-ns2.ercolano.net.; key ns1-
>>>>>>>> dhcpsrc.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "ercolano.net" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/ercolano.net.zone";
>>>>>>>> allow-transfer { friendsnameserver; key ns1-ns2.ercolano.net.;
>>>>>>>> key
>>>>>>>> ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> };
>>>>>>>> zone "ercolano.org" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/ercolano.org.zone";
>>>>>>>> allow-transfer { friendsnameserver; key ns1-ns2.ercolano.net.;
>>>>>>>> key
>>>>>>>> ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "ercolano.com" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/ercolano.com.zone";
>>>>>>>> allow-update { key ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> allow-transfer { friendsnameserver; key ns1-ns2.ercolano.net.;
>>>>>>>> key
>>>>>>>> ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>> zone "208-214.88.181.209.in-addr.arpa" IN {
>>>>>>>> type master;
>>>>>>>> file "pri/208-214.88.181.209.zone";
>>>>>>>> allow-transfer { friendsnameserver; key ns1-ns2.ercolano.net.;
>>>>>>>> key
>>>>>>>> ns1-dhcpsrc.ercolano.net.; };
>>>>>>>> };
>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> If I execute the following nsupdate -d on the dhcp server
>>>>>>>> machine I
>>>>>>>> get:
>>>>>>>>
>>>>>>>> dhcpsrc dhcp # nsupdate -d
>>>>>>>>> server 209.181.88.209
>>>>>>>>> zone ercolano.com
>>>>>>>>> key ns1-dhcpsrc.ercolano.net. supersecretsecret==
>>>>>>>>> update add bogu.ercolano.com 300 A 10.0.0.57
>>>>>>>>> send
>>>>>>>> Sending update to 209.181.88.209#53
>>>>>>>> Outgoing update query:
>>>>>>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 40437
>>>>>>>> ;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
>>>>>>>> ;; ZONE SECTION:
>>>>>>>> ;ercolano.com. IN SOA
>>>>>>>>
>>>>>>>> ;; UPDATE SECTION:
>>>>>>>> bogu.ercolano.com. 300 IN A 10.0.0.57
>>>>>>>>
>>>>>>>> ;; TSIG PSEUDOSECTION:
>>>>>>>> ns1-dhcpsrc.ercolano.net. 0 ANY TSIG
>hmac-md5.sig-alg.reg.int.
>>>>>>>> 1196299697 300 16 hmmmmmmm== 40437 NOERROR 0
>>>>>>>>
>>>>>>>> ; TSIG error with server: tsig indicates error
>>>>>>>>
>>>>>>>> Reply from update query:
>>>>>>>> ;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 40437
>>>>>>>> ;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
>>>>>>>> ;; TSIG PSEUDOSECTION:
>>>>>>>> ns1-dhcpsrc.ercolano.net. 0 ANY TSIG
>hmac-md5.sig-alg.reg.int.
>>>>>>>> 1196299697 300 0 40437 BADSIG 0
>>>>>>>>
>>>>>>>> The error message on the bind server contains:
>>>>>>>>
>>>>>>>> Nov 28 17:43:56 mail named[24825]: client 209.181.88.214#22283:
>>>>>>>> request has invalid signature: TSIG ns1-dhcpsrc.ercolano.net:
>>>>>>>> tsig
>>>>>>>> verify failure (BADSIG)
>>>>>>>>
>>>>>>>> Any thoughts on why this doesn't work?
>>>>>>>>
>>>>>>>> Any thoughts on what sort of logging would be especially
>>>>>>>> helpful on
>>>>>>>> the bind server for finding the problem?
>>>>>>>>
>>>>>>>> Could there be issues with the fact that the dhcp request is
>>>>>>>> initiating server with nat'ed address 10.0.0.37 going through a
>>>>>>>> cisco
>>>>>>>> dsl router and coming into the bind server, which is at
>>>>>>>> 209.181.88.209
>>>>>>>> with the request appearing as though NOW initiated on address
>>>>>>>> 209.181.88.214?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the dhcp-users
mailing list