From bduff at ecessa.com Thu Sep 2 18:14:42 2010 From: bduff at ecessa.com (Bryan Duff) Date: Thu, 02 Sep 2010 13:14:42 -0500 Subject: [ldns-users] Programmatically creating a zone Message-ID: <4C7FE992.5000809@ecessa.com> As opposed to read it from a file, or from a packet. The API doesn't seem to be the best in this scenario. Is there something I'm missing? -Bryan From bduff at ecessa.com Thu Sep 2 19:21:17 2010 From: bduff at ecessa.com (Bryan Duff) Date: Thu, 02 Sep 2010 14:21:17 -0500 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> References: <4C7FE992.5000809@ecessa.com> <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> Message-ID: <4C7FF92D.1080802@ecessa.com> On 09/02/10 14:01, Ray Bellis wrote: > On 2 Sep 2010, at 19:14, Bryan Duff wrote: > >> As opposed to read it from a file, or from a packet. The API doesn't >> seem to be the best in this scenario. >> >> Is there something I'm missing? > An LDNS zone structure (ldns_zone) is nothing more than an ldns_rr* for the SOA, and an ldns_rr_list* for the records therein, and there are functions to access and modify those - see > > e.g. > > ldns_zone *z = ldns_zone_new(); > ldns_zone_set_soa(z, soa); // requires an SOA "ldns_rr*" object > ldns_zone_push_rr(z, rr); // requires other "ldns_rr*" object > > Is the real issue figuring how to create an "ldns_rr"? Yes, I think that is the main difficulty. ldns_rr_new_frm_str_internal() is what I've been looking at as the template for creating my own ldns_rr. It looks like it has all the init, and assignment code that I would need. It seems like this function is the most like what I want. > Ray > > > -Bryan From Ray.Bellis at nominet.org.uk Thu Sep 2 19:01:07 2010 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Thu, 2 Sep 2010 19:01:07 +0000 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <4C7FE992.5000809@ecessa.com> References: <4C7FE992.5000809@ecessa.com> Message-ID: <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> On 2 Sep 2010, at 19:14, Bryan Duff wrote: > As opposed to read it from a file, or from a packet. The API doesn't > seem to be the best in this scenario. > > Is there something I'm missing? An LDNS zone structure (ldns_zone) is nothing more than an ldns_rr* for the SOA, and an ldns_rr_list* for the records therein, and there are functions to access and modify those - see e.g. ldns_zone *z = ldns_zone_new(); ldns_zone_set_soa(z, soa); // requires an SOA "ldns_rr*" object ldns_zone_push_rr(z, rr); // requires other "ldns_rr*" object Is the real issue figuring how to create an "ldns_rr"? Ray From bduff at ecessa.com Thu Sep 2 20:55:55 2010 From: bduff at ecessa.com (Bryan Duff) Date: Thu, 02 Sep 2010 15:55:55 -0500 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> References: <4C7FE992.5000809@ecessa.com> <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> <4C7FF92D.1080802@ecessa.com> <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> Message-ID: <4C800F5B.8030506@ecessa.com> On 09/02/10 14:43, Ray Bellis wrote: >>> Is the real issue figuring how to create an "ldns_rr"? >> Yes, I think that is the main difficulty. >> >> ldns_rr_new_frm_str_internal() is what I've been looking at as the >> template for creating my own ldns_rr. It looks like it has all the >> init, and assignment code that I would need. >> >> It seems like this function is the most like what I want. > Well, that depends on what the source of your RRs is. > > I've used ldns_rr_new_frm_str() before (not the _internal variant): > > ldns_rr *rr; > ldns_rdf *origin = ldns_dname_new_frm_str(origin_str); > ldns_rr_new_frm_str(&rr, rr_str, ttl, origin, NULL); > > (where "origin_str" is $ORIGIN and "rr_str" is the RR in the form "@ RTYPE RDATA") Ahh, I see - that does look much simpler. As long as I create the "@ RTYPE RDATA" correctly (it's probably still much less error prone than probably duplication alot of code in the _internal function). Thanks. > Alternatively, it's possible (but tedious) to create it one field at a time: > > ldns_rr *rr = ldns_rr_new(); > ldns_rdf *owner = ldns_dname_new_frm_str(owner_str); > ldns_rr_set_owner(rr, owner); > ldns_rr_set_ttl(rr, ttl); > ldns_rr_set_type(rr, rtype); > ... > > [not sure how to set the RDATA yet, the _frm_str method is probably easier in many cases, but this method is probably faster if you have the RDATA already in wire format instead of ASCII]. > > Ray > -Bryan From Ray.Bellis at nominet.org.uk Thu Sep 2 21:05:36 2010 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Thu, 2 Sep 2010 21:05:36 +0000 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <4C800F5B.8030506@ecessa.com> References: <4C7FE992.5000809@ecessa.com> <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> <4C7FF92D.1080802@ecessa.com> <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> <4C800F5B.8030506@ecessa.com> Message-ID: <8A6272B0-8478-4301-91F5-7487E791F1FF@nominet.org.uk> > > Ahh, I see - that does look much simpler. > > As long as I create the "@ RTYPE RDATA" correctly (it's probably still > much less error prone than probably duplication alot of code in the > _internal function). > Of course only use "@" if you mean it - the function correctly turns non-fully-qualified labels into FQDNs by appending the "origin" RDF value. Ray From Ray.Bellis at nominet.org.uk Thu Sep 2 19:43:23 2010 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Thu, 2 Sep 2010 19:43:23 +0000 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <4C7FF92D.1080802@ecessa.com> References: <4C7FE992.5000809@ecessa.com> <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> <4C7FF92D.1080802@ecessa.com> Message-ID: <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> >> Is the real issue figuring how to create an "ldns_rr"? > > Yes, I think that is the main difficulty. > > ldns_rr_new_frm_str_internal() is what I've been looking at as the > template for creating my own ldns_rr. It looks like it has all the > init, and assignment code that I would need. > > It seems like this function is the most like what I want. Well, that depends on what the source of your RRs is. I've used ldns_rr_new_frm_str() before (not the _internal variant): ldns_rr *rr; ldns_rdf *origin = ldns_dname_new_frm_str(origin_str); ldns_rr_new_frm_str(&rr, rr_str, ttl, origin, NULL); (where "origin_str" is $ORIGIN and "rr_str" is the RR in the form "@ RTYPE RDATA") Alternatively, it's possible (but tedious) to create it one field at a time: ldns_rr *rr = ldns_rr_new(); ldns_rdf *owner = ldns_dname_new_frm_str(owner_str); ldns_rr_set_owner(rr, owner); ldns_rr_set_ttl(rr, ttl); ldns_rr_set_type(rr, rtype); ... [not sure how to set the RDATA yet, the _frm_str method is probably easier in many cases, but this method is probably faster if you have the RDATA already in wire format instead of ASCII]. Ray From wouter at NLnetLabs.nl Mon Sep 6 14:18:07 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Mon, 06 Sep 2010 16:18:07 +0200 Subject: [ldns-users] ldns_buffer_free() function bug? In-Reply-To: <4C762E10.4060606@nic.cz> References: <4C762E10.4060606@nic.cz> Message-ID: <4C84F81F.3030705@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, The prototype is fine, this is what a *free() function is expected to be. The LDNS_FREE macro sets its argument to NULL for debugging and cleanliness reasons, so that use-after-free is detected very quickly. It is not necessary to change the prototype for ldns_buffer_free for that, nor is it really necessary to set this variable to NULL. Best regards, Wouter On 08/26/2010 11:04 AM, Zbynek Michl wrote: > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyE+B8ACgkQkDLqNwOhpPhNJwCdFPtSl0z1CoeCW5oz4tsr6Qx+ y2wAmwVvUg/QM8AXOq4lYD7HY9pH3Vab =f6Ie -----END PGP SIGNATURE----- From wouter at NLnetLabs.nl Mon Sep 6 14:35:12 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Mon, 06 Sep 2010 16:35:12 +0200 Subject: [ldns-users] Programmatically creating a zone In-Reply-To: <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> References: <4C7FE992.5000809@ecessa.com> <425F750C-E3C8-483C-8E44-5808D04E5A91@nominet.org.uk> <4C7FF92D.1080802@ecessa.com> <45FA5DE9-1171-4D96-9C06-38B9511EF24C@nominet.org.uk> Message-ID: <4C84FC20.6070009@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ray, Bryan, On 09/02/2010 09:43 PM, Ray Bellis wrote: > ldns_rr *rr; > ldns_rdf *origin = ldns_dname_new_frm_str(origin_str); > ldns_rr_new_frm_str(&rr, rr_str, ttl, origin, NULL); > > (where "origin_str" is $ORIGIN and "rr_str" is the RR in the form "@ RTYPE RDATA") Yes that is easier than the method below. > Alternatively, it's possible (but tedious) to create it one field at a time: > > ldns_rr *rr = ldns_rr_new(); > ldns_rdf *owner = ldns_dname_new_frm_str(owner_str); > ldns_rr_set_owner(rr, owner); > ldns_rr_set_ttl(rr, ttl); > ldns_rr_set_type(rr, rtype); > ... > > [not sure how to set the RDATA yet, the _frm_str method is probably easier in many cases, but this method is probably faster if you have the RDATA already in wire format instead of ASCII]. You add the rdata one field at a time, by creating ldns_rdf's for every RDATA field, and pushing it ldns_rr_push_rdf() onto the rdf. To create the rdata for an A record you would do: ldns_str2rdf_a() or ldns_rdf_new_frm_str(LDNS_RDF_TYPE_A, "192.0.2.1") or ldns_rdf_new_frm_data(LDNS_RDF_TYPE_A, 4, pointer to 4-octet ipv4 in wire format) For other types you need the correct rdf fields, ldns_rr_descript() can tell you what rdf fields are needed. Anyway ldns_rr_new_frm_str handles that for you. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyE/CAACgkQkDLqNwOhpPhiQACfVuZ0LnReAzNzcNcDRFzdPxrN FHMAn1H/lFaRAyVCzVFMVQMWZJEACy5b =6UTF -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Tue Sep 7 13:34:41 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Tue, 07 Sep 2010 15:34:41 +0200 Subject: [ldns-users] Improper socket closing on Windows Message-ID: <4C863F71.9030909@nic.cz> Hi, ldns library does not close sockets on Windows. In sources is almost everywhere used close() function, but it works well just on UNIX systems. On Windows is necessary to use closesocket() instead of close() function. So I suggest to modify ldns source files like this: #ifndef USE_WINSOCK close(sockfd); #else closesocket(sockfd); #endif Regards, Zbynek From wouter at NLnetLabs.nl Tue Sep 14 09:43:08 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 14 Sep 2010 11:43:08 +0200 Subject: [ldns-users] Wrong parsing of /etc/resolv.conf In-Reply-To: <4C7D0201.7010700@nic.cz> References: <4C7D0201.7010700@nic.cz> Message-ID: <4C8F43AC.6010402@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, Fixed in svn trunk r3340. It skips the %eth0. Best regards, Wouter On 08/31/2010 03:22 PM, Zbynek Michl wrote: > nameserver fe80::222:19ff:fe31:4222%eth0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPQ6wACgkQkDLqNwOhpPiXoACgpcV+ogE25qagEFJ4Bch3GL2f tzEAmwXeCXmWOAhQiV2q0d5UtxTdLng/ =4VMK -----END PGP SIGNATURE----- From wouter at NLnetLabs.nl Tue Sep 14 10:41:43 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 14 Sep 2010 12:41:43 +0200 Subject: [ldns-users] drill doesn't validate NSEC3 nxdomain? In-Reply-To: <4C7D5ACC.4020105@nic.cl> References: <4C7D5ACC.4020105@nic.cl> Message-ID: <4C8F5167.7000804@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Hugo, On 08/31/2010 09:41 PM, Hugo Salgado wrote: > I want to use "drill -k" to validate correctness of a nsec3 > chain signature, for a nxdomain response. > 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. > I'm using drill version 1.6.6 (ldns version 1.6.6). Fixed in svn trunk r3341. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPUWcACgkQkDLqNwOhpPgClgCgrypMiOXWvHLRf6BMk6EAZqXt E5QAoLBOYe5PQ+VTVmQaBc8L8grbXLpX =5SHC -----END PGP SIGNATURE----- From wouter at NLnetLabs.nl Tue Sep 14 11:12:59 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 14 Sep 2010 13:12:59 +0200 Subject: [ldns-users] Improper socket closing on Windows In-Reply-To: <4C863F71.9030909@nic.cz> References: <4C863F71.9030909@nic.cz> Message-ID: <4C8F58BB.905@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, On 09/07/2010 03:34 PM, Zbynek Michl wrote: > ldns library does not close sockets on Windows. In sources is almost > everywhere used close() function, but it works well just on UNIX > systems. On Windows is necessary to use closesocket() instead of close() > function. So I suggest to modify ldns source files like this: > > #ifndef USE_WINSOCK > close(sockfd); > #else > closesocket(sockfd); > #endif Patch applied to svn trunk r3342, it cross-compiled properly to win32. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPWLsACgkQkDLqNwOhpPgsTACgmrrTQC5QYusGhKtLhQbtls3X D9QAnAgetxxW4V4XxVe3RDTU7QsuOBAO =RxEs -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Tue Sep 14 16:46:56 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Tue, 14 Sep 2010 18:46:56 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4BEA52EE.4050702@nlnetlabs.nl> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> Message-ID: <4C8FA700.2090106@nic.cz> Hi Matthijs, I have tried to make a dname like this: domain = ldns_dname_new_frm_str("myhostname"); new_domain = ldns_dname_new_frm_data(ldns_rdf_size(domain) - 1, ldns_rdf_data(domain)); printf("domain: %s\n", ldns_rdf2str(domain)); printf("new_domain: %s\n", ldns_rdf2str(new_domain)); It is strange for me that both printf()s print the same result (with dot at the end). And then when I use: p = ldns_resolver_search(res, new_domain, LDNS_RR_TYPE_A, LDNS_RR_CLASS_IN, LDNS_RD); resolver returns FORMERR, because ldns_resolver_search() uses ldns_rdf2str() which causes to call ldns_resolver_query() with incorrect domain name. Another error of ldns_resolver_search() is that it does not check RCODE. In case of this resolv.conf: search mydomain.com search mydomain.cz and query for "myhostname" will try just first search value even if NXDOMAIN is returned. Last error that I have observed is that ldns_resolver_new_frm_file() reads just first domain name on line, so this searchlist definition is not read completely: search mydomain.com mydomain.cz Regards, Zbynek On 12.5.2010 09:04, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek, > > Sorry for the late follow-up. You are right that making a dname from > string always returns an absolute dname. You can try making a dname with > ldns_dname_new_frm_data(). > > Best regards, > > Matthijs > > Zbynek Michl wrote: >> Hello, >> >> I am trying to use search list, but unsuccessfully. Here is an sample: >> >> --- CODE --- >> ldns_rdf *domain = ldns_dname_new_frm_str("myhostname"); >> ldns_rdf *search = ldns_dname_new_frm_str("mydomain.cz"); >> >> ldns_resolver_push_searchlist(res, search); >> >> p = ldns_resolver_search(res, domain, LDNS_RR_TYPE_A, >> LDNS_RR_CLASS_IN, LDNS_RD); >> --- /CODE --- >> >> The problem is that "myhostname.mydomain.cz" will never be tried, >> because of ldns_dname_new_frm_str() adds "." to the end of "myhostname" >> and therefore ldns_resolver_search() will not concatenate "mydomain.cz". >> So how can I create "myhostname" RDF without trailing "."? Or any other >> suggestion? >> >> Cheers, >> Zbynek >> _______________________________________________ >> 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.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEcBAEBAgAGBQJL6lLsAAoJEA8yVCPsQCW5Ss8IAItekTcmCrBH/GbCYgbLIVMO > zlydOWWoYPbwWN23uT53v6/b9GaCl85vlxQk8XizcyffFpHvNpydbLAAZQ6oF0rP > JtzsTlR9vmNvoTfr23ZYAlALKnacDhb3W34nAFwZwoOf8KhGvI36D9IvY9NI4r/K > bt9BQm/wGF2yyqUsCp7D8/NaHbgzP7J2hU+58A8I14cuXRGOv3KEWPHZA/hLTxfI > B6YflGVdqBRXVKr8tkB7hc4SPwrSyaFiWEyp13fCyTzJ+uUk9xijO1Ec0QeGLd1L > AKUQeGRs8Ci+4Xu5N37L2galQVezjFhLXTE6XGwO0yZ/9V9ZChdSoG0X1u7JiiU= > =wPt5 > -----END PGP SIGNATURE----- From hsalgado at nic.cl Tue Sep 14 16:54:06 2010 From: hsalgado at nic.cl (Hugo Salgado) Date: Tue, 14 Sep 2010 12:54:06 -0400 Subject: [ldns-users] drill doesn't validate NSEC3 nxdomain? In-Reply-To: <4C8F5167.7000804@nlnetlabs.nl> References: <4C7D5ACC.4020105@nic.cl> <4C8F5167.7000804@nlnetlabs.nl> Message-ID: <4C8FA8AE.7000801@nic.cl> Great, thanks Wouter. Now it's working! Regards, Hugo On 09/14/2010 06:41 AM, W.C.A. Wijngaards wrote: > Hi Hugo, > > On 08/31/2010 09:41 PM, Hugo Salgado wrote: >> I want to use "drill -k" to validate correctness of a nsec3 >> chain signature, for a nxdomain response. >> 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. >> I'm using drill version 1.6.6 (ldns version 1.6.6). > > Fixed in svn trunk r3341. > > Best regards, > Wouter From marco.davids at sidn.nl Mon Sep 20 09:08:03 2010 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Mon, 20 Sep 2010 11:08:03 +0200 Subject: [ldns-users] Time bug? Message-ID: <4C972473.5090101@sidn.nl> Hi, For fun I signed a zonefile with an expiration time way in the future, the RRSIG says: '...SOA 7 2 86400 20781008111202 20100920075757...' However, ldns-rrsig says: RRSIG(SOA): Mon Sep 20 09:57:57 2010 - Wed Sep 2 06:43:46 1942 Is LDNS perhaps not entirely RFC1982 compliant? No need to hurry for a fix, there is ample time ;-) Regards, -- Marco Davids Technical Advisor SIDN | Utrechtseweg 310 | 6812 AR | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 83 | M +31 (0)6 52 37 34 35 | F +31 (0)26 352 55 05 marco.davids at sidn.nl | www.sidn.nl | enum:+31652373435 | sip:583 at sidn.nl From matthijs at NLnetLabs.nl Mon Sep 20 10:40:07 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 20 Sep 2010 12:40:07 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4C8FA700.2090106@nic.cz> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> Message-ID: <4C973A07.8010700@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, I noticed that the dname2str function prints a dot after every label. And that function is used in ldns_resolver_search(...) to determine if the domain is a relative or a fqdn. I fixed this in trunk, r3347. I found another bug in the ldns_resolver_search function. The ldns_resolver stops as soon it founds a packet. But it would be nice if the ldns_resolver continues its search if the RCODE of that packet is not NOERROR. This fix is in trunk since r3349. Thanks for your report. Best regards, Matthijs On 09/14/2010 06:46 PM, Zbynek Michl wrote: > Hi Matthijs, > > I have tried to make a dname like this: > > domain = ldns_dname_new_frm_str("myhostname"); > new_domain = ldns_dname_new_frm_data(ldns_rdf_size(domain) - 1, > ldns_rdf_data(domain)); > printf("domain: %s\n", ldns_rdf2str(domain)); > printf("new_domain: %s\n", ldns_rdf2str(new_domain)); > > It is strange for me that both printf()s print the same result (with dot > at the end). And then when I use: > > p = ldns_resolver_search(res, new_domain, LDNS_RR_TYPE_A, > LDNS_RR_CLASS_IN, LDNS_RD); > > resolver returns FORMERR, because ldns_resolver_search() uses > ldns_rdf2str() which causes to call ldns_resolver_query() with incorrect > domain name. > > > Another error of ldns_resolver_search() is that it does not check RCODE. > In case of this resolv.conf: > > search mydomain.com > search mydomain.cz > > and query for "myhostname" will try just first search value even if > NXDOMAIN is returned. > > Last error that I have observed is that ldns_resolver_new_frm_file() > reads just first domain name on line, so this searchlist definition is > not read completely: > > search mydomain.com mydomain.cz > > > Regards, > Zbynek > > On 12.5.2010 09:04, Matthijs Mekking wrote: > Hi Zbynek, > > Sorry for the late follow-up. You are right that making a dname from > string always returns an absolute dname. You can try making a dname with > ldns_dname_new_frm_data(). > > Best regards, > > Matthijs > > Zbynek Michl wrote: >>>> Hello, >>>> >>>> I am trying to use search list, but unsuccessfully. Here is an sample: >>>> >>>> --- CODE --- >>>> ldns_rdf *domain = ldns_dname_new_frm_str("myhostname"); >>>> ldns_rdf *search = ldns_dname_new_frm_str("mydomain.cz"); >>>> >>>> ldns_resolver_push_searchlist(res, search); >>>> >>>> p = ldns_resolver_search(res, domain, LDNS_RR_TYPE_A, >>>> LDNS_RR_CLASS_IN, LDNS_RD); >>>> --- /CODE --- >>>> >>>> The problem is that "myhostname.mydomain.cz" will never be tried, >>>> because of ldns_dname_new_frm_str() adds "." to the end of "myhostname" >>>> and therefore ldns_resolver_search() will not concatenate "mydomain.cz". >>>> So how can I create "myhostname" RDF without trailing "."? Or any other >>>> suggestion? >>>> >>>> Cheers, >>>> Zbynek >>>> _______________________________________________ >>>> 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/ iQEcBAEBAgAGBQJMlzoGAAoJEA8yVCPsQCW54RAIANqfP6o7Jex8E2gFfXoXQNl1 lIDjPGSWfuFPeAcQS4G7YA7Tav2/0SKLX1RXdIuclWkzW+dI74z5FwPIhrqGV9ef +lWLO/jL2OvP6CDVTy/cc3abbU04rGl/PmYgCFJblJ4m98DjIrEF7OvfzviwH3G3 cePtHcCiZy/cmSU450IzZ35PezSGFvaTLif04aFSMwIsMvhsfixNn+H7R0lmklZM 6K42z/zuYKnuEAU5tadHStfAi4Et04SBEs4B1xRkWp+Sdy/dRhYaj103bypC6qMH UiREaRCvbRkAnD5ukrodYvhjEmDrAnDPFo9MnSBCKZtDl+2nrWa9CUS2fVvqYxs= =nOFm -----END PGP SIGNATURE----- From msheldon at godaddy.com Wed Sep 22 21:18:36 2010 From: msheldon at godaddy.com (Michael Sheldon) Date: Wed, 22 Sep 2010 14:18:36 -0700 Subject: [ldns-users] =?utf-8?q?Drill_does_not_handle_CNAME_properly=3F?= Message-ID: <20100922141836.205a61dff9fc1684c258b274662bb912.35d0b2c2aa.wbe@email00.secureserver.net> Not sure if this is right or not. When digging for a hostname, type A (or any type other than CNAME) that is represented by a CNAME, I get: ; Bad data; RR for name and type not found or failed to verify, and denial of existence failed. If I dig directly for the CNAME, it validates, as it does if I dig directly for the target host record. Is this correct? Michael Sheldon Dev-DNS Services GoDaddy.com