From jkomissa at cisco.com Mon Aug 2 20:52:52 2010 From: jkomissa at cisco.com (Jan Komissar (jkomissa)) Date: Mon, 2 Aug 2010 15:52:52 -0500 Subject: [ldns-users] Question about drill -T Message-ID: <76230786E2D2DB4D8949546E2215156B014A7414@XMB-RCD-214.cisco.com> Hi, I have ldns 1.6.5 and was trying to use drill to follow the trust chain from root to org. and I got (slightly reformatted): (my root-anchors.txt only has the root DS key from data.iana.org) $ drill -k anchors/root-anchors.txt -TD org. NS ;; Number of trusted keys: 1 ;; Domain: . ;; Signature ok but no chain to a trusted key or ds record [S] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} Checking if signing key is trusted: New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i k2dwY/JiBIpV+EhKZV7LccxN c6Qlj467QjHQ3Fgm2i2LE9w6 LqPFDSng5qVq1OYFyTBt3DQp pqDnAPriTwW5qIQNDNFv34yo 63sAdBeU4G9tv7dzT5sPyAgm Vh5HDCe+6XM2+Iel1+kUKCel 8Icy19hR ;{id = 41248 (zsk), size = 1024b} Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 446702e54a1607371607a1a4 1855200fd2ce1cdde32f24e8 fb5 ; xidep-pybec-tyvak- zonag-kesud-vohip-cumul- fysuk-bivac-pubam-hugeb- buzud-symes-tylaf-dosog- vufor-huxax [S] org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a80446567b6 9f634da078f0d90f01ba ;; Domain: org. ;; Signature ok but no chain to a trusted key or ds record [S] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} [S] org. 86400 IN NS a0.org.afilias-nst.info. org. 86400 IN NS a2.org.afilias-nst.info. org. 86400 IN NS b0.org.afilias-nst.org. org. 86400 IN NS b2.org.afilias-nst.org. org. 86400 IN NS c0.org.afilias-nst.info. org. 86400 IN NS d0.org.afilias-nst.org. ;;[S] self sig OK; [B] bogus; [T] trusted And I noticed that it couldn't chain to a trusted key. So I took a look at the code in drill/securetrace.c:do_secure_trace(), and found that it doesn't insert the trusted keys from the command line into the list of trusted DS RRs before it tries to verify the root. So I added the following code: /* Add all preset trusted DS signatures to the list of trusted DS RRs. */ for (j = 0; j < ldns_rr_list_rr_count(trusted_keys); j++) { ldns_rr* one_rr = ldns_rr_list_rr(trusted_keys, j); if (ldns_rr_get_type(one_rr) == LDNS_RR_TYPE_DS) { ldns_rr_list_push_rr(trusted_ds_rrs, ldns_rr_clone(one_rr)); } } after the trusted_ds_rrs list has been initialized. Now I get the following results: $ drill -k anchors/root-anchors.txt -TD org. NS ;; Number of trusted keys: 1 ;; Domain: . [T] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} Checking if signing key is trusted: New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i k2dwY/JiBIpV+EhKZV7LccxN c6Qlj467QjHQ3Fgm2i2LE9w6 LqPFDSng5qVq1OYFyTBt3DQp pqDnAPriTwW5qIQNDNFv34yo 63sAdBeU4G9tv7dzT5sPyAgm Vh5HDCe+6XM2+Iel1+kUKCel 8Icy19hR ;{id = 41248 (zsk), size = 1024b} Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 446702e54a1607371607a1a4 1855200fd2ce1cdde32f24e8 fb5 ; xidep-pybec-tyvak- zonag-kesud-vohip-cumul- fysuk-bivac-pubam-hugeb- buzud-symes-tylaf-dosog- vufor-huxax Trusted key: . 86400 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC 6Ia7gEzahOR+9W29euxhJhVV LOyQbSEW0O8gcCjFFVQUTf6v 58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9V nMVDxP/VHL496M/QZxkjf5/E fucp2gaDX6RS6CXpoY68LsvP VjR0ZSwzz1apAzvN9dlzEheX 7ICJBBtuA6G3LQpzW5hOA2hz CTMjJPJ8LbqF6dsV6DoBQzgu l0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8 ONGcLmqrAmRLKBP1dfwhYB4N 7knNnulqQxA+Uk1ihz0= ;{id = 19036 (ksk), size = 2048b} Trusted key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9 MlgUxS0ik2dwY/JiBIpV+EhK ZV7LccxNc6Qlj467QjHQ3Fgm 2i2LE9w6LqPFDSng5qVq1OYF yTBt3DQppqDnAPriTwW5qIQN DNFv34yo63sAdBeU4G9tv7dz T5sPyAgmVh5HDCe+6XM2+Iel 1+kUKCel8Icy19hR ;{id = 41248 (zsk), size = 1024b} Key is now trusted! [T] org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a804465 67b69f634da078f0d90f01ba org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 ;; Domain: org. [T] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} [T] org. 86400 IN NS b0.org.afilias-nst.org. org. 86400 IN NS a0.org.afilias-nst.info. org. 86400 IN NS a2.org.afilias-nst.info. org. 86400 IN NS b2.org.afilias-nst.org. org. 86400 IN NS d0.org.afilias-nst.org. org. 86400 IN NS c0.org.afilias-nst.info. ;;[S] self sig OK; [B] bogus; [T] trusted where the data is trusted all the way. Now, my question is if this is the correct way to solve this problem. Another way of solving this is to put the root DNSKEY in the root-anchors.txt file, although in the unbound "Howto enable DNSSEC" article (http://unbound.net/documentation/howto_anchor.html), it shows only DS records in the anchor files. And I think drill should be able to work with only DS records in the trust anchors. Any comments? Thanks, Jan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthijs at NLnetLabs.nl Thu Aug 5 14:47:31 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Thu, 05 Aug 2010 16:47:31 +0200 Subject: [ldns-users] Question about drill -T In-Reply-To: <76230786E2D2DB4D8949546E2215156B014A7414@XMB-RCD-214.cisco.com> References: <76230786E2D2DB4D8949546E2215156B014A7414@XMB-RCD-214.cisco.com> Message-ID: <4C5ACF03.1040803@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Well actually, the documentation does say that the file given with -k should contain a DNSKEY :). But, I agree that with drill should be able to work with DS records in the trust anchor file. I have committed your change to the trunk. Best regards, Matthijs On 08/02/2010 10:52 PM, Jan Komissar (jkomissa) wrote: > Hi, > > I have ldns 1.6.5 and was trying to use* drill* to follow the trust > chain from root to org. and I got (slightly reformatted): > > (my root-anchors.txt only has the root DS key from data.iana.org) > > $ drill -k anchors/root-anchors.txt -TD org. NS > > ;; Number of trusted keys: 1 > > ;; Domain: . > > *****;; Signature ok but no chain to a trusted key or ds record* > > [S] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} > > . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} > > Checking if signing key is trusted: > > New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i > > k2dwY/JiBIpV+EhKZV7LccxN > > c6Qlj467QjHQ3Fgm2i2LE9w6 > > LqPFDSng5qVq1OYFyTBt3DQp > > pqDnAPriTwW5qIQNDNFv34yo > > 63sAdBeU4G9tv7dzT5sPyAgm > > Vh5HDCe+6XM2+Iel1+kUKCel > > 8Icy19hR > ;{id > = 41248 > > (zsk), > size > = 1024b} > > Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 > > 446702e54a1607371607a1a4 > > 1855200fd2ce1cdde32f24e8 > > fb5 > ; xidep-pybec-tyvak- > > zonag-kesud-vohip-cumul- > > fysuk-bivac-pubam-hugeb- > > buzud-symes-tylaf-dosog- > > vufor-huxax > > [S] org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 > > org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a80446567b6 > > 9f634da078f0d90f01ba > > ;; Domain: org. > > ;; Signature ok but no chain to a trusted key or ds record > > [S] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} > > org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} > > [S] org. 86400 IN NS a0.org.afilias-nst.info. > > org. 86400 IN NS a2.org.afilias-nst.info. > > org. 86400 IN NS b0.org.afilias-nst.org. > > org. 86400 IN NS b2.org.afilias-nst.org. > > org. 86400 IN NS c0.org.afilias-nst.info. > > org. 86400 IN NS d0.org.afilias-nst.org. > > ;;[S] self sig OK; [B] bogus; [T] trusted > > And I noticed that it couldn?t chain to a trusted key. So I took a look > at the code in drill/securetrace.c:do_secure_trace(), and found that it > doesn?t insert the trusted keys from the command line into the list of > trusted DS RRs before it tries to verify the root. So I added the > following code: > > /* Add all preset trusted DS signatures to the list of trusted DS R_Rs._ */ > > *****for* (j = 0; j < ldns_rr_list_rr_count(trusted_keys); j++) { > > ldns_rr* one_rr = ldns_rr_list_rr(trusted_keys, j); > > ***** if* (ldns_rr_get_type(one_rr) ==///// LDNS_RR_TYPE_DS/) { > > ldns_rr_list_push_rr(trusted_ds_rrs, ldns_rr_clone(one_rr)); > > } > > } > > after the trusted_ds_rrs list has been initialized. Now I get the > following results: > > $ drill -k anchors/root-anchors.txt -TD org. NS > > ;; Number of trusted keys: 1 > > ;; Domain: . > > [T] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} > > . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} > > Checking if signing key is trusted: > > New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i > > k2dwY/JiBIpV+EhKZV7LccxN > > c6Qlj467QjHQ3Fgm2i2LE9w6 > > LqPFDSng5qVq1OYFyTBt3DQp > > pqDnAPriTwW5qIQNDNFv34yo > > 63sAdBeU4G9tv7dzT5sPyAgm > > Vh5HDCe+6XM2+Iel1+kUKCel > > 8Icy19hR > ;{id > = 41248 > > (zsk), > size > = 1024b} > > Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 > > 446702e54a1607371607a1a4 > > 1855200fd2ce1cdde32f24e8 > > fb5 > ; xidep-pybec-tyvak- > > zonag-kesud-vohip-cumul- > > fysuk-bivac-pubam-hugeb- > > buzud-symes-tylaf-dosog- > > vufor-huxax > > Trusted key: . 86400 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC > > 6Ia7gEzahOR+9W29euxhJhVV > > LOyQbSEW0O8gcCjFFVQUTf6v > > 58fLjwBd0YI0EzrAcQqBGCzh > > /RStIoO8g0NfnfL2MTJRkxoX > > bfDaUeVPQuYEhg37NZWAJQ9V > > nMVDxP/VHL496M/QZxkjf5/E > > fucp2gaDX6RS6CXpoY68LsvP > > VjR0ZSwzz1apAzvN9dlzEheX > > 7ICJBBtuA6G3LQpzW5hOA2hz > > CTMjJPJ8LbqF6dsV6DoBQzgu > > l0sGIcGOYl7OyQdXfZ57relS > > Qageu+ipAdTTJ25AsRTAoub8 > > ONGcLmqrAmRLKBP1dfwhYB4N > > 7knNnulqQxA+Uk1ihz0= > > > ;{id > = 19036 > (ksk), > size > > = > 2048b} > > Trusted key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9 > > MlgUxS0ik2dwY/JiBIpV+EhK > > ZV7LccxNc6Qlj467QjHQ3Fgm > > 2i2LE9w6LqPFDSng5qVq1OYF > > yTBt3DQppqDnAPriTwW5qIQN > > DNFv34yo63sAdBeU4G9tv7dz > > T5sPyAgmVh5HDCe+6XM2+Iel > > 1+kUKCel8Icy19hR > ;{id > = > > 41248 > (zsk), > size > = 1024b} > > *****Key is now trusted!* > > [T] org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a804465 > > 67b69f634da078f0d90f01ba > > org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 > > ;; Domain: org. > > [T] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} > > org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} > > [T] org. 86400 IN NS b0.org.afilias-nst.org. > > org. 86400 IN NS a0.org.afilias-nst.info. > > org. 86400 IN NS a2.org.afilias-nst.info. > > org. 86400 IN NS b2.org.afilias-nst.org. > > org. 86400 IN NS d0.org.afilias-nst.org. > > org. 86400 IN NS c0.org.afilias-nst.info. > > ;;[S] self sig OK; [B] bogus; [T] trusted > > where the data is trusted all the way. Now, my question is if this is > the correct way to solve this problem. Another way of solving this is to > put the root DNSKEY in the root-anchors.txt file, although in the > unbound ?Howto enable DNSSEC? article > (_http://unbound.net/documentation/howto_anchor.html_), it shows only DS > records in the anchor files. And I think drill should be able to work > with only DS records in the trust anchors. > > Any comments? > > Thanks, > > Jan. > > > > _______________________________________________ > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWs8CAAoJEA8yVCPsQCW5LmcH/i6+y2e5ltwukrznCPCN4pr1 Q/rW8AqPGEV9BergKolqhcpqlJZNtGX4t2FasbdxuMhRc/jYx9DAz7H8z294B6py 9lPJVfgetSKMnqW/v3oiZq5mNbF5Fkf6JZGuaPS3jJPvvBTe2QZqEqebHwYj4vj0 s8yivzSL7kMK3pOChVfardKMCVgdPE9KAsN0TDtDf7cqPFdN2vosp1G0JVFqlCJg 7jjga4nXa1R6iDnm5gKuMVCK0nZbPAKxY1+5X46DfWHActospM1IgpgWlMmE5cH8 qZzBHAqkb4HeMZ+b4BwGkNTKCGxi+XbC7g2rUqy2uyOBrHeN/SR5KFdw37SKtyg= =hUgD -----END PGP SIGNATURE----- From jkomissa at cisco.com Thu Aug 5 15:57:24 2010 From: jkomissa at cisco.com (Jan Komissar (jkomissa)) Date: Thu, 5 Aug 2010 10:57:24 -0500 Subject: [ldns-users] Question about drill -T In-Reply-To: <4C5ACF03.1040803@nlnetlabs.nl> References: <76230786E2D2DB4D8949546E2215156B014A7414@XMB-RCD-214.cisco.com> <4C5ACF03.1040803@nlnetlabs.nl> Message-ID: <76230786E2D2DB4D8949546E2215156B01530C5D@XMB-RCD-214.cisco.com> Hi Matthijs, It turns out that "drill -h" and "man drill" have slightly different documentation of "-k": drill -h ========= -k specify a file that contains a trusted DNSSEC key [**] used to verify any signatures in the current answer man drill ========== -k keyfile Use this file to read a (trusted) key from. When this options is given drill tries to validate the current answer with this key. No chasing is done. When drill is doing a secure trace, this key will be used as trust anchor. That's what happens when there are two sources of data.... All the best, Jan. -----Original Message----- From: Matthijs Mekking [mailto:matthijs at NLnetLabs.nl] Sent: Thursday, August 05, 2010 10:48 AM To: Jan Komissar (jkomissa) Cc: ldns-users at open.nlnetlabs.nl Subject: Re: [ldns-users] Question about drill -T -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jan, Well actually, the documentation does say that the file given with -k should contain a DNSKEY :). But, I agree that with drill should be able to work with DS records in the trust anchor file. I have committed your change to the trunk. Best regards, Matthijs On 08/02/2010 10:52 PM, Jan Komissar (jkomissa) wrote: > Hi, > > I have ldns 1.6.5 and was trying to use* drill* to follow the trust > chain from root to org. and I got (slightly reformatted): > > (my root-anchors.txt only has the root DS key from data.iana.org) > > $ drill -k anchors/root-anchors.txt -TD org. NS > > ;; Number of trusted keys: 1 > > ;; Domain: . > > *****;; Signature ok but no chain to a trusted key or ds record* > > [S] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} > > . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} > > Checking if signing key is trusted: > > New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i > > k2dwY/JiBIpV+EhKZV7LccxN > > c6Qlj467QjHQ3Fgm2i2LE9w6 > > LqPFDSng5qVq1OYFyTBt3DQp > > pqDnAPriTwW5qIQNDNFv34yo > > 63sAdBeU4G9tv7dzT5sPyAgm > > Vh5HDCe+6XM2+Iel1+kUKCel > > 8Icy19hR > ;{id > = 41248 > > (zsk), > size > = 1024b} > > Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 > > 446702e54a1607371607a1a4 > > 1855200fd2ce1cdde32f24e8 > > fb5 > ; xidep-pybec-tyvak- > > zonag-kesud-vohip-cumul- > > fysuk-bivac-pubam-hugeb- > > buzud-symes-tylaf-dosog- > > vufor-huxax > > [S] org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 > > org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a80446567b6 > > 9f634da078f0d90f01ba > > ;; Domain: org. > > ;; Signature ok but no chain to a trusted key or ds record > > [S] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} > > org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} > > [S] org. 86400 IN NS a0.org.afilias-nst.info. > > org. 86400 IN NS a2.org.afilias-nst.info. > > org. 86400 IN NS b0.org.afilias-nst.org. > > org. 86400 IN NS b2.org.afilias-nst.org. > > org. 86400 IN NS c0.org.afilias-nst.info. > > org. 86400 IN NS d0.org.afilias-nst.org. > > ;;[S] self sig OK; [B] bogus; [T] trusted > > And I noticed that it couldn't chain to a trusted key. So I took a look > at the code in drill/securetrace.c:do_secure_trace(), and found that it > doesn't insert the trusted keys from the command line into the list of > trusted DS RRs before it tries to verify the root. So I added the > following code: > > /* Add all preset trusted DS signatures to the list of trusted DS R_Rs._ */ > > *****for* (j = 0; j < ldns_rr_list_rr_count(trusted_keys); j++) { > > ldns_rr* one_rr = ldns_rr_list_rr(trusted_keys, j); > > ***** if* (ldns_rr_get_type(one_rr) ==///// LDNS_RR_TYPE_DS/) { > > ldns_rr_list_push_rr(trusted_ds_rrs, ldns_rr_clone(one_rr)); > > } > > } > > after the trusted_ds_rrs list has been initialized. Now I get the > following results: > > $ drill -k anchors/root-anchors.txt -TD org. NS > > ;; Number of trusted keys: 1 > > ;; Domain: . > > [T] . 86400 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} > > . 86400 IN DNSKEY 256 3 8 ;{id = 41248 (zsk), size = 1024b} > > Checking if signing key is trusted: > > New key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9MlgUxS0i > > k2dwY/JiBIpV+EhKZV7LccxN > > c6Qlj467QjHQ3Fgm2i2LE9w6 > > LqPFDSng5qVq1OYFyTBt3DQp > > pqDnAPriTwW5qIQNDNFv34yo > > 63sAdBeU4G9tv7dzT5sPyAgm > > Vh5HDCe+6XM2+Iel1+kUKCel > > 8Icy19hR > ;{id > = 41248 > > (zsk), > size > = 1024b} > > Trusted key: . 3600 IN DS 19036 8 2 49aac11d7b6f6 > > 446702e54a1607371607a1a4 > > 1855200fd2ce1cdde32f24e8 > > fb5 > ; xidep-pybec-tyvak- > > zonag-kesud-vohip-cumul- > > fysuk-bivac-pubam-hugeb- > > buzud-symes-tylaf-dosog- > > vufor-huxax > > Trusted key: . 86400 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC > > 6Ia7gEzahOR+9W29euxhJhVV > > LOyQbSEW0O8gcCjFFVQUTf6v > > 58fLjwBd0YI0EzrAcQqBGCzh > > /RStIoO8g0NfnfL2MTJRkxoX > > bfDaUeVPQuYEhg37NZWAJQ9V > > nMVDxP/VHL496M/QZxkjf5/E > > fucp2gaDX6RS6CXpoY68LsvP > > VjR0ZSwzz1apAzvN9dlzEheX > > 7ICJBBtuA6G3LQpzW5hOA2hz > > CTMjJPJ8LbqF6dsV6DoBQzgu > > l0sGIcGOYl7OyQdXfZ57relS > > Qageu+ipAdTTJ25AsRTAoub8 > > ONGcLmqrAmRLKBP1dfwhYB4N > > 7knNnulqQxA+Uk1ihz0= > > > ;{id > = 19036 > (ksk), > size > > = > 2048b} > > Trusted key: . 86400 IN DNSKEY 256 3 8 AwEAAb1gcDhBlH/9 > > MlgUxS0ik2dwY/JiBIpV+EhK > > ZV7LccxNc6Qlj467QjHQ3Fgm > > 2i2LE9w6LqPFDSng5qVq1OYF > > yTBt3DQppqDnAPriTwW5qIQN > > DNFv34yo63sAdBeU4G9tv7dz > > T5sPyAgmVh5HDCe+6XM2+Iel > > 1+kUKCel8Icy19hR > ;{id > = > > 41248 > (zsk), > size > = 1024b} > > *****Key is now trusted!* > > [T] org. 172800 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a804465 > > 67b69f634da078f0d90f01ba > > org. 172800 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 > > ;; Domain: org. > > [T] org. 900 IN DNSKEY 256 3 7 ;{id = 61970 (zsk), size = 1024b} > > org. 900 IN DNSKEY 256 3 7 ;{id = 52197 (zsk), size = 1024b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} > > org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} > > [T] org. 86400 IN NS b0.org.afilias-nst.org. > > org. 86400 IN NS a0.org.afilias-nst.info. > > org. 86400 IN NS a2.org.afilias-nst.info. > > org. 86400 IN NS b2.org.afilias-nst.org. > > org. 86400 IN NS d0.org.afilias-nst.org. > > org. 86400 IN NS c0.org.afilias-nst.info. > > ;;[S] self sig OK; [B] bogus; [T] trusted > > where the data is trusted all the way. Now, my question is if this is > the correct way to solve this problem. Another way of solving this is to > put the root DNSKEY in the root-anchors.txt file, although in the > unbound "Howto enable DNSSEC" article > (_http://unbound.net/documentation/howto_anchor.html_), it shows only DS > records in the anchor files. And I think drill should be able to work > with only DS records in the trust anchors. > > Any comments? > > Thanks, > > Jan. > > > > _______________________________________________ > 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMWs8CAAoJEA8yVCPsQCW5LmcH/i6+y2e5ltwukrznCPCN4pr1 Q/rW8AqPGEV9BergKolqhcpqlJZNtGX4t2FasbdxuMhRc/jYx9DAz7H8z294B6py 9lPJVfgetSKMnqW/v3oiZq5mNbF5Fkf6JZGuaPS3jJPvvBTe2QZqEqebHwYj4vj0 s8yivzSL7kMK3pOChVfardKMCVgdPE9KAsN0TDtDf7cqPFdN2vosp1G0JVFqlCJg 7jjga4nXa1R6iDnm5gKuMVCK0nZbPAKxY1+5X46DfWHActospM1IgpgWlMmE5cH8 qZzBHAqkb4HeMZ+b4BwGkNTKCGxi+XbC7g2rUqy2uyOBrHeN/SR5KFdw37SKtyg= =hUgD -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Mon Aug 9 09:51:14 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 09 Aug 2010 11:51:14 +0200 Subject: [ldns-users] ldns 1.6.6 released Message-ID: <4C5FCF92.3030900@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, ldns 1.6.6 is out. It's a bugfix release. See below for the Changelog. You can download it at: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.6.tar.gz sha1sum: d9615d6d0021ec35fb089635cba6401bc87ac962 Enjoy! Best regards, Matthijs Changelog 1.6.6 * Fix ldns_rr_clone to copy question rrs properly. * Fix ldns_sign_zone(_nsec3) to clone the soa for the new zone. * Fix ldns_wire2dname size check from reading 1 byte beyond buffer end. * Fix ldns_wire2dname from reading 1 byte beyond end for pointer. * Fix crash using GOST for particular platform configurations. * extern C declarations used in the header file. * Removed debug fprintf from resolver.c. * ldns-signzone checks if public key file is for the right zone. * NETLDNS, .NET port of ldns functionality, by Alex Nicoll, in contrib. * Fix handling of comments in resolv.conf parse. * GOST code enabled if SSL recent, RFC 5933. * bugfix #317: segfault util.c ldns_init_random() fixed. * Fix ldns_tsig_mac_new: allocate enough memory for the hash, fix use of b64_pton_calculate_size. * Fix ldns_dname_cat: size calculation and handling of realloc(). * Fix ldns_rr_pop_rdf: fix handling of realloc(). * Fix ldns-signzone for single type key scheme: sign whole zone if there are only KSKs. * Fix ldns_resolver: also close socket if AXFR failed (if you don't, it would block subsequent transfers (thanks Roland van Rijswijk). * Fix drill: allow for a secure trace if you use DS records as trust anchors (thanks Jan Komissar). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMX8+SAAoJEA8yVCPsQCW5yUQIAMBkiQ+8O1Lx6hy+YE3jUDOA 2IEKJq3cKNUGt0qFm9NCMP1V8ZVVzRbbKXdHJ+LbEl1H6BbIKgOtAN9/CBn+z1oy fVdAVkRoajzbzDRNMARHjuZatkHE/OwaVCdjjvEvWJuJTLaP3GO0eCh6asnmgdgM 6gvwiqrXcCAFBKRIjStxu3AekMW/P4t0DVqyQCaMm75MB55hV1VbjkuOZh6k0VJ2 Vd2a29uRYCZdH0JQ4wTnK0hWstOCnYYXkZ2qT3hIFUCHO8i2pkmx7ovyH6SynIhY 0cJ9bqCnRnTc56hZc6BI74T3/TTwfsL32+pyP+VXgcstARUi7Ns10cjY8EtQFWA= =GyCD -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Mon Aug 9 09:51:22 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 09 Aug 2010 11:51:22 +0200 Subject: [ldns-users] ldns 1.6.6 released Message-ID: <4C5FCF9A.4070007@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, ldns 1.6.6 is out. It's a bugfix release. See below for the Changelog. You can download it at: http://www.nlnetlabs.nl/downloads/ldns/ldns-1.6.6.tar.gz sha1sum: d9615d6d0021ec35fb089635cba6401bc87ac962 Enjoy! Best regards, Matthijs Changelog 1.6.6 * Fix ldns_rr_clone to copy question rrs properly. * Fix ldns_sign_zone(_nsec3) to clone the soa for the new zone. * Fix ldns_wire2dname size check from reading 1 byte beyond buffer end. * Fix ldns_wire2dname from reading 1 byte beyond end for pointer. * Fix crash using GOST for particular platform configurations. * extern C declarations used in the header file. * Removed debug fprintf from resolver.c. * ldns-signzone checks if public key file is for the right zone. * NETLDNS, .NET port of ldns functionality, by Alex Nicoll, in contrib. * Fix handling of comments in resolv.conf parse. * GOST code enabled if SSL recent, RFC 5933. * bugfix #317: segfault util.c ldns_init_random() fixed. * Fix ldns_tsig_mac_new: allocate enough memory for the hash, fix use of b64_pton_calculate_size. * Fix ldns_dname_cat: size calculation and handling of realloc(). * Fix ldns_rr_pop_rdf: fix handling of realloc(). * Fix ldns-signzone for single type key scheme: sign whole zone if there are only KSKs. * Fix ldns_resolver: also close socket if AXFR failed (if you don't, it would block subsequent transfers (thanks Roland van Rijswijk). * Fix drill: allow for a secure trace if you use DS records as trust anchors (thanks Jan Komissar). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMX8+aAAoJEA8yVCPsQCW5/XsIAJJdcs8d+2S364okQu3ALD6F J/OSAGLojJsyGooNkXN0wgFrdQt8pDMgHv9DLf0fzSMhg9zglKaelA6T1xOOO2qv DFuXu82sI8N3HPNrWfUU3gdbIo9ir/P4G/heUfv2hNDp2iGbVaVCpXdtvw4oNpui e+dQC8jd0X3BaB9bGTZQeHSzxeD10CNu32DqEbXQGHmwL2/bbnfrtqtisI1zPzu6 fNCi/ic5gnKRHjGd+D84q3ZkVmIMJlO7bhgJbht/eb5ifGCAYuud908X2eVTPEe9 4LkNVZCJCO0WttoD36zuezuLkQsfZKs4qx4yB16hTbBoJoYUzDv+UVZhMwtou3A= =VSw5 -----END PGP SIGNATURE----- From pete.mccann at motorola.com Mon Aug 16 22:31:23 2010 From: pete.mccann at motorola.com (McCann Peter-A001034) Date: Mon, 16 Aug 2010 18:31:23 -0400 Subject: [ldns-users] Can ldns be used asynchronously? Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> If I use ldns as a resolver library, can I perform asynchronous queries, and have multiple outstanding queries simultaneously? Thanks, -Pete From wouter at NLnetLabs.nl Tue Aug 17 06:57:48 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 17 Aug 2010 08:57:48 +0200 Subject: [ldns-users] Can ldns be used asynchronously? In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> References: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> Message-ID: <4C6A32EC.3000303@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pete, Not unless you code it yourself. Libunbound http://unbound.net/documentation/libunbound-tutorial-4.html can do asynchronous queries. Best regards, Wouter On 08/17/2010 12:31 AM, McCann Peter-A001034 wrote: > If I use ldns as a resolver library, can I perform > asynchronous queries, and have multiple outstanding > queries simultaneously? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqMuwACgkQkDLqNwOhpPgsSQCdEVWiV2Rc64/v0Lxklu2Farc/ RX4An0ukCH824BV0qmm/euHxjNgpANXG =qml2 -----END PGP SIGNATURE----- From henri at asseily.com Tue Aug 17 08:26:35 2010 From: henri at asseily.com (Henri Asseily) Date: Tue, 17 Aug 2010 11:26:35 +0300 Subject: [ldns-users] Can ldns be used asynchronously? In-Reply-To: <4C6A32EC.3000303@nlnetlabs.nl> References: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> <4C6A32EC.3000303@nlnetlabs.nl> Message-ID: <889CB097-96D9-4F48-9B8C-90D54FFF15A4@asseily.com> On the iPhone I do multiple queries by instantiating a resolver for each thread, and it works perfectly. On Aug 17, 2010, at 9:57 AM, W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Pete, > > Not unless you code it yourself. Libunbound > http://unbound.net/documentation/libunbound-tutorial-4.html can do > asynchronous queries. > > Best regards, > Wouter > > On 08/17/2010 12:31 AM, McCann Peter-A001034 wrote: >> If I use ldns as a resolver library, can I perform >> asynchronous queries, and have multiple outstanding >> queries simultaneously? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxqMuwACgkQkDLqNwOhpPgsSQCdEVWiV2Rc64/v0Lxklu2Farc/ > RX4An0ukCH824BV0qmm/euHxjNgpANXG > =qml2 > -----END PGP SIGNATURE----- > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users From pete.mccann at motorola.com Tue Aug 17 17:36:52 2010 From: pete.mccann at motorola.com (McCann Peter-A001034) Date: Tue, 17 Aug 2010 13:36:52 -0400 Subject: [ldns-users] Can ldns be used asynchronously? In-Reply-To: <4C6A32EC.3000303@nlnetlabs.nl> References: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> <4C6A32EC.3000303@nlnetlabs.nl> Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC074B00E4@de01exm70.ds.mot.com> W.C.A. Wijngaards wrote: > Not unless you code it yourself. Libunbound > http://unbound.net/documentation/libunbound-tutorial-4.html can do > asynchronous queries. Thank you, Wouter. I might switch to using libunbound. A question, though: I note that a call to ub_ctx_async sets whether to spawn a thread or fork a process. But, why do I have to do either? It seems like the file descriptor returned from ub_ctx_fd could be the UDP socket on which the library is waiting for a response packet. In that case, a call to ub_process would both read this data from the socket and perform any other processing that might be necessary. But, I guess you would also need to return a timeout value that the application would need to respect by calling ub_process at that time in case no response was received. I am just a little concerned about the overhead of spawning a thread for each lookup. -Pete From wouter at NLnetLabs.nl Wed Aug 18 07:16:02 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Wed, 18 Aug 2010 09:16:02 +0200 Subject: [ldns-users] Can ldns be used asynchronously? In-Reply-To: <274D46DDEB9F2244B2F1EA66B3FF54BC074B00E4@de01exm70.ds.mot.com> References: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> <4C6A32EC.3000303@nlnetlabs.nl> <274D46DDEB9F2244B2F1EA66B3FF54BC074B00E4@de01exm70.ds.mot.com> Message-ID: <4C6B88B2.8010809@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, No it spawns one thread that is associated with the context. The call you talk about it for configuration what the context should do, and is not used by most users (I think). The thread stays present until you delete the context, and keeps a cache for example. Best regards, Wouter On 08/17/2010 07:36 PM, McCann Peter-A001034 wrote: > W.C.A. Wijngaards wrote: >> Not unless you code it yourself. Libunbound >> http://unbound.net/documentation/libunbound-tutorial-4.html can do >> asynchronous queries. > > > Thank you, Wouter. I might switch to using libunbound. > > A question, though: I note that a call to ub_ctx_async > sets whether to spawn a thread or fork a process. But, > why do I have to do either? It seems like the file > descriptor returned from ub_ctx_fd could be the UDP > socket on which the library is waiting for a response > packet. In that case, a call to ub_process would both > read this data from the socket and perform any other > processing that might be necessary. But, I guess you > would also need to return a timeout value that the > application would need to respect by calling ub_process > at that time in case no response was received. > > I am just a little concerned about the overhead of > spawning a thread for each lookup. > > -Pete -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxriLIACgkQkDLqNwOhpPjqnwCfcpQkZXP1DX/zlDOrJMUaSGcA dIkAmgN1Xwqi0D3dKvrtzTk2f52tlxor =+kui -----END PGP SIGNATURE----- From pete.mccann at motorola.com Wed Aug 18 14:34:39 2010 From: pete.mccann at motorola.com (McCann Peter-A001034) Date: Wed, 18 Aug 2010 10:34:39 -0400 Subject: [ldns-users] Can ldns be used asynchronously? In-Reply-To: <4C6B88B2.8010809@nlnetlabs.nl> References: <274D46DDEB9F2244B2F1EA66B3FF54BC074AFCBF@de01exm70.ds.mot.com> <4C6A32EC.3000303@nlnetlabs.nl> <274D46DDEB9F2244B2F1EA66B3FF54BC074B00E4@de01exm70.ds.mot.com> <4C6B88B2.8010809@nlnetlabs.nl> Message-ID: <274D46DDEB9F2244B2F1EA66B3FF54BC07520CD5@de01exm70.ds.mot.com> Ah, thank you, that makes much more sense. One thread per context that can be re-used concurrently for many queries sounds like an acceptable overhead. -Pete W.C.A. Wijngaards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Peter, > > No it spawns one thread that is associated with the context. The > call you talk about it for configuration what the context should do, > and is not used by most users (I think). The thread stays present > until you delete the context, and keeps a cache for example. > > Best regards, Wouter From zbynek.michl at nic.cz Thu Aug 26 09:04:16 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Thu, 26 Aug 2010 11:04:16 +0200 Subject: [ldns-users] ldns_buffer_free() function bug? Message-ID: <4C762E10.4060606@nic.cz> Hi, I have a question about ldns_buffer_free() function. Its prototype is void ldns_buffer_free(ldns_buffer *buffer); but shouldn't it be void ldns_buffer_free(ldns_buffer **buffer); (pointer to pointer)? Because using LDNS_FREE macro only memory is freed, but original pointer passed to the function remains at its original address (is not set to NULL). Currently only local copy of that pointer is set to NULL. Thanks, Zbynek From zbynek.michl at nic.cz Tue Aug 31 13:22:09 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Tue, 31 Aug 2010 15:22:09 +0200 Subject: [ldns-users] Wrong parsing of /etc/resolv.conf Message-ID: <4C7D0201.7010700@nic.cz> Hi, when resolv.conf contains resolver IPv6 link-local address with zone, ldns_resolver_new_frm_file() function cannot parse it and fails on "Syntax error, could not parse the RR". My resolv.conf looks like this: nameserver fe80::222:19ff:fe31:4222%eth0 Regards, Zbynek From hsalgado at nic.cl Tue Aug 31 19:41:00 2010 From: hsalgado at nic.cl (Hugo Salgado) Date: Tue, 31 Aug 2010 15:41:00 -0400 Subject: [ldns-users] drill doesn't validate NSEC3 nxdomain? Message-ID: <4C7D5ACC.4020105@nic.cl> Hi. I want to use "drill -k" to validate correctness of a nsec3 chain signature, for a nxdomain response. If I put the .org keys in a file and then validate a DS record, it works: % drill -D -k ORG.KSK @a0.org.afilias-nst.info. ds ietf.org. [ ... ] ; VALIDATED by id = 52197, owner = org. But when I try to validate non-existence: % drill -D -k ORG.KSK @a0.org.afilias-nst.info. ds aaaaietf.org. [ ... ] ; Bad data; RR for name and type not found or failed to verify, and denial of existence failed. The same command for a NSEC zone is working: % drill -D -k ROOT.KEY @g.root-servers.net. ds sssse. [ ... ] ; Existence denied for sssse. DS I'm using drill version 1.6.6 (ldns version 1.6.6). Thanks and regards, Hugo