From dkg at fifthhorseman.net Tue Jan 5 05:47:18 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 05 Jan 2016 00:47:18 -0500 Subject: [getdns-users] getdns 0.9.0 released In-Reply-To: <568531B2.3060603@nlnetlabs.nl> References: <568531B2.3060603@nlnetlabs.nl> Message-ID: <87a8oky3vd.fsf@alice.fifthhorseman.net> On Thu 2015-12-31 08:46:26 -0500, Willem Toorop wrote: > We have a special New Year's Eve release, version 0.9.0 of getdns. This was uploaded into debian unstable earlier today, thanks to Ond?ej Sur?. It should be available on the mirrors now! --dkg From shollenbeck at verisign.com Thu Jan 7 15:05:54 2016 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu, 7 Jan 2016 15:05:54 +0000 Subject: [getdns-users] getdns 0.9.0 released In-Reply-To: <568531B2.3060603@nlnetlabs.nl> References: <568531B2.3060603@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A127388@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, December 31, 2015 8:46 AM > To: libgetdns users list > Subject: [getdns-users] getdns 0.9.0 released > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear All, > > We have a special New Year's Eve release, version 0.9.0 of getdns. Willem, I'm doing some testing with this release and I just ran into a segmentation fault situation when running getdns_pubkey_pin_create_from_string(). Guess what happens when the str parameter is NULL and the strncmp functions attempts to compare it to PIN_PREFIX? Scott From sara at sinodun.com Thu Jan 7 16:46:54 2016 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 7 Jan 2016 16:46:54 +0000 Subject: [getdns-users] getdns 0.9.0 released In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A127388@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <568531B2.3060603@nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F4A127388@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: <2FF758B9-131C-4AA4-AE05-FB3BC9C4C5E7@sinodun.com> > On 7 Jan 2016, at 15:05, Hollenbeck, Scott wrote: > >> -----Original Message----- >> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem >> Toorop >> Sent: Thursday, December 31, 2015 8:46 AM >> To: libgetdns users list >> Subject: [getdns-users] getdns 0.9.0 released >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Dear All, >> >> We have a special New Year's Eve release, version 0.9.0 of getdns. > > Willem, I'm doing some testing with this release and I just ran into a segmentation fault situation when running getdns_pubkey_pin_create_from_string(). Guess what happens when the str parameter is NULL and the strncmp functions attempts to compare it to PIN_PREFIX? Ouch. I?ll put a fix in develop today. Apologies - this was missed in the testing which was only done via getdns_query which does additional checking! Will add a unit test. Sara. From dkg at fifthhorseman.net Fri Jan 8 01:36:12 2016 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 07 Jan 2016 17:36:12 -0800 Subject: [getdns-users] dropping GETDNS_TRANSPORT_STARTTLS is backward-incompatible API change in 0.9.0 Message-ID: <8760z47sz7.fsf@alice.fifthhorseman.net> Hi folks-- in https://bugs.debian.org/810260, we're seeing a build failure for python-getdns 0.5.0 against libgetdns 0.9.0. I think this is due to the removal of the GETDNS_TRANSPORT_STARTTLS definition, which is a backward-incompatible change to the API. I see two fixes: (a) bump the SONAME (b) make a 0.9.1 release with the definition in place, but have 0.9.1 return an error if anyone tries to use it (b) seems simpler, and i think we have more incomaptible API changes coming up, so i'm reluctant to bump the SONAME twice in rapid succession (but maybe that doesn't matter so much?) --dkg From melinda.shore at nomountain.net Fri Jan 8 02:24:48 2016 From: melinda.shore at nomountain.net (Melinda Shore) Date: Thu, 7 Jan 2016 17:24:48 -0900 Subject: [getdns-users] dropping GETDNS_TRANSPORT_STARTTLS is backward-incompatible API change in 0.9.0 In-Reply-To: <8760z47sz7.fsf@alice.fifthhorseman.net> References: <8760z47sz7.fsf@alice.fifthhorseman.net> Message-ID: <568F1DF0.4060302@nomountain.net> Hi, Daniel: Thanks for the report. I'm in the process of getting another release of the Python bindings out, and I'm conditionalizing that out, depending on the libgetdns version. (Once the API stabilizes I can start getting rid of the ocean of #ifs in the Python binding code). The new bindings should be out by Monday. Melinda From willem at nlnetlabs.nl Fri Jan 8 10:46:43 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 8 Jan 2016 11:46:43 +0100 Subject: [getdns-users] dropping GETDNS_TRANSPORT_STARTTLS is backward-incompatible API change in 0.9.0 In-Reply-To: <8760z47sz7.fsf@alice.fifthhorseman.net> References: <8760z47sz7.fsf@alice.fifthhorseman.net> Message-ID: <568F9393.3050302@nlnetlabs.nl> Op 08-01-16 om 02:36 schreef Daniel Kahn Gillmor: > Hi folks-- > > in https://bugs.debian.org/810260, we're seeing a build failure for > python-getdns 0.5.0 against libgetdns 0.9.0. > > I think this is due to the removal of the GETDNS_TRANSPORT_STARTTLS > definition, which is a backward-incompatible change to the API. > > I see two fixes: > > (a) bump the SONAME > > (b) make a 0.9.1 release with the definition in place, but have 0.9.1 > return an error if anyone tries to use it > > (b) seems simpler, and i think we have more incomaptible API changes > coming up, so i'm reluctant to bump the SONAME twice in rapid succession > (but maybe that doesn't matter so much?) I also prefer (b). It would also be an opportunity to use a safer append_name default value (and then try to get the spec on par with that later on). -- Willem > > > --dkg > _______________________________________________ > Users mailing list > Users at getdnsapi.net > http://getdnsapi.net/mailman/listinfo/users > From shollenbeck at verisign.com Fri Jan 15 12:38:57 2016 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Fri, 15 Jan 2016 12:38:57 +0000 Subject: [getdns-users] getdns 0.9.0 released In-Reply-To: <568531B2.3060603@nlnetlabs.nl> References: <568531B2.3060603@nlnetlabs.nl> Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A12DE31@BRN1WNEXMBX01.vcorp.ad.vrsn.com> > -----Original Message----- > From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem > Toorop > Sent: Thursday, December 31, 2015 8:46 AM > To: libgetdns users list > Subject: [getdns-users] getdns 0.9.0 released > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Dear All, > > We have a special New Year's Eve release, version 0.9.0 of getdns. I just committed and pushed updates to the development and master branches for the PHP language bindings. Scott From melinda.shore at nomountain.net Mon Jan 25 03:06:42 2016 From: melinda.shore at nomountain.net (Melinda Shore) Date: Sun, 24 Jan 2016 18:06:42 -0900 Subject: [getdns-users] New Python bindings release Message-ID: <56A59142.9080406@nomountain.net> Hi, all: I've just released v0.6.0 of the getdns Python bindings. This release includes: ? added support for tls public key pinsets to upstream_recursive_server ? added support for tsig ? added getdns.AUTHENTICATION_REQUIRED as a possible value for Context().tls_authentication ? some performance and code improvements ? removed STARTTLS support as it's no longer supported by libgetdns ? changed call_debugging extension name to call_reporting, reflecting changes in libgetdns ? added example code demonstrating use of new features ? --with-edns-cookies build argument removed, since it's now enabled by default ? removed ldns dependency and (of course!) updated documentation. https://github.com/getdnsapi/getdns-python-bindings/releases/tag/v0.6.0 Melinda From sara at sinodun.com Thu Jan 7 13:21:31 2016 From: sara at sinodun.com (Sara Dickinson) Date: Thu, 7 Jan 2016 13:21:31 +0000 Subject: [getdns-api] Error handling in getdns References: Message-ID: Hi All, Willem and I have been discussing the error handling in getdns and would like to propose some changes based on our implementation experience. 1) Asynchronous error handling At the moment the async callbacks are specified as below: GETDNS_CALLBACK_COMPLETE The response has the requested data in it GETDNS_CALLBACK_CANCEL The calling program cancelled the callback; response is NULL GETDNS_CALLBACK_TIMEOUT The requested action timed out; response is filled in with empty structures GETDNS_CALLBACK_ERROR The requested action had an error; response is NULL With this approach there is no mechanism to provide any more fine grained information to the user when an ERROR is return because the response in the callback is NULL. When considering a mainly UDP based approach this is probably sufficient, but to cater for TCP and TLS (with authentication) we would like to change the above so that a variety of errors that can occur that are not timeouts can be communicated to the caller. We would like to propose that the ERROR case is changed to have the same response as the TIMEOUT case i.e: GETDNS_CALLBACK_ERROR The requested action had an error; response is filled in with empty structures And so the response structure would look similar to this example for a TIMEOUT: { "answer_type": GETDNS_NAMETYPE_DNS, "replies_full": [], "replies_tree": [], "status": GETDNS_RESPSTATUS_ALL_TIMEOUT } 2) New GETDNS_RESPSTATUS codes The new GETDNS_RESPSTATUS_ error cases we would like to add at this time are: TRANSPORT_SETUP_FAILED - for the case where no connection could be made over any specified transport to any upstream (for example, only TLS is specified but none of the available upstreams support it). TLS_FEATURE_NOT_SUPPORTED - for the cases where getdns can?t support the configured transport/authentication options at runtime because the available TLS library doesn?t have the required functionality (for example support for TLS 1.2 or hostname verification methods)). TLS_AUTH_FAILED - for the case when using TLS only and authentication is required but fails. This is strictly a sub-case of TRANSPORT_SETUP_FAILED but seems worthy of a separate status code. 3) Synchronous timeouts When calling the API synchronously, the return type of the functions is getdns_return_t. There is currently no value for GETDNS_RETURN_TIMEOUT and the behaviour for the sync calls is not clearly specified for a timeout in the spec. So our implementation currently uses GETDNS_RETURN_GOOD (and returns the response dict as in 1 above), the best alternative error code would be GETDNS_RETURN_GENERIC_ERROR. So we would like to propose adding the value GETDNS_RETURN_TIMEOUT to the getdns_return_t type. As a future activity we note that the above mechanisms can only relay a single error code. Since completing an API call can involve - performing multiple DNS queries - using multiple upstreams - using multiple transports - TLS authentication that can fail for various reasons - DNSSEC validations - TSIG validation we are considering adding an ?error log trail? utility that would be recorded during execution and could be returned in the response dict. Feedback on this is welcomed. Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmadkat1 at gmail.com Thu Jan 7 16:25:08 2016 From: gmadkat1 at gmail.com (Gowri V) Date: Thu, 7 Jan 2016 11:25:08 -0500 Subject: [getdns-api] Error handling in getdns In-Reply-To: References:

Message-ID: I strongly agree to this proposed change and have added some comments inline below... Also, I would like to propose something analogous to the errno or the Windows function GetLastError() where if the user desires, they can get a more detailed description, either as a string or a dict, in addition to the below. This would be useful diagnostics for a developer if any of the lower level socket API calls fail for any reason, currently some of these failures return a generic error. Gowri On Thu, Jan 7, 2016 at 8:21 AM, Sara Dickinson wrote: > Hi All, > > Willem and I have been discussing the error handling in getdns and would > like to propose some changes based on our implementation experience. > > 1) Asynchronous error handling > > At the moment the async callbacks are specified as below: > > GETDNS_CALLBACK_COMPLETE > The response has the requested data in it > GETDNS_CALLBACK_CANCEL > The calling program cancelled the callback; response is NULL > GETDNS_CALLBACK_TIMEOUT > The requested action timed out; response is filled in with empty structures > GETDNS_CALLBACK_ERROR > The requested action had an error; response is NULL > > > With this approach there is no mechanism to provide any more fine grained > information to the user when an ERROR is return because the response in the > callback is NULL. > When considering a mainly UDP based approach this is probably sufficient, > but to cater for TCP and TLS (with authentication) we would like to change > the above so that a variety of errors that can occur that are not timeouts > can be communicated to the caller. > > We would like to propose that the ERROR case is changed to have the same > response as the TIMEOUT case i.e: > > GETDNS_CALLBACK_ERROR > The requested action had an error; response is filled in with empty > structures > > And so the response structure would look similar to this example for a > TIMEOUT: > > { > "answer_type": GETDNS_NAMETYPE_DNS, > "replies_full": [], > "replies_tree": [], > "status": GETDNS_RESPSTATUS_ALL_TIMEOUT > } > > 2) New GETDNS_RESPSTATUS codes > > The new GETDNS_RESPSTATUS_ error cases we would like to add at this time > are: > > TRANSPORT_SETUP_FAILED - for the case where no connection could be made > over any specified transport to any upstream (for example, only TLS is > specified but none of the available upstreams support it). > > TLS_FEATURE_NOT_SUPPORTED - for the cases where getdns can?t support the > configured transport/authentication options at runtime because the > available TLS library doesn?t have the required functionality (for example > support for TLS 1.2 or hostname verification methods)). > I suggest even more detailed reporting for the above, eg. TLS_FEATURE_NOT _SUPPORTED_TLS12_NOT AVAILABLE and other errors where possible. > > TLS_AUTH_FAILED - for the case when using TLS only and authentication is > required but fails. This is strictly a sub-case of TRANSPORT_SETUP_FAILED > but seems worthy of a separate status code. > > 3) Synchronous timeouts > > When calling the API synchronously, the return type of the functions is > getdns_return_t. There is currently no value for GETDNS_RETURN_TIMEOUT and > the behaviour for the sync calls is not clearly specified for a timeout in > the spec. So our implementation currently uses GETDNS_RETURN_GOOD (and > returns the response dict as in 1 above), the best alternative error code > would be GETDNS_RETURN_GENERIC_ERROR. So we would like to propose adding > the value GETDNS_RETURN_TIMEOUT to the getdns_return_t type. > > As a future activity we note that the above mechanisms can only relay a > single error code. Since completing an API call can involve > - performing multiple DNS queries > - using multiple upstreams > - using multiple transports > - TLS authentication that can fail for various reasons > - DNSSEC validations > - TSIG validation > we are considering adding an ?error log trail? utility that would be > recorded during execution and could be returned in the response dict. > Feedback on this is welcomed. > The error log trail utility is a good design pattern to implement for getdns, perhaps add an extension that would return the error log trail in the response dict similar to the return_call_reporting? > > Sara. > > > > _______________________________________________ > spec mailing list > spec at getdnsapi.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Jan 8 11:17:47 2016 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 8 Jan 2016 12:17:47 +0100 Subject: [getdns-api] Error handling in getdns In-Reply-To: References:

Message-ID: <568F9ADB.6030103@redhat.com> On 7.1.2016 17:25, Gowri V wrote: > I strongly agree to this proposed change and have added some comments > inline below... > > Also, I would like to propose something analogous to the errno or the > Windows function GetLastError() > where if the user desires, they can get a more detailed description, either > as a string or a dict, in addition to the below. > This would be useful diagnostics for a developer if any of the lower level > socket API calls fail for any reason, currently some of these failures > return a generic error. > > Gowri > > > On Thu, Jan 7, 2016 at 8:21 AM, Sara Dickinson wrote: > >> Hi All, >> >> Willem and I have been discussing the error handling in getdns and would >> like to propose some changes based on our implementation experience. >> >> 1) Asynchronous error handling >> >> At the moment the async callbacks are specified as below: >> >> GETDNS_CALLBACK_COMPLETE >> The response has the requested data in it >> GETDNS_CALLBACK_CANCEL >> The calling program cancelled the callback; response is NULL >> GETDNS_CALLBACK_TIMEOUT >> The requested action timed out; response is filled in with empty structures >> GETDNS_CALLBACK_ERROR >> The requested action had an error; response is NULL >> >> >> With this approach there is no mechanism to provide any more fine grained >> information to the user when an ERROR is return because the response in the >> callback is NULL. >> When considering a mainly UDP based approach this is probably sufficient, >> but to cater for TCP and TLS (with authentication) we would like to change >> the above so that a variety of errors that can occur that are not timeouts >> can be communicated to the caller. >> >> We would like to propose that the ERROR case is changed to have the same >> response as the TIMEOUT case i.e: >> >> GETDNS_CALLBACK_ERROR >> The requested action had an error; response is filled in with empty >> structures >> >> And so the response structure would look similar to this example for a >> TIMEOUT: >> >> { >> "answer_type": GETDNS_NAMETYPE_DNS, >> "replies_full": [], >> "replies_tree": [], >> "status": GETDNS_RESPSTATUS_ALL_TIMEOUT >> } >> >> 2) New GETDNS_RESPSTATUS codes >> >> The new GETDNS_RESPSTATUS_ error cases we would like to add at this time >> are: >> >> TRANSPORT_SETUP_FAILED - for the case where no connection could be made >> over any specified transport to any upstream (for example, only TLS is >> specified but none of the available upstreams support it). >> >> TLS_FEATURE_NOT_SUPPORTED - for the cases where getdns can?t support the >> configured transport/authentication options at runtime because the >> available TLS library doesn?t have the required functionality (for example >> support for TLS 1.2 or hostname verification methods)). >> > > > I suggest even more detailed reporting for the above, eg. TLS_FEATURE_NOT > _SUPPORTED_TLS12_NOT AVAILABLE and other errors where possible. > > > >> >> TLS_AUTH_FAILED - for the case when using TLS only and authentication is >> required but fails. This is strictly a sub-case of TRANSPORT_SETUP_FAILED >> but seems worthy of a separate status code. >> >> 3) Synchronous timeouts >> >> When calling the API synchronously, the return type of the functions is >> getdns_return_t. There is currently no value for GETDNS_RETURN_TIMEOUT and >> the behaviour for the sync calls is not clearly specified for a timeout in >> the spec. So our implementation currently uses GETDNS_RETURN_GOOD (and >> returns the response dict as in 1 above), the best alternative error code >> would be GETDNS_RETURN_GENERIC_ERROR. So we would like to propose adding >> the value GETDNS_RETURN_TIMEOUT to the getdns_return_t type. >> >> As a future activity we note that the above mechanisms can only relay a >> single error code. Since completing an API call can involve >> - performing multiple DNS queries >> - using multiple upstreams >> - using multiple transports >> - TLS authentication that can fail for various reasons >> - DNSSEC validations >> - TSIG validation >> we are considering adding an ?error log trail? utility that would be >> recorded during execution and could be returned in the response dict. >> Feedback on this is welcomed. >> > > > The error log trail utility is a good design pattern to implement for > getdns, perhaps add an extension that would return the error log trail in > the response dict similar to the return_call_reporting? I support this idea. More detailed errors the better :-) -- Petr Spacek @ Red Hat From oriol292 at gmail.com Mon Jan 11 14:39:57 2016 From: oriol292 at gmail.com (=?UTF-8?Q?oriol_ca=C3=B1o?=) Date: Mon, 11 Jan 2016 15:39:57 +0100 Subject: [getdns-api] Fwd: TLSA record In-Reply-To: References: Message-ID: Hello, I am using the getdns API to get a TLSA record. However, I couldn't find how to parse the bindata of the certificate_association_data into something usable. Is there any function that translates the bindata into the record itself? Thanks a lot for your time, Oriol Ca?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From willem at nlnetlabs.nl Tue Jan 12 10:00:00 2016 From: willem at nlnetlabs.nl (Willem Toorop) Date: Tue, 12 Jan 2016 11:00:00 +0100 Subject: [getdns-api] Fwd: TLSA record In-Reply-To: References:

Message-ID: <5694CEA0.3080701@nlnetlabs.nl> Hi Oriol, Op 11-01-16 om 15:39 schreef oriol ca?o: > Hello, > > I am using the getdns API to get a TLSA record. > > However, I couldn't find how to parse the bindata of the > certificate_association_data into something usable. You can use that TLSA rdata to authenticate an TLS connection, for example with the functions of the upcoming version 1.1.0 of openssl. See: https://www.openssl.org/docs/manmaster/ssl/SSL_dane_enable.html -- Willem > Is there any function that translates the bindata into the record itself > > Thanks a lot for your time, > > Oriol Ca?o > > > > > _______________________________________________ > spec mailing list > spec at getdnsapi.net > From melinda.shore at nomountain.net Wed Jan 13 15:58:33 2016 From: melinda.shore at nomountain.net (Melinda Shore) Date: Wed, 13 Jan 2016 06:58:33 -0900 Subject: [getdns-api] Fwd: TLSA record In-Reply-To: References:

Message-ID: <56967429.9010900@nomountain.net> Hi, Oriol: If this helps, we've got sample Python code that will pull the certificate out of a set of returned records and do some basic checks using Python crypto libraries (and those are basically wrappers around OpenSSL functions). I believe someone has implemented something similar in C but I'm not sure where the code is. Please let us know if you've got questions. The code is here: https://github.com/getdnsapi/getdns-python-bindings/blob/master/examples/checkdanecert.py Melinda From robert.groenenberg at broadforward.com Tue Jan 26 15:42:15 2016 From: robert.groenenberg at broadforward.com (Robert Groenenberg) Date: Tue, 26 Jan 2016 16:42:15 +0100 Subject: [getdns-api] Upstream servers Message-ID: <56A793D7.5000206@broadforward.com> Hi, I am looking into using getdns for doing ENUM queries from an application. Based on the examples I've build a small test application which works Ok as a stub resolver doing a query to a configured upstream server. According to the API doc (http://getdnsapi.org/spec.html#8.7) a /list/ of upstream servers can be configured. I would expect that when the first server does not respond, the next one is queried. However, I found that whatever the number of upstream servers configured only the first is ever used (verified with tcpdump/wireshark), no matter what the response (or lack thereof) from that first server is. This is the configuration of my context: { "all_context": { "append_name": GETDNS_APPEND_NAME_ALWAYS, "dns_transport_list": [ GETDNS_TRANSPORT_UDP, GETDNS_TRANSPORT_TCP ], "dnssec_allowed_skew": 0, "edns_do_bit": 0, "edns_extended_rcode": 0, "edns_version": 0, "follow_redirects": GETDNS_REDIRECTS_FOLLOW, "limit_outstanding_queries": 0, "namespaces": [ GETDNS_NAMESPACE_LOCALNAMES, GETDNS_NAMESPACE_DNS ], "suffix": [], "timeout": 200, "tls_authentication": GETDNS_AUTHENTICATION_NONE, "upstream_recursive_servers": [ { "address_data": , "address_type": , "tls_port": 853 }, { "address_data": , "address_type": , "tls_port": 853 }, { "address_data": , "address_type": , "tls_port": 853 } ] }, "implementation_string": , "resolution_type": GETDNS_RESOLUTION_STUB, "version_string": } Did I miss something here? For the query itself I use getdns_general(), e.g.: if ((r = getdns_general(context, "8.1.2.7.5.9.3.4.1.1.3.e164.test.net.", GETDNS_RRTYPE_NAPTR, extensions, userarg, &transaction_id, callback))) fprintf(stderr, "Error scheduling request: %s (%d)\n", getdns_get_errorstr_by_id(r), r); Is there some way to configure multiple servers where on a timeout the next one is tried? Cheers, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From sara at sinodun.com Tue Jan 26 16:16:37 2016 From: sara at sinodun.com (Sara Dickinson) Date: Tue, 26 Jan 2016 16:16:37 +0000 Subject: [getdns-api] Upstream servers In-Reply-To: <56A793D7.5000206@broadforward.com> References: <56A793D7.5000206@broadforward.com> Message-ID: > On 26 Jan 2016, at 15:42, Robert Groenenberg wrote: > > Hi, > > I am looking into using getdns for doing ENUM queries from an application. Based on the examples I've build a small test application which works Ok as a stub resolver doing a query to a configured upstream server. > > According to the API doc (http://getdnsapi.org/spec.html#8.7 ) a list of upstream servers can be configured. I would expect that when the first server does not respond, the next one is queried. However, I found that whatever the number of upstream servers configured only the first is ever used (verified with tcpdump/wireshark), no matter what the response (or lack thereof) from that first server is. Hi Robert, The timeout associated with the context is the total timeout to get an answer for the query. In the current implementation when using UDP, the same value is used to wait for a response from a particular upstream, so the first query on a context will use the first upstream and timeout the API call if no response is received within that time. For a particular context getdns does use the upstreams in order, however if 2 timeouts are received from a particular upstream then a 'back-off' is put in place and the next upstream is used until the 'back-off' has expired and then the failed upstream is tried again. So if you re-try timed out queries on the same context you should see this behaviour. (Note: TCP/TLS is a little different because if a problem is detected when trying to perform the handshake then the next server is tried immediately as long as the overall timeout hasn?t expired). We have had discussions about how to improve this, for example, letting the user specify the individual timeout for an upstream to respond and the total time they are willing to wait, but just haven?t got around to making the change. If you (or others) have ideas for the API change/algorithm to support this, please let us know. Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.groenenberg at broadforward.com Tue Jan 26 17:00:11 2016 From: robert.groenenberg at broadforward.com (Robert Groenenberg) Date: Tue, 26 Jan 2016 18:00:11 +0100 Subject: [getdns-api] Upstream servers In-Reply-To: References: <56A793D7.5000206@broadforward.com> Message-ID: <56A7A61B.1000107@broadforward.com> Hi Sara, Thanks for the explanation. Just my luck: I did try two queries, should have done another one ;-) Indeed, the third query uses the next server, great! I understand the problem; configuring a timeout per upstream server seems most logical. If I think of something else I'll let you know. Cheers, Robert On 26-01-16 17:16, Sara Dickinson wrote: > >> On 26 Jan 2016, at 15:42, Robert Groenenberg >> > > wrote: >> >> Hi, >> >> I am looking into using getdns for doing ENUM queries from an >> application. Based on the examples I've build a small test >> application which works Ok as a stub resolver doing a query to a >> configured upstream server. >> >> According to the API doc (http://getdnsapi.org/spec.html#8.7) a >> /list/ of upstream servers can be configured. I would expect that >> when the first server does not respond, the next one is queried. >> However, I found that whatever the number of upstream servers >> configured only the first is ever used (verified with >> tcpdump/wireshark), no matter what the response (or lack thereof) >> from that first server is. > > Hi Robert, > > The timeout associated with the context is the total timeout to get an > answer for the query. In the current implementation when using UDP, > the same value is used to wait for a response from a particular > upstream, so the first query on a context will use the first upstream > and timeout the API call if no response is received within that time. > > For a particular context getdns does use the upstreams in order, > however if 2 timeouts are received from a particular upstream then a > 'back-off' is put in place and the next upstream is used until the > 'back-off' has expired and then the failed upstream is tried again. So > if you re-try timed out queries on the same context you should see > this behaviour. > > (Note: TCP/TLS is a little different because if a problem is detected > when trying to perform the handshake then the next server is tried > immediately as long as the overall timeout hasn?t expired). > > We have had discussions about how to improve this, for example, > letting the user specify the individual timeout for an upstream to > respond and the total time they are willing to wait, but just haven?t > got around to making the change. If you (or others) have ideas for the > API change/algorithm to support this, please let us know. > > Regards > > Sara. > -------------- next part -------------- An HTML attachment was scrubbed... URL: