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

From: Timothe Litt <litt_at_acm.org>
Date: Tue, 19 Apr 2022 16:14:23 -0400

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

Optionally returning some resolver-specific data is fine, but neither a
new set of abstract codes nor whatever a resolver produces should be
primary.

Something like

|struct {|

|    uint16 rcode;  RFC1035
|

|    uint16 edecode; RFC8914
|

|   const char *edxtratext; (or NULL) RFC8914
|

|   enum resolverID {unspec, glibc,Cares,windoze,...}; cURL
|

|   uint64 resolverCode; resolver-specific code
|

|   const char *resolverText; (or NULL) resolver-specific string
|

|} resolverCode;|

If curllib allocates the struct, the text strings, if present can be
appended to the struct (with suitable alignment), or point to static
strings.  This avoids requiring a specialized free() routine.  If the
application allocates it, the application would be responsible for
calling free() on the text strings.

Note that for some resolvers, it may be necessary to back translate
their response code to the DNS RFCs'.  But that work ends up in curllib,
not in the application.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 19-Apr-22 15:18, Dmitry Karpov via curl-library wrote:
> The resolvers can have completely different codes, and some of them maybe completely resolver-specific (or resolvers may not provide any status codes at all).
> The CURLINFO_RESOLVER_CODE would help to debug issues with some specific resolver, so I am not sure if it will be very beneficial to create some abstract resolver codes here .
>
> It would be much better, in my opinion, to return resolver codes "as is" rather than mapping them into some abstract values.
> For instance, it will help to debug some internal resolver errors, which may be reported via resolver status codes but don't have good abstract translation.
>
> -----Original Message-----
> From: Daniel Gustafsson<daniel_at_yesql.se>
> Sent: Tuesday, April 19, 2022 11:49 AM
> To: libcurl development<curl-library_at_lists.haxx.se>
> Cc: Daniel Stenberg<daniel_at_haxx.se>; Dmitry Karpov<dkarpov_at_roku.com>
> Subject: Re: Feature request about curlinfo option returning resolver status/error code
>
>> On 19 Apr 2022, at 19:35, Dmitry Karpov via curl-library<curl-library_at_lists.haxx.se> wrote:
>>
>> It would return a status code the resolver returns when it performs a DNS query.
>>
>> For instance, c-ares passes its status code in resolution callbacks, so this status code would be returned in the CURLINFO_RESOLVER_CODE.
>> So, if something goes wrong with host name resolution, this code will give a hint why the resolver failed.
> If we are returning a code it should be an abstracted/translated code which doesn't rely on a specific resolver (ie the set of returncodes should not change depending on the resolver).
>
> This is clearly not hard to do, but we need to figure out a good mapping.
>
> --
> Daniel Gustafsson https://vmware.com/
>

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

Received on 2022-04-19