Cacheable lookup responds with ESERVFAIL while native dns.resolve works about cacheable-lookup HOT 10 OPEN

I have also faced the same issue

from cacheable-lookup.

Duplicate of #52. What does ESERVFAIL mean? I couldn't find anything in the internet about this. Not sure if we should treat this an empty response (it would work in that case), but first I need to know the meaning of the error.

from cacheable-lookup.

https://bluecatnetworks.com/blog/the-top-four-dns-response-codes-and-what-they-mean/
@szmarczak This explains all the the DNS errors, ESERVFAIL means that the query failed because the answer cannot be given, means the server refuses to give response for the query.
Shouldn't be handled in a way where we would get only one query IPv4 and if the DNS is not present we could call IPv6 right?

from cacheable-lookup.

The website doesn't work for me. Can you post a screenshot or give another source please?

from cacheable-lookup.

from cacheable-lookup.

That doesn't seem to be correct. I just used Google again and this time found this:

• https://blog.cloudflare.com/unwrap-the-servfail/#a-tight-lipped-agent

default("Server failure: unable to process this query due to a problem with the name server"):
   return SERVFAIL

"catch-all" SERVFAIL: something went wrong but what exactly?

When a user receives SERVFAIL, the failure can be one of the following:

The stub resolver fails to send the request.
The stub resolver doesn’t get a response.
The recursive resolver, which the stub resolver sends its query to, is overloaded.
The recursive resolver is unable to communicate with upstream authoritative servers.
The recursive resolver fails to verify the DNSSEC chain.
The authoritative server takes too long to respond.

In such cases, it is nearly impossible for the user to know exactly what’s wrong. The resolver is usually the one to be blamed, because, as an agent, it fails to get back the answer, and doesn’t return a clear reason for the failure in the response.

Which means that there's an internal server error. In that case we definitely want to throw an error. If a server doesn't support IPv6, it shouldn't respond with SERVFAIL.

Closing as duplicate of #52

from cacheable-lookup.

Yeah in some DNS servers this happens, when i point to CF dns it returns with ENOTFOUND. But we don't have to query for IPv4 and IPv6 addresses right on resolve()

from cacheable-lookup.

Correct, that's part of #52

from cacheable-lookup.

The problem still exists, when i query for some domains like staging.camsrepository.com, CF DNS resolver throws ESERVFAIL. Since the implementation is querying for both resolve4 and resolve6, should we use promise.allSettled instead of promise.all
Code reference: https://github.com/szmarczak/cacheable-lookup/blob/master/source/index.mjs#L251

from cacheable-lookup.

Hello! Is this temporary workaround correct?

        const cacheable = new CacheableLookup({
            cache,
            maxTtl,
          });

          const originalLookup = cacheable.lookup;

          cacheable.lookup = (hostname, options, callback) => {
            if (hostname === 'localhost') {
              return dns.lookup(hostname, options, callback);
            }
            originalLookup.call(cacheable, hostname, options, callback);
          };

          cacheable.install(http.globalAgent);
          cacheable.install(https.globalAgent);

from cacheable-lookup.