This would make a perfect sense if all resolvers provided most of their codes 
very close to general DNS RCODEs with a very small resolver-specific set 
"Reserved for Private Use".
But this is not the case, as far as I can tell, and the resolvers never 
intended to return status codes close to DNS RCODEs.

The getaddrinfo() error codes are very resolver-specific, and on Windows there 
is also an OS-specific subset of errors obtained via WSAGetLastError().
So, most of the codes returned by the resolvers will be "Reserved for Private 
Use", with a very tiny subset from some specific resolvers that can be probably 
mapped into common DNS RCODEs.

This makes creating and maintaining such mapping not very useful.
And any changes in some resolver status codes will require changes in libcurl 
to maintain the mapping up to date.
For many different libcurl+resolver combinations it will become a maintenance 
problem very soon.

When I proposed the CURLINFO_RESOLVER_CODE info option, the main purpose was to 
help developers to debug resolver-specific issues, when something goes wrong 
and “opaque” resolver code in case of errors would be a good hint (regardless 
of whether it is a common DNS problem or some internal resolver issue).
From that perspective, any mapping hiding the resolver code will require 
additional operation from the developer to do “unmapping” in libcurl first to 
get to the actual resolver code.

So, a very simple info option, like CURLINFO_RESOLVER_CODE returning a resolver 
status code “as is” provides useful debugging information needed to debug 
resolver issues but without any maintenance cost on libcurl side.

Thanks,
Dmitry

From: curl-library <curl-library-boun...@lists.haxx.se> On Behalf Of Timothe 
Litt via curl-library
Sent: Wednesday, April 20, 2022 1:34 PM
To: curl-library@lists.haxx.se
Cc: Timothe Litt <l...@acm.org>
Subject: Re: Feature request about curlinfo option returning resolver 
status/error code


On 19-Apr-22 18:26, Dan Fandrich via curl-library wrote:

On Tue, Apr 19, 2022 at 04:14:23PM -0400, Timothe Litt via curl-library wrote:

No.  No need to invent abstract codes.  Use the DNS RCODE + (if available) the

ENS EDNS0 EDE (RFC8914).



But do those codes include errors that only a local resolver might face? Things

like access or syntax errors on /etc/resolv.conf, inability to connect to the

local resolver daemon, or out of memory? In just looking at the set of c-ares

error codes, they're defined in sections with 6 in the "server error codes"

section and 11 in the "locally-generated error codes" section.

No, but that's why I suggested optionally including resolver-specific codes at 
the end of the structure.

The point is to allow an application to be independent of the resolver without 
learning a new, curl-specific vocabulary.  And, when new codes are introduced 
in DNS, not to have to update curl with new abstract codes - at least when the 
resolver supports getting the actual DNS error code.

You would map any resolver codes that don't come from DNS to a code in the 
"Reserved for Private Use" space.

You can also provide the text for humans.

See the RFCs and the code registries at:

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes



Timothe Litt

ACM Distinguished Engineer

--------------------------

This communication may not represent the ACM or my employer's views,

if any, on the matters discussed.


-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Reply via email to