From miek at miek.nl Thu Oct 14 13:15:55 2010 From: miek at miek.nl (Miek Gieben) Date: Thu, 14 Oct 2010 15:15:55 +0200 Subject: [ldns-users] drill -s Message-ID: <20101014131555.GA20129@miek.nl> Hello, I was wondering if there was a switch in drill which could print the DS of the keys in the packet. Ofcourse such a switch was already there :-) However it only prints the SHA1 hash. The following patch expands this a little, so that the SHA256 is also printed. It would make our lives here at SIDN a little easier. Kind regards, Miek Gieben --- ldns-1.6.4-patched/drill/drill_util.c 2010-10-14 15:06:56.068236505 +0200 +++ ldns-1.6.4/drill/drill_util.c 2010-01-21 11:30:14.000000000 +0100 @@ -103,7 +103,7 @@ { ldns_rr_list *keys; uint16_t i; - ldns_rr *ds1, *ds2; + ldns_rr *ds; /* TODO fix the section stuff, here or in ldns */ keys = ldns_pkt_rr_list_by_type(p, LDNS_RR_TYPE_DNSKEY, @@ -114,17 +114,12 @@ if (keys) { for (i = 0; i < ldns_rr_list_rr_count(keys); i++) { - ds1 = ldns_key_rr2ds(ldns_rr_list_rr(keys, i), LDNS_SHA1); - ds2 = ldns_key_rr2ds(ldns_rr_list_rr(keys, i), LDNS_SHA256); - if (ds1) { + ds = ldns_key_rr2ds(ldns_rr_list_rr(keys, i), LDNS_SHA1); + if (ds) { printf("; "); - ldns_rr_print(stdout, ds1); + ldns_rr_print(stdout, ds); + printf("\n"); } - if (ds2) { - printf("; "); - ldns_rr_print(stdout, ds2); - } - printf("\n"); } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From zbynek.michl at nic.cz Fri Oct 15 13:01:23 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Fri, 15 Oct 2010 15:01:23 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4C973A07.8010700@nlnetlabs.nl> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> <4C973A07.8010700@nlnetlabs.nl> Message-ID: <4CB850A3.2060002@nic.cz> Hi Matthijs, thanks for your bug fixes. However I am still in doubt with ldns_resolver_search() function. I think it is not a good idea to use ldns_dname_str_absolute(str_dname) there. 1. When I use ---CODE--- domain = ldns_dname_new_frm_str("myhostname"); p = ldns_resolver_search(res, domain, LDNS_RR_TYPE_A, LDNS_RR_CLASS_IN, LDNS_RD); ---/CODE--- then searchlist is not used because ldns_dname_new_frm_str() creates absolute dname everytime. 2. When I use ---CODE--- domain = ldns_dname_new_frm_str("myhostname.mydomain.cz"); new_domain = ldns_dname_new_frm_data(ldns_rdf_size(domain) - 1, ldns_rdf_data(domain)); p = ldns_resolver_search(res, new_domain, LDNS_RR_TYPE_A, LDNS_RR_CLASS_IN, LDNS_RD); ---/CODE--- then searchlist is used indeed, however alone "myhostname.mydomain.cz" is never tried. So I would expect ldns_resolver_search() should try every combination for given name (with and without suffix(es)). Btw reading of searchlist from resolv.conf containing more than one suffix (e.g. search mydomain.com mydomain.cz) still does not work properly. Thanks, Zbynek On 20.9.2010 12:40, Matthijs Mekking wrote: > -----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 matthijs at NLnetLabs.nl Mon Oct 18 11:11:00 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 18 Oct 2010 13:11:00 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4CB850A3.2060002@nic.cz> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> <4C973A07.8010700@nlnetlabs.nl> <4CB850A3.2060002@nic.cz> Message-ID: <4CBC2B44.30202@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Zbynek, On 10/15/2010 03:01 PM, Zbynek Michl wrote: ... > So I would expect ldns_resolver_search() should try every combination > for given name (with and without suffix(es)). I guess by default adding the root domain (".") to the search list would fix that. > Btw reading of searchlist from resolv.conf containing more than one > suffix (e.g. search mydomain.com mydomain.cz) still does not work properly. Fixed this in r3357. Best regards, Matthijs > > Thanks, > Zbynek > > On 20.9.2010 12:40, Matthijs Mekking wrote: > 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/ iQEcBAEBAgAGBQJMvCtEAAoJEA8yVCPsQCW5ksUH/18uKaUonr99L0qCKX8802T6 YqPdMI7aM+hUMhoxmCAN6xLrUAtyoWtien201ip/UiVss3I3n9aw1jqjCUCzV3VH sh4gjyR+IvwOHljlc73/Qv8H1ZQGnfiUr3F+E49jKKr8XnqWI5Za3nkBAkUqtZQ1 su6fTV/8Z+kpy6WClr0yKPGCS0S8iytVJwgvbLwBrGb6lpZV4Jj1DaP0EI3O3QXd zx4nFEdq4yBhn7qGgIyXuB09gB8y3miVl7zsqdJUQqLpyFyhGRdcVLbWmHZuwJeD pm9IPE3sSlSFHR0Fr+ozcus8bG3MM3H/Ij6M9lUJTw4gQjSoHSfE1Y/ONHsUcsw= =gsMr -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Mon Oct 25 11:45:16 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 25 Oct 2010 13:45:16 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4CBC2B44.30202@nlnetlabs.nl> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> <4C973A07.8010700@nlnetlabs.nl> <4CB850A3.2060002@nic.cz> <4CBC2B44.30202@nlnetlabs.nl> Message-ID: <4CC56DCC.5030906@nic.cz> Hi Matthijs, thanks for your fixes, however I think that it is not a good idea to add "." zone to the end of the search list in ldns_resolver_new_frm_fp_l() by default. In my case I am querying for A/AAAA records and it does not make a sense to query domain names with just one label (e.g. myname.) It would be better to make new resolver option for this or let user to add it by hand if he needs it (as it was in previous releases of ldns). Regards, Zbynek On 18.10.2010 13:11, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Zbynek, > > On 10/15/2010 03:01 PM, Zbynek Michl wrote: > ... >> So I would expect ldns_resolver_search() should try every combination >> for given name (with and without suffix(es)). > > I guess by default adding the root domain (".") to the search list would > fix that. > >> Btw reading of searchlist from resolv.conf containing more than one >> suffix (e.g. search mydomain.com mydomain.cz) still does not work properly. > > Fixed this in r3357. > > Best regards, > Matthijs > >> >> Thanks, >> Zbynek >> >> On 20.9.2010 12:40, Matthijs Mekking wrote: >> 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/ > > iQEcBAEBAgAGBQJMvCtEAAoJEA8yVCPsQCW5ksUH/18uKaUonr99L0qCKX8802T6 > YqPdMI7aM+hUMhoxmCAN6xLrUAtyoWtien201ip/UiVss3I3n9aw1jqjCUCzV3VH > sh4gjyR+IvwOHljlc73/Qv8H1ZQGnfiUr3F+E49jKKr8XnqWI5Za3nkBAkUqtZQ1 > su6fTV/8Z+kpy6WClr0yKPGCS0S8iytVJwgvbLwBrGb6lpZV4Jj1DaP0EI3O3QXd > zx4nFEdq4yBhn7qGgIyXuB09gB8y3miVl7zsqdJUQqLpyFyhGRdcVLbWmHZuwJeD > pm9IPE3sSlSFHR0Fr+ozcus8bG3MM3H/Ij6M9lUJTw4gQjSoHSfE1Y/ONHsUcsw= > =gsMr > -----END PGP SIGNATURE----- From matthijs at NLnetLabs.nl Mon Oct 25 12:00:58 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Mon, 25 Oct 2010 14:00:58 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4CC56DCC.5030906@nic.cz> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> <4C973A07.8010700@nlnetlabs.nl> <4CB850A3.2060002@nic.cz> <4CBC2B44.30202@nlnetlabs.nl> <4CC56DCC.5030906@nic.cz> Message-ID: <4CC5717A.5060802@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, You requested: "So I would expect ldns_resolver_search() should try every combination for given name (with and without suffix(es))." Adding the root zone to the search list ensures that every combination is tried (all search domains appended or treat it as a fqdn). But now, if I understand correctly, you want to be able to choose whether you should do a fqdn query or append a search domain? Best regards, Matthijs On 10/25/2010 01:45 PM, Zbynek Michl wrote: > Hi Matthijs, > > thanks for your fixes, however I think that it is not a good idea to add > "." zone to the end of the search list in ldns_resolver_new_frm_fp_l() > by default. > > In my case I am querying for A/AAAA records and it does not make a sense > to query domain names with just one label (e.g. myname.) > > It would be better to make new resolver option for this or let user to > add it by hand if he needs it (as it was in previous releases of ldns). > > Regards, > Zbynek > > On 18.10.2010 13:11, Matthijs Mekking wrote: > Hi Zbynek, > > On 10/15/2010 03:01 PM, Zbynek Michl wrote: > ... >>>> So I would expect ldns_resolver_search() should try every combination >>>> for given name (with and without suffix(es)). > > I guess by default adding the root domain (".") to the search list would > fix that. > >>>> Btw reading of searchlist from resolv.conf containing more than one >>>> suffix (e.g. search mydomain.com mydomain.cz) still does not work >>>> properly. > > Fixed this in r3357. > > Best regards, > Matthijs > >>>> >>>> Thanks, >>>> Zbynek >>>> >>>> On 20.9.2010 12:40, Matthijs Mekking wrote: >>>> 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/ iQEcBAEBAgAGBQJMxXF6AAoJEA8yVCPsQCW5LWwIAIMYOLgYG6680UteYwTrC85t l4wFpVBcoyoyGIWl68d4bt25z/G2UlT7obSiCZGY7x+YraPpbeE0UI1466W3eJEe cmzZ8dMAbytCdkT/XMmmEf0uxbg/KziKHuM7KcixI49aJXDz/p/Dk/2RrnAPyir8 R2nXDKRCV8ieOGXjcROjxwB6kXtP3DrrCYTLbZhzJE3l06bykp/hOeX3MrdtrSXm UzxrdnSRgDQjqwxJ68dnsCjEbtw6r8EJeCjKBYYdBbhwTybZ8jyNJetKW/ZO5G+4 XKcj4EXouOZjVLtV2toKHhwiGr4JYfmUVGKg7zf7GDULSbuEKzkhreNPTyjneFk= =wGOB -----END PGP SIGNATURE----- From zbynek.michl at nic.cz Mon Oct 25 13:16:44 2010 From: zbynek.michl at nic.cz (Zbynek Michl) Date: Mon, 25 Oct 2010 15:16:44 +0200 Subject: [ldns-users] How to use _searchlist provided by ldns_struct_resolver? In-Reply-To: <4CC5717A.5060802@nlnetlabs.nl> References: <4BCC8BBD.8070902@nic.cz> <4BEA52EE.4050702@nlnetlabs.nl> <4C8FA700.2090106@nic.cz> <4C973A07.8010700@nlnetlabs.nl> <4CB850A3.2060002@nic.cz> <4CBC2B44.30202@nlnetlabs.nl> <4CC56DCC.5030906@nic.cz> <4CC5717A.5060802@nlnetlabs.nl> Message-ID: <4CC5833C.4050103@nic.cz> Ok, I know that I am a little bit confusing :) I have my own search function as follows: ---CODE--- ldns_pkt* ds_resolver_search(const ldns_resolver *r, const ldns_rdf *name, ldns_rr_type t, ldns_rr_class c, uint16_t flags) { ldns_rdf *new_name; ldns_rdf **search_list; size_t i; ldns_pkt *orig_p, *new_p; orig_p = NULL; new_p = NULL; if (ldns_dname_label_count(name) > 1 || (t != LDNS_RR_TYPE_A && t != LDNS_RR_TYPE_AAAA)) { /* query as is */ orig_p = ds_resolver_search_query(r, name, t, c, flags); if (orig_p && ldns_pkt_get_rcode(orig_p) == LDNS_RCODE_NOERROR) { return orig_p; } } if (ldns_resolver_dnsrch(r)) { /* query using search-list */ search_list = ldns_resolver_searchlist(r); for (i = 0; i < ldns_resolver_searchlist_count(r); i++) { new_name = ldns_dname_cat_clone(name, search_list[i]); new_p = ds_resolver_search_query(r, new_name, t, c, flags); ldns_rdf_free(new_name); if (new_p) { if (ldns_pkt_get_rcode(new_p) == LDNS_RCODE_NOERROR) { ldns_pkt_free(orig_p); return new_p; } else { ldns_pkt_free(new_p); } } } } return orig_p; } ---/CODE--- Now I can resolve FQDN names on my own, but default "." in search list results in A/AAAA queries even for domain names with just one label. So I suggest to modify ldns_resolver_search() function according to my function (which then I can use) and remove default "." from the search list. Thanks, Zbynek On 25.10.2010 14:00, Matthijs Mekking wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > You requested: > "So I would expect ldns_resolver_search() should try every combination > for given name (with and without suffix(es))." > > Adding the root zone to the search list ensures that every combination > is tried (all search domains appended or treat it as a fqdn). > > But now, if I understand correctly, you want to be able to choose > whether you should do a fqdn query or append a search domain? > > Best regards, > > Matthijs > > > > On 10/25/2010 01:45 PM, Zbynek Michl wrote: >> Hi Matthijs, >> >> thanks for your fixes, however I think that it is not a good idea to add >> "." zone to the end of the search list in ldns_resolver_new_frm_fp_l() >> by default. >> >> In my case I am querying for A/AAAA records and it does not make a sense >> to query domain names with just one label (e.g. myname.) >> >> It would be better to make new resolver option for this or let user to >> add it by hand if he needs it (as it was in previous releases of ldns). >> >> Regards, >> Zbynek >> >> On 18.10.2010 13:11, Matthijs Mekking wrote: >> Hi Zbynek, >> >> On 10/15/2010 03:01 PM, Zbynek Michl wrote: >> ... >>>>> So I would expect ldns_resolver_search() should try every combination >>>>> for given name (with and without suffix(es)). >> >> I guess by default adding the root domain (".") to the search list would >> fix that. >> >>>>> Btw reading of searchlist from resolv.conf containing more than one >>>>> suffix (e.g. search mydomain.com mydomain.cz) still does not work >>>>> properly. >> >> Fixed this in r3357. >> >> Best regards, >> Matthijs >> >>>>> >>>>> Thanks, >>>>> Zbynek >>>>> >>>>> On 20.9.2010 12:40, Matthijs Mekking wrote: >>>>> 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/ > > iQEcBAEBAgAGBQJMxXF6AAoJEA8yVCPsQCW5LWwIAIMYOLgYG6680UteYwTrC85t > l4wFpVBcoyoyGIWl68d4bt25z/G2UlT7obSiCZGY7x+YraPpbeE0UI1466W3eJEe > cmzZ8dMAbytCdkT/XMmmEf0uxbg/KziKHuM7KcixI49aJXDz/p/Dk/2RrnAPyir8 > R2nXDKRCV8ieOGXjcROjxwB6kXtP3DrrCYTLbZhzJE3l06bykp/hOeX3MrdtrSXm > UzxrdnSRgDQjqwxJ68dnsCjEbtw6r8EJeCjKBYYdBbhwTybZ8jyNJetKW/ZO5G+4 > XKcj4EXouOZjVLtV2toKHhwiGr4JYfmUVGKg7zf7GDULSbuEKzkhreNPTyjneFk= > =wGOB > -----END PGP SIGNATURE----- From bedrich.kosata at nic.cz Mon Oct 25 13:40:51 2010 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Mon, 25 Oct 2010 15:40:51 +0200 Subject: [ldns-users] how to check existence of EDNS in read packet Message-ID: <4CC588E3.90807@nic.cz> Hello, I have the following problem. When parsing DNS packets, I need to know if an OPT RR containing EDNS is present. However, it seems that ldns parses this RR separately and then removes it from the additional section. What is the best way to find out if this RR was present in the original data? I need this to find out if the zero returned for edns version is a real value or a default one. It seems that the best I can do for now is to use the value of _edns_udp_size, but this could be zero as well (at least in theory), could it not? I would be glad for any insight. Best regards Beda -- Bedrich Kosata CZ.NIC Labs From Ray.Bellis at nominet.org.uk Mon Oct 25 16:21:37 2010 From: Ray.Bellis at nominet.org.uk (Ray Bellis) Date: Mon, 25 Oct 2010 16:21:37 +0000 Subject: [ldns-users] how to check existence of EDNS in read packet In-Reply-To: <4CC588E3.90807@nic.cz> References: <4CC588E3.90807@nic.cz> Message-ID: <8F5ADBD7-B689-4DBC-9D6C-4B631A944159@nominet.org.uk> On 25 Oct 2010, at 14:40, Bedrich Kosata wrote: > Hello, > > I have the following problem. When parsing DNS packets, I need to know if an OPT RR containing EDNS is present. However, it seems that ldns parses this RR separately and then removes it from the additional section. > What is the best way to find out if this RR was present in the original data? I need this to find out if the zero returned for edns version is a real value or a default one. > It seems that the best I can do for now is to use the value of _edns_udp_size, but this could be zero as well (at least in theory), could it not? > > I would be glad for any insight. This function should give you the original EDNS RR (if any) ldns_rdf *ldns_pkt_edns_data(const ldns_pkt *packet) Ray From bedrich.kosata at nic.cz Tue Oct 26 05:54:29 2010 From: bedrich.kosata at nic.cz (Bedrich Kosata) Date: Tue, 26 Oct 2010 07:54:29 +0200 Subject: [ldns-users] how to check existence of EDNS in read packet In-Reply-To: <8F5ADBD7-B689-4DBC-9D6C-4B631A944159@nominet.org.uk> References: <4CC588E3.90807@nic.cz> <8F5ADBD7-B689-4DBC-9D6C-4B631A944159@nominet.org.uk> Message-ID: <4CC66D15.1070600@nic.cz> On 10/25/2010 06:21 PM, Ray Bellis wrote: > > On 25 Oct 2010, at 14:40, Bedrich Kosata wrote: > >> Hello, >> >> I have the following problem. When parsing DNS packets, I need to know if an OPT RR containing EDNS is present. However, it seems that ldns parses this RR separately and then removes it from the additional section. >> What is the best way to find out if this RR was present in the original data? I need this to find out if the zero returned for edns version is a real value or a default one. >> It seems that the best I can do for now is to use the value of _edns_udp_size, but this could be zero as well (at least in theory), could it not? >> >> I would be glad for any insight. > > This function should give you the original EDNS RR (if any) > > ldns_rdf *ldns_pkt_edns_data(const ldns_pkt *packet) > > Ray > Unfortunately, this does not seem to be the case. This structure only contains the optional data that might be present in the OPT RR, but which is often empty and thus this value is NULL. It seems that the best I could do, is to use "ldns_pkt_edns" which tells if there is data in the packet that would require use of EDNS. However, this function is meant to be used when constructing a packet, so it would not be reliable in case the packet arrived with OPT RR but contained zeroes in every field. It would be cool, if there could be an indicator value in the ldns_pkt struct which would tell if there was an OPT RR in the raw data. Best regards Beda -- Bedrich Kosata CZ.NIC Labs From darryl at rodden.us Tue Oct 26 15:03:51 2010 From: darryl at rodden.us (Darryl) Date: Tue, 26 Oct 2010 08:03:51 -0700 Subject: [ldns-users] how to check existence of EDNS in read packet References: <4CC588E3.90807@nic.cz><8F5ADBD7-B689-4DBC-9D6C-4B631A944159@nominet.org.uk> <4CC66D15.1070600@nic.cz> Message-ID: <001401cb751f$00bdb620$6210a8c0@cis.neustar.com> Hi, If you are using ldns_wire2pkt(), you can call ldns_pkt_edns() to determine if the received packet has EDNS or not. Regards, Darryl ----- Original Message ----- From: "Bedrich Kosata" To: Sent: Monday, October 25, 2010 10:54 PM Subject: Re: [ldns-users] how to check existence of EDNS in read packet > On 10/25/2010 06:21 PM, Ray Bellis wrote: >> >> On 25 Oct 2010, at 14:40, Bedrich Kosata wrote: >> >>> Hello, >>> >>> I have the following problem. When parsing DNS packets, I need to know >>> if an OPT RR containing EDNS is present. However, it seems that ldns >>> parses this RR separately and then removes it from the additional >>> section. >>> What is the best way to find out if this RR was present in the original >>> data? I need this to find out if the zero returned for edns version is a >>> real value or a default one. >>> It seems that the best I can do for now is to use the value of >>> _edns_udp_size, but this could be zero as well (at least in theory), >>> could it not? >>> >>> I would be glad for any insight. >> >> This function should give you the original EDNS RR (if any) >> >> ldns_rdf *ldns_pkt_edns_data(const ldns_pkt *packet) >> >> Ray >> > > Unfortunately, this does not seem to be the case. This structure only > contains the optional data that might be present in the OPT RR, but which > is often empty and thus this value is NULL. > It seems that the best I could do, is to use "ldns_pkt_edns" which tells > if there is data in the packet that would require use of EDNS. However, > this function is meant to be used when constructing a packet, so it would > not be reliable in case the packet arrived with OPT RR but contained > zeroes in every field. > It would be cool, if there could be an indicator value in the ldns_pkt > struct which would tell if there was an OPT RR in the raw data. > > Best regards > > Beda > > > -- > Bedrich Kosata > CZ.NIC Labs > _______________________________________________ > ldns-users mailing list > ldns-users at open.nlnetlabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/ldns-users >