rndc-key has expired

[Mark Andrews]

In message <1300893881.12273.67.camel at localhost.localdomain>, "fakessh @" write
s:
> I use and bind  rndc and dlv isc for dnssec=20
> my zone config like this
> 
> 
> zone "renelacroute.fr" {
>         type master;
>         file "/var/named/renelacroute.fr.hosts";
>         auto-dnssec maintain;
>         update-policy local;
>         key-directory "/var/named/keys/";
>         allow-transfer {  213.251.*.*;87.98.*.*; 195.234.*.*;94.23.*.\
> *; 193.223.*.*; };
>         };
> 
> 
> and my log dnssec it is
> 23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
> has expired
> 23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
> has expired
> 23-Mar-2011 16:18:18.244 dnssec: debug 2: tsig key 'rndc-key': signature
> has expired
> 
> 
> I can not use the script to validate the answers (for dnssec ) I isc

RNDC, TSIG and DNSSEC are *different* things. 

TSIG is a transaction signature and by default it is valid for 5
minutes (tsig.fudge) from when it is computed.  TSIG can be used
on zone transfers and to secure individual DNS transactions.  The
format of TSIG log messages is "tsig key '%s': %s" and "tsig key
'%s' (%s): %s".  TSIG uses HMAC with private keys or it can use
public key cyptograhy similar to DNSSEC.

The DNS server and client being out of time sync can generate the
above messages.  A slow TSIG signed zone transfer can also generate
the messages above even when the server and client are in sync if
it takes more than 5 minutes to send the signed messages in the
axfr/ixfr stream to the client.

RNDC, uses HMAC (private keys).  It shares hmac keys with TSIG but
passes the expiry values differently.  The format of its log messages
is "invalid command from %s: %s"

The above messages are not rndc related.

DNSSEC uses RRSIGs and they are valid for 30 days by default.  DNSSEC
secures records in the transaction, not the transaction itself.  You
have a secure transaction if all the components of the transaction are
secure and otherwise sensible.

The above messages are not DNSSEC related.  The message below are
DNSSEC related.

Mark

> SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
> 5.814:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
> 5.814:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
> 5.814:INFO Total answers: 3
> 5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164
> 5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232
> 5.816:SUCCESS All DNSKEY responses are identical.
> 5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D62721 flags=3D256 alg=3DRSASHA1
> AwEAAb20...UzDMzFplHk=3D
> 5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
> 5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D48793 flags=3D257 alg=3DRSASHA1
> AwEAAbj7...WFfCkn7o38=3D
> 5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
> 5.822:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
> 5.822:INFO VERIFY-DNSKEY: 0 keys found after filtering.
> 5.822:DEBUG VERIFY-DNSKEY: Using keys:
> 5.822:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
> 5.822:FAILURE VERIFY-DNSKEY: No keys found after filtering.
> 5.822:FAILURE DNSKEY signature did not validate.
> 5.822:FINAL_FAILURE FAILURE
> 
> 
> Le mercredi 23 mars 2011 =C3=A0 09:29 +0100, Eivind Olsen a =C3=A9crit :
> > > I edit the file named.conf
> > > modification
> > > update-policy {
> > >         grant * self * A TXT;
> > >     };
> > > to update-policy local;
> > > it seems more logical.
> > > but I'm still stuck on the validation of isc dlv. the script tells me
> > > lost keys
> >=20
> > Which script? What exactly does it say?
> >=20
> > I'm guessing you might have enabled dynamic updates in a DNSSEC signed
> > zone, without BIND having access to the private keys needed to sign, but
> > that's a wild guess really.
> >=20
> > Regards
> > Eivind Olsen
> >=20
> >=20
> --=20
> gpg --keyserver pgp.mit.edu --recv-key 092164A7
> http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x092164A7
> 
> --=-nHmVHAZDpObhKURw8YiG
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: Ceci est une partie de message
> 	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> 
> iD8DBQBNihC5tXI/OwkhZKcRAq2dAJ0SsEztSh/rgrKCYyo3JerXzjsOxgCggvQv
> 5jISvLMReyxov6dURql1lw0=
> =e9RP
> -----END PGP SIGNATURE-----
> 
> --=-nHmVHAZDpObhKURw8YiG--
> 
> 
> --===============8954482665668778810==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============8954482665668778810==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org