<div dir="ltr">I strongly agree to this proposed change and have added some comments inline below...<div><br></div><div><div id=":17k" dir="ltr" class="" style="font-size:12.8px">Also, I would like to propose something analogous to the errno or the Windows function GetLastError() </div><div id=":17j" dir="ltr" class="" style="font-size:12.8px">where if the user desires, they can get a more detailed description, either as a string or a dict, in addition to the below. </div><div id=":17j" class="" style="font-size:12.8px">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. </div><div id=":17j" dir="ltr" class="" style="font-size:12.8px"><br></div><div id=":17j" class="" style="font-size:12.8px">Gowri</div><div id=":17j" dir="ltr" class="" style="font-size:12.8px"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 8:21 AM, Sara Dickinson <span dir="ltr"><<a href="mailto:sara@sinodun.com" target="_blank">sara@sinodun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"><div><font color="#000000">Hi All,</font></div><div><br></div><div>Willem and I have been discussing the error handling in getdns and would like to propose some changes based on our implementation experience. </div><div><br></div><div>1) Asynchronous error handling</div><div><br></div><div>At the moment the async callbacks are specified as below:<br><div><br></div><div><div style="margin:0px 0px 0px 2em;font-family:monospace;font-weight:bold;color:rgb(51,51,51);font-size:14px;line-height:20px;background-color:rgb(255,255,255)">GETDNS_CALLBACK_COMPLETE</div><div style="margin:0px 0px 0px 4em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px;background-color:rgb(255,255,255)">The response has the requested data in it</div><div style="margin:0px 0px 0px 2em;font-family:monospace;font-weight:bold;color:rgb(51,51,51);font-size:14px;line-height:20px;background-color:rgb(255,255,255)">GETDNS_CALLBACK_CANCEL</div><div style="margin:0px 0px 0px 4em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px;background-color:rgb(255,255,255)">The calling program cancelled the callback; response is NULL</div><div style="margin:0px 0px 0px 2em;font-family:monospace;font-weight:bold;color:rgb(51,51,51);font-size:14px;line-height:20px;background-color:rgb(255,255,255)">GETDNS_CALLBACK_TIMEOUT</div><div style="margin:0px 0px 0px 4em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px;background-color:rgb(255,255,255)">The requested action timed out; response is filled in with empty structures</div></div><div><div style="margin:0px 0px 0px 2em;font-family:monospace;font-weight:bold;color:rgb(51,51,51);font-size:14px;line-height:20px;background-color:rgb(255,255,255)">GETDNS_CALLBACK_ERROR</div><div style="margin:0px 0px 0px 4em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px;background-color:rgb(255,255,255)">The requested action had an error; response is NULL</div></div><div><br></div><div><br></div><div>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.  </div><div>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. </div><div><br></div><div>We would like to propose that the ERROR case is changed to have the same response as the TIMEOUT case i.e:</div><div><br></div><div><div style="margin:0px 0px 0px 2em;font-family:monospace;font-weight:bold;color:rgb(51,51,51);font-size:14px;line-height:20px;background-color:rgb(255,255,255)">GETDNS_CALLBACK_ERROR</div><div style="margin:0px 0px 0px 4em;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,Arial,sans-serif;font-size:14px;line-height:20px;background-color:rgb(255,255,255)">The requested action had an error; response is filled in with empty structures</div></div><div><br></div><div>And so the response structure would look similar to this example for a TIMEOUT:</div><div><br></div><div><div>{</div><div>  "answer_type": GETDNS_NAMETYPE_DNS,</div><div>  "replies_full": [],</div><div>  "replies_tree": [],</div><div>  "status": GETDNS_RESPSTATUS_ALL_TIMEOUT</div><div>}</div><div><br></div></div><div>2) New GETDNS_RESPSTATUS codes</div><div><br></div><div>The new GETDNS_RESPSTATUS_ error cases we would like to add at this time are:</div><div><br></div><div><div>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).</div><div><br></div></div><div>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)).</div></div></div></div></div></blockquote><div><br></div><div><br></div><div>I suggest even more detailed reporting for the above, eg. <span style="font-size:12.8px">TLS_FEATURE_NOT</span><span style="font-size:12.8px">_SUPPORTED_TLS1</span><span style="font-size:12.8px">2_NOT AVAILABLE and other errors where possible.</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"><div><div><br></div><div>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.</div><div><br></div><div>3) Synchronous timeouts</div><div><br></div><div>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. </div><div><br></div><div>As a future activity we note that the above mechanisms can only relay a single error code. Since completing an API call can involve</div><div>- performing multiple DNS queries</div><div>- using multiple upstreams</div><div>- using multiple transports</div><div>- TLS authentication that can fail for various reasons</div><div>- DNSSEC validations</div><div>- TSIG validation</div><div>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. </div></div></div></div></div></blockquote><div><br></div><div><br></div><div>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?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div style="word-wrap:break-word"><div><span class=""><font color="#888888"><div><br></div><div>Sara. </div><div><br></div></font></span></div></div></div><br></div><br>_______________________________________________<br>
spec mailing list<br>
<a href="mailto:spec@getdnsapi.net">spec@getdnsapi.net</a><br></blockquote></div><br></div></div></div>