problem validate key of isc dlv

Mon Mar 21 01:13:59 UTC 2011

Yes, I bothered to redeploy new keys, fields TXT, a new signature. 
and more on a new rehabilitation isc dlv. 

I still get the same error

nb : Simply debuggers dnssec still provide all kinds of resultasts
Le lundi 21 mars 2011 à 10:58 +1100, Mark Andrews a écrit :
> In message <1300660825.6651.21.camel at localhost.localdomain>, "fakessh @" writes
> :
> > 
> > Le dimanche 20 mars 2011 =C3=A0 22:47 +0100, Torinthiel a =C3=A9crit :
> > > On 03/20/11 22:33, fakessh @ wrote:
> > > > and what do I do.=20
> > >=20
> > > You have to add your key to ISC's DLV registry. Go to dlv.isc.org,
> > > create account, login, add a zone, add keys for it and publish a record
> > > in your zone validating that you're the owner of the zone. You will be
> > > told what to do after you create zone.
> > >=20
> > 
> > that's what I did
> > I made =E2=80=8B=E2=80=8Ba post on my blog explaining how I do
> > goo.gl/EAbCB
> 
> Have you changed your DNSKEY's since you did that?  If you have did
> you update the zone in your account on dlv.isc.org?  What does
> dlv.isc.org have to say about fakessh.eu?
> 
> > > > and what is this other publication of another DS
> 
> In the end you should have a DS RRset published in the .EU zone for
> fakessh.EU.  .EU claim to implement DNSSEC and that should mean
> that you can get DS records addeded for your zone.
> 
> > > I have no idea what do you mean by this sentence.
> > > Torinthiel
> > >=20
> > > >=20
> > > >=20
> > > > Le lundi 21 mars 2011 =C3=A0 08:25 +1100, Mark Andrews a =C3=A9crit :
> > > >> In message <1300650238.6651.15.camel at localhost.localdomain>, "fakessh =
> > @" writes
> > > >> :
> > > >>> hello bind network and duru.=20
> > > >>>
> > > >>> I can not validate the key dlv via the website of the isc.=20
> > > >>> I do not understand why the warning is the isc=20
> > > >>> you have an explanation
> > > >>> SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
> > > >>> 4.502:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
> > > >>> 4.502:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
> > > >>> 4.502:INFO Total answers: 3
> > > >>> 4.503:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.=
> > 164
> > > >>> 4.504:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.=
> > 232
> > > >>> 4.504:SUCCESS All DNSKEY responses are identical.
> > > >>> 4.515:DEBUG VERIFY-DNSKEY: Checking tag=3D10231 flags=3D257 alg=3DRSA=
> > SHA1
> > > >>> AwEAAbwO...8fkjXphfS8=3D
> > > >>> 4.515:DEBUG VERIFY-DNSKEY: Ignoring key.
> > > >>> 4.515:DEBUG VERIFY-DNSKEY: Checking tag=3D30111 flags=3D256 alg=3DRSA=
> > SHA1
> > > >>> AwEAAb1q...jG+UQeAtYE=3D
> > > >>> 4.515:DEBUG VERIFY-DNSKEY: Ignoring key.
> > > >>> 4.515:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
> > > >>> 4.515:INFO VERIFY-DNSKEY: 0 keys found after filtering.
> > > >>> 4.515:DEBUG VERIFY-DNSKEY: Using keys:
> > > >>> 4.516:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
> > > >>> 4.516:FAILURE VERIFY-DNSKEY: No keys found after filtering.
> > > >>> 4.516:FAILURE DNSKEY signature did not validate.
> > > >>> 4.516:FINAL_FAILURE FAILURE
> > > >>
> > > >> Based on the key tags and the truncated keys I think these keys are
> > > >> for fakessh.eu and if so there isn't a DLV record or a DS published
> > > >> for fakessh.eu.  The only other thing the validator can check against
> > > >> is any installed trust-anchor.
> > > >>
> > > >> Mark
> > > >>
> > > >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> fakessh.eu.dlv.isc.org dlv
> > > >> ;; global options: +cmd
> > > >> ;; Got answer:
> > > >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48161
> > > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> > > >>
> > > >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> fakessh.eu ds
> > > >> ;; global options: +cmd
> > > >> ;; Got answer:
> > > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63623
> > > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> > > >>
> > > >>
> > > >>
> > > >>> --=20
> > > >>> gpg --keyserver pgp.mit.edu --recv-key 092164A7
> > > >>> http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x092164A7
> > > >>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> bind-users mailing list
> > > >>> bind-users at lists.isc.org
> > > >>> https://lists.isc.org/mailman/listinfo/bind-users
> > >=20
> > >=20
> > > _______________________________________________
> > > bind-users mailing list
> > > bind-users at lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
> > --=20
> > gpg --keyserver pgp.mit.edu --recv-key 092164A7
> > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x092164A7
> > 
> > --=-PTfCUNzbM6WN0AFHL2g3
> > 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)
> > 
> > iD8DBQBNhoJZtXI/OwkhZKcRAujMAKCIR7D4r7o+rVlue7jdtUvzrIqAbwCcD9gt
> > hw37QYLE5IuLPQXgUQI3qWc=
> > =hDB7
> > -----END PGP SIGNATURE-----
> > 
> > --=-PTfCUNzbM6WN0AFHL2g3--
> > 
> > 
> > --===============8269614476746204563==
> > 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
> > --===============8269614476746204563==--
> > 
-- 
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110321/32faf7d1/attachment.bin>