From matthijs at NLnetLabs.nl Wed Dec 8 12:41:40 2010 From: matthijs at NLnetLabs.nl (Matthijs Mekking) Date: Wed, 08 Dec 2010 13:41:40 +0100 Subject: [ldns-users] Drill date strageness In-Reply-To: <4CF42294.7070106@digitus.itk.ppke.hu> References: <4CF42294.7070106@digitus.itk.ppke.hu> Message-ID: <4CFF7D04.2090801@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi P?sztor J?nos, The high verboisty (-V 5) makes drill print the query packets as well. The dig output doesn't show query packets, just response packets. Query packets don't have meaningful information about query time and received bytes. I think therefore, also the timestamp was not set. In trunk, I have added code that does set the timestamp, so you can at least see when the query was sent. Query time and MSG SIZE rcvd stay 0, obviously. Best regards, Matthijs On 11/29/2010 11:00 PM, P?sztor J?nos wrote: > Hi, > > Today i've made some experiment with drill, and found some strange dates > in the answers. I've made a trace to the domain 'se.' form the root, > with verbosity 5. And i've found that all dates are ';; WHEN: Thu Jan 1 > 01:00:00 1970' After i repeat the experiment with dig, and it printed > out the correct dates. > > I've attached the two replies. I use debian 5.0.7, ldns 1.6.7 and DiG > 9.7.1-P2 > > Is this intentional? > > Best regards, > J?nos > > > > _______________________________________________ > 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/ iQEcBAEBAgAGBQJM/30EAAoJEA8yVCPsQCW5niYIAIpkBo0kLZbRgwWFrAGchS99 MFg2EtcsqKxy9vRNT94RcooOaqvpC/au0M9aORXxwzW2IqmaaNjqhDP6u3yk2ByH g2lA6c0XL++wQxIy63d859uWNjYLIufPWkQYv5XLKeR7CUkcUpjY/e9qWDAV69Wz KCRXbej8wndu7Nu0jegjzq04gK5Ia9m8mxrxtmDUqS1iqxYx2TFAz+b8o04InCOD fqATcixeS9DlC8fFHJhBR0nm4BonS/v75Zy5CPCORyZDoy44vfNHU8zMhIrAX92H LuN4QvpbJ+tB9CW4HsgWD9wQgGpL+5uFYBBsEtpCTcWMCPSImkbsldtwIsInkJI= =94ju -----END PGP SIGNATURE----- From miek at miek.nl Tue Dec 14 13:10:18 2010 From: miek at miek.nl (Miek Gieben) Date: Tue, 14 Dec 2010 14:10:18 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? Message-ID: <20101214131018.GA15432@miek.nl> Hello, How hard would it be to extend the ldns library with 2 new functions that support callbacks? So to make asynchronous sending of queries possible? I was thinking about the following prototypes: ldns_resolver_send_callback(cb_func, ldns_resolver *r, const ldns_rdf *name, ldns_rr_type t, ldns_rr_class c, uint16_t flags); ldns_resolver_send_pkt_callback(cb_func, ldns_resolver *r, ldns_pkt *query_pkt); The cb_func prototype should be able to fill a ldns_pkt struct, so it might be: ldns_status cb_func(ldns_pkt *k) I have never dealt with callback functions, so I don't know if this is a viable proposal and how it impacts the rest of the ldns design. grtz, -- Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From henri at asseily.com Tue Dec 14 14:03:20 2010 From: henri at asseily.com (Henri Asseily) Date: Tue, 14 Dec 2010 16:03:20 +0200 Subject: [ldns-users] Problem when not using SSL? Message-ID: <3FD1F1CA-95DF-4CCF-9BEB-E838340348E5@asseily.com> Hello, I am running into a problem with ldns compiled without SSL. In resolver.c, line 1143: #ifdef HAVE_SSL if (ldns_resolver_tsig_keyname(r) && ldns_resolver_tsig_keydata(r)) { status = ldns_pkt_tsig_sign(query_pkt, ldns_resolver_tsig_keyname(r), ldns_resolver_tsig_keydata(r), 300, ldns_resolver_tsig_algorithm(r), NULL); if (status != LDNS_STATUS_OK) { return LDNS_STATUS_CRYPTO_TSIG_ERR; } } #else return LDNS_STATUS_CRYPTO_TSIG_ERR; #endif /* HAVE_SSL */ status = ldns_resolver_send_pkt(&answer_pkt, r, query_pkt); ... If HAVE_SSL is undefined, then the function always returns LDNS_STATUS_CRYPTO_TSIG_ERR and never properly completes. Is that correct behavior? I'm trying to debug why ldns 1.6.7 doesn't work for me, and this seems to be the culprit. I'll keep digging. --- Henri Asseily henri.tel From wouter at NLnetLabs.nl Tue Dec 14 14:40:53 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 14 Dec 2010 15:40:53 +0100 Subject: [ldns-users] Problem when not using SSL? In-Reply-To: <3FD1F1CA-95DF-4CCF-9BEB-E838340348E5@asseily.com> References: <3FD1F1CA-95DF-4CCF-9BEB-E838340348E5@asseily.com> Message-ID: <4D0781F5.2020105@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Henri, On 12/14/2010 03:03 PM, Henri Asseily wrote: > Hello, I am running into a problem with ldns compiled without SSL. In > resolver.c, line 1143: > > If HAVE_SSL is undefined, then the function always returns > LDNS_STATUS_CRYPTO_TSIG_ERR and never properly completes. Is that That is a bug, it should be inside the braces of the if(keyname). Thanks for the report! > correct behavior? I'm trying to debug why ldns 1.6.7 doesn't work for > me, and this seems to be the culprit. I'll keep digging. --- Henri I have fixed it in our svn development version of ldns (for 1.6.8). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0HgfUACgkQkDLqNwOhpPjzNgCffKGB1JkJhzbZH4Q0YuhKD1Mp g20Anitp1ykNLBHGY0U9l+h4YtxzWJ4d =2+5w -----END PGP SIGNATURE----- From wouter at NLnetLabs.nl Tue Dec 14 14:52:05 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Tue, 14 Dec 2010 15:52:05 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <20101214131018.GA15432@miek.nl> References: <20101214131018.GA15432@miek.nl> Message-ID: <4D078495.7000802@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi Miek, On 12/14/2010 02:10 PM, Miek Gieben wrote: > Hello, > > How hard would it be to extend the ldns library with 2 new functions > that support callbacks? So to make asynchronous sending of queries > possible? Well, asynchronous means another thread or process is working on the query. And ldns does not do that. > I was thinking about the following prototypes: > > ldns_resolver_send_callback(cb_func, ldns_resolver *r, const > ldns_rdf *name, ldns_rr_type t, ldns_rr_class c, uint16_t flags); > ldns_resolver_send_pkt_callback(cb_func, ldns_resolver *r, ldns_pkt *query_pkt); > > The cb_func prototype should be able to fill a ldns_pkt struct, so it > might be: > ldns_status cb_func(ldns_pkt *k) > > I have never dealt with callback functions, so I don't know if this is > a viable proposal and how it impacts the rest of the ldns design. It is not viable (for ldns itself). libunbound gives you a callback that gives the packet wiredata from unbound, it handles the threads, pipes, mutexes. Or maybe this does what you need: http://code.google.com/p/evldns/ Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0HhJUACgkQkDLqNwOhpPhYMwCeJY1e/p2M7AAKPvRN4x/omh/k gEoAn0zO+ZpCb5hNczltGY3jcJLPt0WB =J+YO -----END PGP SIGNATURE----- From paul at xelerance.com Tue Dec 14 14:56:27 2010 From: paul at xelerance.com (Paul Wouters) Date: Tue, 14 Dec 2010 09:56:27 -0500 (EST) Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <20101214131018.GA15432@miek.nl> References: <20101214131018.GA15432@miek.nl> Message-ID: On Tue, 14 Dec 2010, Miek Gieben wrote: [somewhat stealing this thread, apologies] > How hard would it be to extend the ldns library with 2 new functions > that support callbacks? So to make asynchronous sending of queries > possible? > > I was thinking about the following prototypes: > > ldns_resolver_send_callback(cb_func, ldns_resolver *r, const > ldns_rdf *name, ldns_rr_type t, ldns_rr_class c, uint16_t flags); > ldns_resolver_send_pkt_callback(cb_func, ldns_resolver *r, ldns_pkt *query_pkt); > > The cb_func prototype should be able to fill a ldns_pkt struct, so it > might be: > ldns_status cb_func(ldns_pkt *k) > > I have never dealt with callback functions, so I don't know if this is > a viable proposal and how it impacts the rest of the ldns design. This reminds me of a design decision we have to make (but postponed). That is to add better DNSSEC support to Openswan. It currently supports the bind lwres{} interface, which requires running a local bind. It does not yet support/use the AD bit. The question is, where should the DNSSEC code be and where should the cache be? Assuming something like the above is added, we have the following choices: 1) dnssec resolver using a more generic query to localhost from openswan 2) using stubunbound or similar, and move the resolver/cache into openswan 3) using ldns with callbacks (no cache?) Currently, openswan accepts host keys from DNS even if no DNSSEC is present. This will be changed to require DNSSEC, meaning we need to have some confidence that we obtained this data securely, including the currently "undetectable last mile". With Opportunistic Encryption enabled, there could be quite some caching overlap with over applications (eg firefox) doing something similar by validating data in the same zone with the same DNSKEY's, for instance when firefox would support the new DANE draft: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1 Though hooking up libunbound would protect us from weird system resolver settings and insecurities. But apps like Openswan and Firefox would be doing a lot of repeat work. Advise? Thoughts? In general, to get back a little to Miek's question is, do you really want callbacks with ldns, or would you be better of using ldns indirectly via libunbound or friends? Paul From miek at miek.nl Wed Dec 15 11:53:24 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 12:53:24 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <4D078495.7000802@nlnetlabs.nl> References: <20101214131018.GA15432@miek.nl> <4D078495.7000802@nlnetlabs.nl> Message-ID: <20101215115324.GA19426@miek.nl> [ Quoting Wouter Wijngaards in "Re: [ldns-users] function call back"... ] > Hoi Miek, Hallo, > Well, asynchronous means another thread or process is working on the > query. And ldns does not do that. True, but with callbacks you can fire off multiple requests and then wait for a reply from one of them. Currently this is hard to do because ldns_resolver_send* hides all this. I'm not proposing to make ldns into a threaded library, we have libunbound for that, I'm asking for a way to seperate the send and receive in ldns. > It is not viable (for ldns itself). libunbound gives you a callback > that gives the packet wiredata from unbound, it handles the threads, Do callbacks imply threads? (I thought not, but I may be wrong). grtz, Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From miek at miek.nl Wed Dec 15 12:14:43 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 13:14:43 +0100 Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: References: <20101214131018.GA15432@miek.nl> Message-ID: <20101215121443.GB19426@miek.nl> [ Quoting Paul Wouters in "Re: [ldns-users] function call back"... ] > [somewhat stealing this thread, apologies] > > This reminds me of a design decision we have to make (but postponed). That is > to add better DNSSEC support to Openswan. It currently supports the bind lwres{} > interface, which requires running a local bind. It does not yet support/use the > AD bit. [SNIP] > with over applications (eg firefox) doing something similar by validating data in > the same zone with the same DNSKEY's, for instance when firefox would support the > new DANE draft: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/?include_text=1 > > Advise? Thoughts? my 0.02 eur My current view is the following. I think we should seperate the two processes: o normal (plain DNS) resolving o DNSSEC validation So any app. just uses the DNS as it always has done and displays that information (a dns packet, a webpage, whatever) to the user. When security is needed, extra lookups are performed and the crypto is checked. And when this dane-protocol works you can check that too. With this info you can then create a colored lock symbol. So the way forward would be to use libunbound IMHO and create only two functions: o is_this_secure(DNSKEY record), gives back yes/no, checks the chain o is_this_secure_dane(SSL cert), gives back yes/no, uses the dane protocol And create a fancy gui library for colored images of locks. grtz, -- Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wouter at NLnetLabs.nl Wed Dec 15 12:02:48 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Wed, 15 Dec 2010 13:02:48 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <20101215115324.GA19426@miek.nl> References: <20101214131018.GA15432@miek.nl> <4D078495.7000802@nlnetlabs.nl> <20101215115324.GA19426@miek.nl> Message-ID: <4D08AE68.1060503@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi Miek, On 12/15/2010 12:53 PM, Miek Gieben wrote: > [ Quoting Wouter Wijngaards in "Re: [ldns-users] function call back"... ] > True, but with callbacks you can fire off multiple requests and then > wait for a reply from one of them. > Currently this is hard to do because ldns_resolver_send* hides all this. > > I'm not proposing to make ldns into a threaded library, we have > libunbound for that, I'm asking for a way to seperate the send and > receive in ldns. > >> It is not viable (for ldns itself). libunbound gives you a callback >> that gives the packet wiredata from unbound, it handles the threads, > > Do callbacks imply threads? (I thought not, but I may be wrong). Well asynchronous implies threads. You want something that resolves an array of 5 queries at the same time, and it finishes when they are all done? That is still a fair amount of work. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0IrmgACgkQkDLqNwOhpPgc0ACdEjkdGxJ1XgCAaLy6OF4L86Uh dpMAoLNSBXNUdOgQUECp29zNyuudzqMK =D7RB -----END PGP SIGNATURE----- From miek at miek.nl Wed Dec 15 14:31:20 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 15:31:20 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <4D08AE68.1060503@nlnetlabs.nl> References: <20101214131018.GA15432@miek.nl> <4D078495.7000802@nlnetlabs.nl> <20101215115324.GA19426@miek.nl> <4D08AE68.1060503@nlnetlabs.nl> Message-ID: <20101215143120.GC19426@miek.nl> [ Quoting Wouter Wijngaards in "Re: [ldns-users] function call back"... ] > > Do callbacks imply threads? (I thought not, but I may be wrong). > > Well asynchronous implies threads. You want something that resolves an > array of 5 queries at the same time, and it finishes when they are all done? > > That is still a fair amount of work. true. If I can find some time (en zin) for this I might try to implement something. grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wouter at NLnetLabs.nl Wed Dec 15 16:04:56 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Wed, 15 Dec 2010 17:04:56 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <20101215143120.GC19426@miek.nl> References: <20101214131018.GA15432@miek.nl> <4D078495.7000802@nlnetlabs.nl> <20101215115324.GA19426@miek.nl> <4D08AE68.1060503@nlnetlabs.nl> <20101215143120.GC19426@miek.nl> Message-ID: <4D08E728.4070809@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi Miek, On 12/15/2010 03:31 PM, Miek Gieben wrote: > [ Quoting Wouter Wijngaards in "Re: [ldns-users] function call back"... ] > If I can find some time (en zin) for this I might try to implement > something. Interesting, but you could also do several libunbound ub_resolve_async calls (with a callback), and then ub_wait(ctx) for them to finish. For a large capacity you may have to twiddle libunbound's allowed socketcount by the way (ub_ctx_set_option("outgoing-range:", "1024")), by default it stays small. This may save you the work (unless you need something different). Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0I5ygACgkQkDLqNwOhpPgiDwCgp4sY5Mxh/DBlK7nmTTeCKiRm wLUAniLr1v+vuRrQoJOXJwEPZRoOdIT3 =/wQf -----END PGP SIGNATURE----- From paul at xelerance.com Wed Dec 15 16:09:48 2010 From: paul at xelerance.com (Paul Wouters) Date: Wed, 15 Dec 2010 11:09:48 -0500 (EST) Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: <20101215121443.GB19426@miek.nl> References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> Message-ID: On Wed, 15 Dec 2010, Miek Gieben wrote: > My current view is the following. I think we should seperate the two > processes: > o normal (plain DNS) resolving > o DNSSEC validation > > So any app. just uses the DNS as it always has done and displays that > information (a dns packet, a webpage, whatever) to the user. When > security is needed, extra lookups are performed and the crypto is > checked. And when this dane-protocol works you can check that too. I assume you do mean that spoofed answers give a servfail and you go investigate? > With this info you can then create a colored lock symbol. > > So the way forward would be to use libunbound IMHO and create > only two functions: > > o is_this_secure(DNSKEY record), gives back yes/no, checks the chain > o is_this_secure_dane(SSL cert), gives back yes/no, uses the dane protocol In the case of firefox, I think what is going to happen is that DANE based cert/keys are going to be treated as DV certificates, and their validation forks based on the equivalent of using both is_this_secure() and is_this_secure_dane(). Additionally, if any cert info is filled in (eg CN, O, OU) then since they might present it to the user, they also want to validate that, so they need to walk the CA path as well. So for DANE based certs, it is best to leave all of that empty. Hoever, my question was more, where does the validating code and cache live? Should openswan keep caches of the DNSKEYs in their lookup mechanism? Should it do validation? Should it just trust the AD bit if resolver is localhost and use a local resolver, or something in between like evldns/stubunbound where most of the "resolver" is linked into openswan. Keeping the validating resolver within openswan protects against bad resolvers on the host, at the expense of sharing the cache, which if any other application does similar resolves, ends up with duplicated caches of infrastructure lookups. In short, should openswan link a secure resolver library and cache, or trust the AD bit on localhost? (or other last mile solution IETF comes up with) Paul From miek at miek.nl Wed Dec 15 20:53:18 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 21:53:18 +0100 Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> Message-ID: <20101215205318.GA17427@miek.nl> [ Quoting Paul Wouters in "Re: DNSSEC (was Re: [ldns-users] fu"... ] > >So any app. just uses the DNS as it always has done and displays that > >information (a dns packet, a webpage, whatever) to the user. When > >security is needed, extra lookups are performed and the crypto is > >checked. And when this dane-protocol works you can check that too. > > I assume you do mean that spoofed answers give a servfail and you go investigate? No, I mean: do an insecure lookup > >o is_this_secure(DNSKEY record), gives back yes/no, checks the chain > >o is_this_secure_dane(SSL cert), gives back yes/no, uses the dane protocol > > In the case of firefox, I think what is going to happen is that DANE based cert/keys > are going to be treated as DV certificates, and their validation forks based on the > equivalent of using both is_this_secure() and is_this_secure_dane(). Additionally, if > any cert info is filled in (eg CN, O, OU) then since they might present it to the user, > they also want to validate that, so they need to walk the CA path as well. So for > DANE based certs, it is best to leave all of that empty. > > Hoever, my question was more, where does the validating code and cache live? Should > openswan keep caches of the DNSKEYs in their lookup mechanism? Should it do validation? Just use the local resolver, but don't trust it. The DNSSEC validation should happen in openswan. > Keeping the validating resolver within openswan protects against bad resolvers on the > host, at the expense of sharing the cache, which if any other application does similar > resolves, ends up with duplicated caches of infrastructure lookups. ... and how bad would that be? > In short, should openswan link a secure resolver library and cache, or trust the AD bit > on localhost? (or other last mile solution IETF comes up with) use the local resolver dont trust the local resolver do the validation yourself -- Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From miek at miek.nl Wed Dec 15 20:54:23 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 21:54:23 +0100 Subject: [ldns-users] function call backs in ldns_resolver_send*? In-Reply-To: <4D08E728.4070809@nlnetlabs.nl> References: <20101214131018.GA15432@miek.nl> <4D078495.7000802@nlnetlabs.nl> <20101215115324.GA19426@miek.nl> <4D08AE68.1060503@nlnetlabs.nl> <20101215143120.GC19426@miek.nl> <4D08E728.4070809@nlnetlabs.nl> Message-ID: <20101215205423.GB17427@miek.nl> [ Quoting Wouter Wijngaards in "Re: [ldns-users] function call back"... ] > Interesting, but you could also do several libunbound ub_resolve_async > calls (with a callback), and then ub_wait(ctx) for them to finish. For > a large capacity you may have to twiddle libunbound's allowed > socketcount by the way (ub_ctx_set_option("outgoing-range:", "1024")), > by default it stays small. This may save you the work (unless you need > something different). nice. Thanks for extra nudge towards libunbound :-) grtz, -- Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From paul at xelerance.com Wed Dec 15 21:00:57 2010 From: paul at xelerance.com (Paul Wouters) Date: Wed, 15 Dec 2010 16:00:57 -0500 (EST) Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: <20101215205318.GA17427@miek.nl> References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> <20101215205318.GA17427@miek.nl> Message-ID: On Wed, 15 Dec 2010, Miek Gieben wrote: > No, I mean: do an insecure lookup Eww. I hope we can move away from that completely :P >> In short, should openswan link a secure resolver library and cache, or trust the AD bit >> on localhost? (or other last mile solution IETF comes up with) > > use the local resolver > dont trust the local resolver > do the validation yourself If you do validation yourself, I guess you also have to cache yourself? So then I guess stubunbound should be used? or just libunbound and take the hit from talking repeatedly to the local resolver cache? Would implementing either be very different? Can we do libunbound first and stubunbound later? Wouter? :) Paul From paul at xelerance.com Wed Dec 15 21:03:05 2010 From: paul at xelerance.com (Paul Wouters) Date: Wed, 15 Dec 2010 16:03:05 -0500 (EST) Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> <20101215205318.GA17427@miek.nl> Message-ID: On Wed, 15 Dec 2010, Paul Wouters wrote: >> use the local resolver >> dont trust the local resolver >> do the validation yourself > > If you do validation yourself, I guess you also have to cache yourself? Additionally, you have to figure out where to put the trust anchors. If you can't trust the local resolver to validate, you can't trust it for its trust anchors either. Would openswan need an option to load trust anchors? Not sure I like the way this is going :P Paul From miek at miek.nl Wed Dec 15 21:15:54 2010 From: miek at miek.nl (Miek Gieben) Date: Wed, 15 Dec 2010 22:15:54 +0100 Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> <20101215205318.GA17427@miek.nl> Message-ID: <20101215211554.GA21934@miek.nl> [ Quoting Paul Wouters in "Re: [ldns-users] DNSSEC (was Re: fu"... ] > On Wed, 15 Dec 2010, Paul Wouters wrote: > > >>use the local resolver > >>dont trust the local resolver > >>do the validation yourself > > > >If you do validation yourself, I guess you also have to cache yourself? > > Additionally, you have to figure out where to put the trust anchors. If you > can't trust the local resolver to validate, you can't trust it for its > trust anchors either. Would openswan need an option to load trust anchors? > > Not sure I like the way this is going :P Still not sure what advise I should give to openswan, but to give some more background on why I'm advocating insecure loopups. My gut feeling currently tells me (this could of course change of time :-) ), that there is going to be a difference in "doing a lookup" and "validating some info (most key-related data) from the DNS". And the primary reason for this is feedback to the user - if all the feedback you can give is SERVFAIL, people will turn off DNSSEC and re-query. If your app. can *show* the data *and* tell it is not secure, you mimic the current situation with ssl certificates (in browsers). grtz Miek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From wouter at NLnetLabs.nl Thu Dec 16 08:25:52 2010 From: wouter at NLnetLabs.nl (W.C.A. Wijngaards) Date: Thu, 16 Dec 2010 09:25:52 +0100 Subject: [ldns-users] DNSSEC (was Re: function call backs in ldns_resolver_send*?) In-Reply-To: References: <20101214131018.GA15432@miek.nl> <20101215121443.GB19426@miek.nl> <20101215205318.GA17427@miek.nl> Message-ID: <4D09CD10.607@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Paul, On 12/15/2010 10:03 PM, Paul Wouters wrote: > On Wed, 15 Dec 2010, Paul Wouters wrote: > >>> use the local resolver >>> dont trust the local resolver >>> do the validation yourself >> >> If you do validation yourself, I guess you also have to cache yourself? > > Additionally, you have to figure out where to put the trust anchors. If you > can't trust the local resolver to validate, you can't trust it for its > trust anchors either. Would openswan need an option to load trust anchors? The trust anchor can be stored in /etc/root.anchor or /etc/root.key or a similar name (check compat with bind installs). At system boot time you can run unbound-anchor to make this file a valid root trust anchor. Then you can load it in unbound, or in a libunbound instance (with auto-trust-anchor-file: /etc/unbound.root.anchor option). This way you can distribute keys to all apps. But note that if your machine is up for a long time, the key may go stale. You would need a cron-job with unbound-anchor or running the unbound daemon to keep the key up-to-date. (cron every week or so). > Not sure I like the way this is going :P > Would implementing either be very different? Can we do libunbound first and > stubunbound later? Wouter? So, libunbound resolves exactly like libunbound. You can use both (have libunbound forward towards 127.0.0.1 and validate itself). libunbound does what Miek says: it always gives you an answer, but sets the 'bogus' flag if it is bogus. (and 'secure' if it is secure). If it is bogus you get a string with text what happened. Best regards, Wouter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0JzRAACgkQkDLqNwOhpPjNoQCgkr6Ifc0qkJXoR+tTnbWH3/TK 2sMAoJq1DpZCOVpam8oF/L7Bpq03MRyG =cuCs -----END PGP SIGNATURE-----