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-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
