DekGenius.com
I l@ve RuBoard Previous Section Next Section

14.6 TSIG Errors

As we said in Chapter 11, transaction signatures require time synchronization and key synchronization (the same key on either end of the transaction, plus the same key name) to work. Here are a couple of errors that may arise if you lose time synchronization or use different keys or key names.

First, here's an error you'd see on a BIND 8 name server if you had configured TSIG but had too much clock skew between your primary master name server and a slave:

Sep 27 10:47:49 wormhole named[22139]: Err/TO getting serial# for "movie.edu"
Sep 27 10:47:49 wormhole named-xfer[22584]: SOA TSIG verification from server 
[192.249.249.3], zone movie.edu: message had BADTIME set (18)

Here, your name server tried to check the serial number of the movie.edu zone on terminator.movie.edu (192.249.249.3). The response from terminator.movie.edu didn't verify because wormhole.movie.edu's clock showed a time more than 10 minutes different from the time the response was signed. The Err/TO message is just a byproduct of the failure of the TSIG-signed response to verify.

If you use a different key name on either end of the transaction, even if the data the key name refers to is the same, you'll see an error like this one from your BIND 8 name server:

Sep 27 12:02:44 wormhole named-xfer[22651]: SOA TSIG verification from server 
[209.8.5.250], zone movie.edu: BADKEY(-17)

This time, the TSIG-signed response didn't check out because the verifier couldn't find a key with the name specified in the TSIG record. You'd see the same error if the key name matched but pointed to different data.

As always, BIND 9 is considerably more closed-mouthed about TSIG failure, reporting only:

Sep 27 13:35:42.804 client 192.249.249.1#1115: query: movie.edu SOA
Sep 27 13:35:42.804 client 192.249.249.1#1115: error

at debug level 3 for both of the previous scenarios.

    I l@ve RuBoard Previous Section Next Section