tsig verify failure

Bob Vance bobvance at alumni.caltech.edu
Sun Apr 8 11:53:57 UTC 2001


You could set up 'ssh' on your server and create an account for those 2
guys.

Then, instead of their doing a direct 'nsupdate' from their systems,
they would do a remote command that would actually cause you to run
'nsupdate' locally, so time difference wouldn't be a problem.  Something
like:

(friend1-sys)# ssh friend1 at maximo  do_it_to_it 1.2.3.7

You may have to play with permissions to allow do_it_to_it to be able to
invoke 'nsupdate' or maybe set them up as root users.

Or, do_it_to_it could just create a file that a root 'cron' job looks
for and does the 'nsupdate'.

Or set up a login/Web access/cgi-bin/SSL thingy to allow them to do it.


-------------------------------------------------
Tks        | <mailto:BVance at sbm.com>
BV         | <mailto:BobVance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Maximo Ramos
Sent: Sunday, April 08, 2001 6:22 AM
To: BIND
Subject: tsig verify failure



Hi

I have been working all day in this DDNS ... works like a charm, but
only locally :(

named[24526]: adding an RR
named[24526]: delete all rrsets from a name
named[24526]: adding an RR

However, a remote host in Canada (I am in South Korea) is trying to
use nsupdate with *the same key* and the same arguments I use locally,
but:

named[24526]: client X.X.X.X#1073: request has invalid signature: tsig
verify failure

I searched in the mailing list archives and found:

> Have you checked that the clocks on the client and server are
> synchronised? TSIGs include a timestamp to reduce the potential for
> replay attacks. If the client and server's clocks are out by too
> much, TSIG validation fails.

Of course the time is different!!!! I am trying to allow two friends
in Canada and Finland to update my domain zone, and they DONT have NS
servers, nor static IP addresses. They are just dumb clients.

Is there any workaround??

BTW, after I implemented views and some other stuff, in my syslogd
(Linux 2.4.2) the entries concerning named have a weird time, like
this:

Apr  8 10:04:48 sputnik named[24526]:
Apr  8 10:06:19 sputnik named[24526]:
Apr  8 19:12:31 sputnik proftpd[24580]:
Apr  8 19:13:28 sputnik proftpd[24582]:
Apr  8 19:13:31 sputnik PAM_pwdb[24582]:

Here there are more, after a restart of named:

Apr  8 10:17:47 sputnik named[24526]: shutting down
Apr  8 10:17:47 sputnik named[24526]: no longer listening on
Apr  8 10:17:47 sputnik named[24526]: no longer listening on
Apr  8 10:17:47 sputnik named[24526]: no longer listening on
Apr  8 10:17:47 sputnik named[24524]: exiting
Apr  8 19:17:47 sputnik named: named shutdown succeeded
       ^^^^^^^^

Apr  8 10:17:48 sputnik named[24626]: starting BIND 9.1.1 -t
/chroot/named -u
Apr  8 10:17:48 sputnik named[24626]: using 1 CPU
Apr  8 10:17:48 sputnik named[24628]: loading configuration from
Apr  8 10:17:48 sputnik named[24628]: no IPv6 interfaces found
Apr  8 10:17:48 sputnik named[24628]: listening on IPv4 interface
Apr  8 10:17:48 sputnik named[24628]: listening on IPv4 interface
Apr  8 10:17:48 sputnik named[24628]: listening on IPv4 interface
Apr  8 10:17:48 sputnik named[24628]: running
Apr  8 19:17:48 sputnik named: named startup succeeded
       ^^^^^^^^

This is the weirdest thing I have ever seen!

Best regards!

--
----------------------------------------------------
Maximo Ramos
>From The Land of The Morning Calm
"I am free of prejudices. I hate everyone equally."
----------------------------------------------------




More information about the bind-users mailing list