curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Feature request about curlinfo option returning resolver status/error code

From: Daniel F via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 22 Apr 2022 22:10:31 +0200

Hi,
DNS error codes mentioned earlier are returned by DNS itself, so they do
not cover all possible problems. You also need to define values for
various network-related problems (e.g. timeouts, ICMP errors, malformed
packets) and software/configuration ones (e.g. out of memory, permission
denied, invalid arguments, etc.).

Regards,
Daniel

W dniu 2022-04-22 21:26, Dmitry Karpov via curl-library napisał(a):
> 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-bounces_at_lists.haxx.se> ON BEHALF OF
> Timothe Litt via curl-library
> SENT: Wednesday, April 20, 2022 1:34 PM
> TO: curl-library_at_lists.haxx.se
> CC: Timothe Litt <litt_at_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
Received on 2022-04-22