From kaustubh.gadkari at gmail.com Fri Feb 3 23:46:53 2012 From: kaustubh.gadkari at gmail.com (Kaustubh Gadkari) Date: Fri, 3 Feb 2012 16:46:53 -0700 Subject: [ldns-users] Key name to be used in ldns_pkt_tsig_verify Message-ID: Hi, I am trying to verify the tsig of a packet that I have received from a client. For the shared key, I use a key generated with dnssec-keygen. At my server side, I read the this key into an ldns_key structure using ldns_key_new_frm_fp() function. I want to use this key to verify the packet's tsig using the ldns_pkt_tsig_verify() function. This function asks for the key name, which I tried to get using the ldns_key_get_file_base_name(), but I get an assertion error for rd != 0. What is the correct way to get the key name and key mac to use with the ldns_pkt_tsig_verify() function? Thanks, Kaustubh -- Kaustubh Gadkari From Willem at NLnetLabs.nl Mon Feb 13 15:23:17 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 13 Feb 2012 16:23:17 +0100 Subject: [ldns-users] Key name to be used in ldns_pkt_tsig_verify In-Reply-To: References: Message-ID: <4F392AE5.6000600@NLnetLabs.nl> Hi Kaustubh, Sorry for my late response. If you are reading the with dnssec-keygen -n HOST generated K++.private file with ldns_key_new_frm_fp then there is no way to set the name of the key (which is the part of the filename b.t.w.) because it is simply not in the file content. Also, it is rather cumbersome to extract even the keyname: ldns_key* key; size_t i = ldns_key_hmac_size(key); ldns_rdf* b64_bignum = ldns_rdf_new_frm_data( LDNS_RDF_TYPE_B64, i , ldns_key_hmac_key(key)); char* keyname = ldns_rdf2str(b64_bignum); Maybe it would be more convenient to read the K++.key file in stead with ldns_key_new_frm_fp. keyname and keydata can then simply be extracted with: ldns_rr* key_rr; char* keyname = ldns_rdf2str(ldns_rr_owner(key_rr)); char* keydata = ldns_rdf2str(ldns_rr_rdf(key_rr, 3)); Good luck! -- Willem Op 04-02-12 00:46, Kaustubh Gadkari schreef: > Hi, > > I am trying to verify the tsig of a packet that I have received from a > client. For the shared key, I use a key generated with dnssec-keygen. > At my server side, I read the this key into an ldns_key structure > using ldns_key_new_frm_fp() function. I want to use this key to verify > the packet's tsig using the ldns_pkt_tsig_verify() function. This > function asks for the key name, which I tried to get using the > ldns_key_get_file_base_name(), but I get an assertion error for rd != > 0. > > What is the correct way to get the key name and key mac to use with > the ldns_pkt_tsig_verify() function? > > Thanks, > Kaustubh > > > -- > Kaustubh Gadkari > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From kaustubh.gadkari at gmail.com Tue Feb 14 16:30:46 2012 From: kaustubh.gadkari at gmail.com (Kaustubh Gadkari) Date: Tue, 14 Feb 2012 09:30:46 -0700 Subject: [ldns-users] Key name to be used in ldns_pkt_tsig_verify In-Reply-To: <4F392AE5.6000600@NLnetLabs.nl> References: <4F392AE5.6000600@NLnetLabs.nl> Message-ID: On Mon, Feb 13, 2012 at 8:23 AM, Willem Toorop wrote: > Hi Kaustubh, > > Sorry for my late response. If you are reading the with > dnssec-keygen -n HOST > generated > K++.private > file with ldns_key_new_frm_fp then there is no way to set the name of > the key (which is the part of the filename b.t.w.) because it is > simply not in the file content. > > Also, it is rather cumbersome to extract even the keyname: > > ldns_key* key; > > size_t i = ldns_key_hmac_size(key); > ldns_rdf* b64_bignum = ldns_rdf_new_frm_data( LDNS_RDF_TYPE_B64, i > , ldns_key_hmac_key(key)); > char* keyname = ldns_rdf2str(b64_bignum); > > Maybe it would be more convenient to read the K++.key > file in stead with ldns_key_new_frm_fp. keyname and keydata can then > simply be extracted with: > > ldns_rr* key_rr; > How would I populate this rr? Thanks, Kaustubh > > char* keyname = ldns_rdf2str(ldns_rr_owner(key_rr)); > char* keydata = ldns_rdf2str(ldns_rr_rdf(key_rr, 3)); > > Good luck! > > -- Willem > > Op 04-02-12 00:46, Kaustubh Gadkari schreef: > > Hi, > > > > I am trying to verify the tsig of a packet that I have received from a > > client. For the shared key, I use a key generated with dnssec-keygen. > > At my server side, I read the this key into an ldns_key structure > > using ldns_key_new_frm_fp() function. I want to use this key to verify > > the packet's tsig using the ldns_pkt_tsig_verify() function. This > > function asks for the key name, which I tried to get using the > > ldns_key_get_file_base_name(), but I get an assertion error for rd != > > 0. > > > > What is the correct way to get the key name and key mac to use with > > the ldns_pkt_tsig_verify() function? > > > > Thanks, > > Kaustubh > > > > > > -- > > Kaustubh Gadkari > > _______________________________________________ > > ldns-users mailing list > > ldns-users at open.nlnetlabs.nl > > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users > -- Kaustubh Gadkari -------------- next part -------------- An HTML attachment was scrubbed... URL: From Willem at NLnetLabs.nl Tue Feb 14 20:17:48 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 14 Feb 2012 21:17:48 +0100 Subject: [ldns-users] Key name to be used in ldns_pkt_tsig_verify In-Reply-To: References: <4F392AE5.6000600@NLnetLabs.nl> Message-ID: <4F3AC16C.3060702@NLnetLabs.nl> Op 14-02-12 17:30, Kaustubh Gadkari schreef: > ldns_rr* key_rr; > > How would I populate this rr? Well, lets say you created a shared key for TSIG transactions for the example.com domain with: dnssec-keygen -a HMAC-MD5 -b 128 -n HOST examples.com This creates two files: Kexamples.com.+157+16702.key Kexamples.com.+157+16702.private Reading the keyfile and extracting the keyname and keydata: ldns_rr* key_rr; char *keyname, *keydata; FILE* fp = fopen("Kexamples.com.+157+16702.key", "r"); if ( ldns_rr_new_frm_fp(&key_rr, fp, NULL, NULL, NULL) == LDNS_STATUS_OK && ldns_rr_rd_count(rr) >= 4) { /* keyname will be "example.com." */ keyname = ldns_rdf2str(ldns_rr_owner(rr)); keydata = ldns_rdf2str(ldns_rr_rdf(rr, 3)); /* * Code that uses ldns_pkt_tsig_verify(), * but it is probably easier to use a ldns_resolver. */ LDNS_FREE(keyname); LDNS_FREE(keydata); } Good luck! -- Willem From peter.van.dijk at netherlabs.nl Thu Feb 23 12:44:14 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Thu, 23 Feb 2012 13:44:14 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification Message-ID: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> Hello, in the 1.6.12 Changelog I see: * Canonicalize the signers name rdata field in RRSIGs when signing It appears the same change has not been applied to verification. This patch fixes validation of results with mixed case signers for me: --- a/host2wire.c +++ b/host2wire.c @@ -205,7 +205,7 @@ ldns_rrsig2buffer_wire(ldns_buffer *buffer, const ldns_rr *rr) /* Convert all the rdfs, except the actual signature data * rdf number 8 - the last, hence: -1 */ for (i = 0; i < ldns_rr_rd_count(rr) - 1; i++) { - (void) ldns_rdf2buffer_wire(buffer, ldns_rr_rdf(rr, i)); + (void) ldns_rdf2buffer_wire_canonical(buffer, ldns_rr_rdf(rr, i)); } return ldns_buffer_status(buffer); I also suspect that this (untested) patch would make ldns more in line with dnssec-bis-16: --- a/host2wire.c +++ b/host2wire.c @@ -113,6 +113,7 @@ ldns_rr2buffer_wire_canonical(ldns_buffer *buffer, case LDNS_RR_TYPE_SRV: case LDNS_RR_TYPE_DNAME: case LDNS_RR_TYPE_A6: + case LDNS_RR_TYPE_RRSIG: pre_rfc3597 = true; break; default: Please let me know what you think. Kind regards, Peter van Dijk From Willem at NLnetLabs.nl Tue Feb 28 13:18:22 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 28 Feb 2012 14:18:22 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> Message-ID: <4F4CD41E.8010103@NLnetLabs.nl> Hi Peter, First of all; Thanks for diving in so deep! Then; Sorry for the late response, but those are subtle issues. I interpret draft-ietf-dnsext-dnssec-bis-updates-16 section-5.1 such that the RDATA section of RRSIG (The Signer's Name field) should be downcased for ordering and signing. Thus not specifically for verifying. If a signer produces (against the very *recent* directive) an RRSIG with an mixed case "Signer's Name" a verifier should be able to validate that too. Though, I do agree that the downcased "Signer's name" should be tried to validate also. A contribution that would do just that would be great! :) (but if you don't I will of course :) Also I believe that signers following the new directive put a lowercased "Signer's Name" in the RRSIG RDATA. Is this not the case? How did you produce the validation failure? Was it from a situation in the wild? -- Willem From miek at miek.nl Tue Feb 28 14:29:54 2012 From: miek at miek.nl (Miek Gieben) Date: Tue, 28 Feb 2012 15:29:54 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <4F4CD41E.8010103@NLnetLabs.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> <4F4CD41E.8010103@NLnetLabs.nl> Message-ID: <20120228142954.GA28123@miek.nl> [ Quoting at 14:18 on Feb 28 in "Re: [ldns-users] can..." ] > Hi Peter, > > First of all; Thanks for diving in so deep! > > Then; Sorry for the late response, but those are subtle issues. > I interpret draft-ietf-dnsext-dnssec-bis-updates-16 section-5.1 such > that the RDATA section of RRSIG (The Signer's Name field) should be > downcased for ordering and signing. Thus not specifically for verifying. > > If a signer produces (against the very *recent* directive) an RRSIG with > an mixed case "Signer's Name" a verifier should be able to validate that > too. Though, I do agree that the downcased "Signer's name" should be > tried to validate also. > > A contribution that would do just that would be great! :) > (but if you don't I will of course :) > > Also I believe that signers following the new directive put a lowercased > "Signer's Name" in the RRSIG RDATA. Is this not the case? How did you > produce the validation failure? Was it from a situation in the wild? I think: dig +dnssec nic.us DS sums it up nicely. My Go code validates pretty much everything, except signatures from that domain (.US) :( So we have the old spec, the new spec and stuff in the wild... grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From miek at miek.nl Tue Feb 28 14:29:54 2012 From: miek at miek.nl (Miek Gieben) Date: Tue, 28 Feb 2012 15:29:54 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <4F4CD41E.8010103@NLnetLabs.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> <4F4CD41E.8010103@NLnetLabs.nl> Message-ID: <20120228142954.GA28123@miek.nl> [ Quoting at 14:18 on Feb 28 in "Re: [ldns-users] can..." ] > Hi Peter, > > First of all; Thanks for diving in so deep! > > Then; Sorry for the late response, but those are subtle issues. > I interpret draft-ietf-dnsext-dnssec-bis-updates-16 section-5.1 such > that the RDATA section of RRSIG (The Signer's Name field) should be > downcased for ordering and signing. Thus not specifically for verifying. > > If a signer produces (against the very *recent* directive) an RRSIG with > an mixed case "Signer's Name" a verifier should be able to validate that > too. Though, I do agree that the downcased "Signer's name" should be > tried to validate also. > > A contribution that would do just that would be great! :) > (but if you don't I will of course :) > > Also I believe that signers following the new directive put a lowercased > "Signer's Name" in the RRSIG RDATA. Is this not the case? How did you > produce the validation failure? Was it from a situation in the wild? I think: dig +dnssec nic.us DS sums it up nicely. My Go code validates pretty much everything, except signatures from that domain (.US) :( So we have the old spec, the new spec and stuff in the wild... grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wouter at nlnetlabs.nl Tue Feb 28 15:59:19 2012 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Tue, 28 Feb 2012 16:59:19 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <20120228142954.GA28123@miek.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> <4F4CD41E.8010103@NLnetLabs.nl> <20120228142954.GA28123@miek.nl> Message-ID: <4F4CF9D7.2000406@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Miek, On 02/28/2012 03:29 PM, Miek Gieben wrote: > [ Quoting at 14:18 on Feb 28 in "Re: > [ldns-users] can..." ] >> Hi Peter, >> >> First of all; Thanks for diving in so deep! >> >> Then; Sorry for the late response, but those are subtle issues. I >> interpret draft-ietf-dnsext-dnssec-bis-updates-16 section-5.1 >> such that the RDATA section of RRSIG (The Signer's Name field) >> should be downcased for ordering and signing. Thus not >> specifically for verifying. Yes it does mean verifying. This is because this is what deployed software (at first, BIND, then after .US got signed, soon, unbound too) does. ldns verify still implemented the standard, but with the fix that it creates lowercase signer-names, thus the canonicalisation became immaterial. Now, dnssec-bis-updates has caught up and is moving to RFC and indeed ldns verify should implement the proper verification. But we wanted to be careful with implementing not-yet-RFC, but this now creates trouble with powerDNS. So, the we intend to lowercase signer-names in ldns in canonicalisation (and also in verification and signing), as well as keep the compatibility lowercase generation of signernames that makes the issue immaterial for signatures created by ldns. >> If a signer produces (against the very *recent* directive) an >> RRSIG with an mixed case "Signer's Name" a verifier should be >> able to validate that too. Though, I do agree that the downcased >> "Signer's name" should be tried to validate also. >> >> A contribution that would do just that would be great! :) (but if >> you don't I will of course :) >> >> Also I believe that signers following the new directive put a >> lowercased "Signer's Name" in the RRSIG RDATA. Is this not the >> case? How did you produce the validation failure? Was it from a >> situation in the wild? > > I think: > > dig +dnssec nic.us DS > > sums it up nicely. > > My Go code validates pretty much everything, except signatures from > that domain (.US) :( You must downcase the signername (implement dnssec-bis-updates). > So we have the old spec, the new spec and stuff in the wild... Yes BIND used to implement SIG where the signername was compressible and thus has to be downcased. Then moved to RRSIG but that code was left in there. And thus unbound changed, and ldns changed it rrsig-generation. And now its back for ldns verify (of signatures that it did not create itself - I think that most signers out there generate backwards compatible RRSIGs) :-) Check HINFO and NSEC too. (see dnssec-bis-updates). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPTPnXAAoJEJ9vHC1+BF+Nc34P/ib3qXhkKOCK4p1njBvLXi3E W+cd9Ga91ZfyZW9W+Ky2IAPkHfX1VAsz+3qQ1G3wp30cajHOBnZ95S3tQqqzprlR 6EKc8m+UU4w+4JmNC/GQ7Zj1WHFm8tVtf3w9m1ThU7KPUhHg4TsxeTtO+kD0Ya2q Rfpc5dhSXrXs0JN5bhd/zky8KLVPXpG+r3tLmwBJpq1se5O1+uY/eOlnCZsBWM2E b3KKUoyrT0qvyG2z+RaJXY31a5R9PrLuZQehPZ7hBL34RkjJyboQLWUXiiFsPWL8 rw2w69sVJDjlhYQAYxAwTLc0xQrUnXgOnw4I1bMe1D30sg9/BX/D1w+3frUbvCgy t9KSDS+nDKU9GbLPj1kgEWjNgat8ewPPQaai//7bmjzwOqDI0g2Q/wMmORJpIf+T Oe8azQrocTbOHIDOKsSWCwB4CocPYzEOkl2C5RRVcR/wxjtte5oD6g1E47x0cB95 sL2kzP9DAie9Gzsrfu/ZB+gHOECkFntkzDV4dEcEaQvMjHnaWaxuaJl+2D4xKbuE LNSc0LVfBGU9D+F2P4EGrBqCDwVQbf7OYXHSY8N8F/QNSPdZ6+fAghTM5Kas2fEr A8XNhgLj5dWNJhqwibkE8ndajF/goLhj7BuyS/IzBs3eSY9jcKMSuDHcpr5CFyT4 gxognDH3bUX6y4KiiUE3 =UdB5 -----END PGP SIGNATURE----- From Willem at NLnetLabs.nl Tue Feb 28 16:24:34 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Tue, 28 Feb 2012 17:24:34 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <4F4CF9D7.2000406@nlnetlabs.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> <4F4CD41E.8010103@NLnetLabs.nl> <20120228142954.GA28123@miek.nl> <4F4CF9D7.2000406@nlnetlabs.nl> Message-ID: <4F4CFFC2.7070400@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK. Good point. We can't have ldns validate successfully things that wont be validated by a bind or unbound resolver. Therefor, Peter, thanks for you patch. Committed :) - -- Willem Op 28-02-12 16:59, W.C.A. Wijngaards schreef: > Hi Miek, > > On 02/28/2012 03:29 PM, Miek Gieben wrote: >> [ Quoting at 14:18 on Feb 28 in "Re: >> [ldns-users] can..." ] >>> Hi Peter, >>> >>> First of all; Thanks for diving in so deep! >>> >>> Then; Sorry for the late response, but those are subtle issues. >>> I interpret draft-ietf-dnsext-dnssec-bis-updates-16 >>> section-5.1 such that the RDATA section of RRSIG (The Signer's >>> Name field) should be downcased for ordering and signing. Thus >>> not specifically for verifying. > > Yes it does mean verifying. This is because this is what deployed > software (at first, BIND, then after .US got signed, soon, unbound > too) does. > > ldns verify still implemented the standard, but with the fix that > it creates lowercase signer-names, thus the canonicalisation > became immaterial. Now, dnssec-bis-updates has caught up and is > moving to RFC and indeed ldns verify should implement the proper > verification. But we wanted to be careful with implementing > not-yet-RFC, but this now creates trouble with powerDNS. So, the > we intend to lowercase signer-names in ldns in canonicalisation > (and also in verification and signing), as well as keep the > compatibility lowercase generation of signernames that makes the > issue immaterial for signatures created by ldns. > >>> If a signer produces (against the very *recent* directive) an >>> RRSIG with an mixed case "Signer's Name" a verifier should be >>> able to validate that too. Though, I do agree that the >>> downcased "Signer's name" should be tried to validate also. >>> >>> A contribution that would do just that would be great! :) (but >>> if you don't I will of course :) >>> >>> Also I believe that signers following the new directive put a >>> lowercased "Signer's Name" in the RRSIG RDATA. Is this not the >>> case? How did you produce the validation failure? Was it from >>> a situation in the wild? > >> I think: > >> dig +dnssec nic.us DS > >> sums it up nicely. > >> My Go code validates pretty much everything, except signatures >> from that domain (.US) :( > > You must downcase the signername (implement dnssec-bis-updates). > >> So we have the old spec, the new spec and stuff in the wild... > > Yes BIND used to implement SIG where the signername was > compressible and thus has to be downcased. Then moved to RRSIG but > that code was left in there. And thus unbound changed, and ldns > changed it rrsig-generation. And now its back for ldns verify (of > signatures that it did not create itself - I think that most > signers out there generate backwards compatible RRSIGs) :-) > > Check HINFO and NSEC too. (see dnssec-bis-updates). > > Best regards, Wouter > _______________________________________________ ldns-users mailing > list ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPTP/CAAoJEOX4+CEvd6SYM4IP/iJynBCtKhaRXNmrTvHlefCk hTo9XdgOF/wDDisKx12+w+bXms4V35FgID4duOkIXEeLEyGT2yJuuDHouDJVPxi3 jaF9lI2ZukKUtINcKqYeVoOc0pXO0Gs3OA7XHFi16Qgjn1DmoEHGIy59vQ8V7wds pFmtmUm70b+SsbTfYcafWJFhNkb+SHFL7PVQAL2eD3HK7egLdFpgrcp9ZonKKxll SHHNXtxgum5R3G3tNfy3GWZyqmcTMwBxG9x8VuxT8M70MmKqiHEZuRcUmIDMBVhe plSeGNfGEqj4S20oYBGb/WdecyIz+ObeHdCDRZRbkh5GEFXwcaU/0P1Zhoz+vV5m //ipYnRQy+WBcXdgTzGO0HAFK0YwZLKJpAVQXE4/RcB60DyGX/XwPi81mK9bj2cq tR0iXDQ1cSbdZ6D0B9cVAgWap0ZGsCE54+/AcbRylYnpQg833WatzvztSQu87+oD s5yt8Qx2ZiOiyE/dO8hxt3j6sUKmnjoWZJh3Ux4J92oDXN/lzFhQAnkqhHpWLucJ NwEPkn/3n5VZ169WcyH3pMfEP/y3d/EFPk1ZXypd10SjwETG9+o99or47RTNdndW FqW1yy8DhJ4MWJ5b1/x5ixQcfyDn/dchIR4L0RiMYiSqa1eYXDYYcw5uDPPPc+gU XFj25Yhr0OCUpCeRpule =hJz9 -----END PGP SIGNATURE----- From peter.van.dijk at netherlabs.nl Tue Feb 28 17:04:51 2012 From: peter.van.dijk at netherlabs.nl (Peter van Dijk) Date: Tue, 28 Feb 2012 18:04:51 +0100 Subject: [ldns-users] canonical signer name in RRSIG during verification In-Reply-To: <4F4CF9D7.2000406@nlnetlabs.nl> References: <328403F6-992B-4CA5-9D00-B800557D8C17@netherlabs.nl> <4F4CD41E.8010103@NLnetLabs.nl> <20120228142954.GA28123@miek.nl> <4F4CF9D7.2000406@nlnetlabs.nl> Message-ID: <3C6D6628-72B4-4795-B9CC-0019297EEC67@netherlabs.nl> Hello, On Feb 28, 2012, at 16:59 , W.C.A. Wijngaards wrote: > But we wanted to be careful with implementing not-yet-RFC, but this > now creates trouble with powerDNS. So, the we intend to lowercase > signer-names in ldns in canonicalisation (and also in verification and > signing), as well as keep the compatibility lowercase generation of > signernames that makes the issue immaterial for signatures created by > ldns. To improve compatibility with old LDNS, and perhaps any other validators that do not lowercase for verification, PowerDNS 3.1 (which is due for release very soon) will lowercase signer name during RRSIG generation (just like LDNS). Kind regards, Peter van Dijk