deprecate dns.lookup() or a way to add custom DNS Resolver?

Is your feature request related to a problem? Please describe.

I’m using AWS Lambda, Route53(DNS), CloudMap(Service Discovery) for my service.

I want a grpc-js client in a lambda function to find a target grpc-js server by querying DNS, with A record or SRV.

But it is not working with dns.lookup().

https://github.com/grpc/grpc-node/blob/2111c0ffa9d5aaef51b0d9a12a75e73bab5cbd93/packages/grpc-js/src/resolver-dns.ts#L48

And I found this article:

dns.lookup() does not necessarily have anything to do with the DNS protocol. The implementation uses an operating system facility that can associate names with addresses, and vice versa. This implementation can have subtle but important consequences on the behavior of any Node.js program. Please take some time to consult the Implementation considerations section before using dns.lookup().

So I monkey-patched the target js file to use dns.resolve4() for A record resolution, instead of dns.lookup()

From 5c9e75ccf15a9806cdf75a157e4b7793ed77273d Mon Sep 17 00:00:00 2001
From: Hyeonsoo Lee <[e-mail]>
Date: Tue, 18 Aug 2020 16:18:19 +0900
Subject: [PATCH] =?UTF-8?q?chore(crane-distributor-api):=20grpc-js=20DNS?=
 =?UTF-8?q?=20Resolver=20=EB=AA=BD=ED=82=A4=ED=8C=A8=EC=B9=AD?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 packages/my-client/generated/index.js | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/packages/my-client/generated/index.js b/packages/my-client/generated/index.js
index 3b2b874..a1c9455 100644
--- a/packages/my-client/generated/index.js
+++ b/packages/my-client/generated/index.js
@@ -5937,7 +5937,7 @@ function trace(text) {
  */
 const DEFAULT_PORT = 443;
 const resolveTxtPromise = util.promisify(dns.resolveTxt);
-const dnsLookupPromise = util.promisify(dns.lookup);
+const dnsLookupPromise = util.promisify(dns.resolve4);
 /**
  * Merge any number of arrays into a single alternating array
  * @param arrays
@@ -6032,12 +6032,10 @@ class DnsResolver {
              * because when looking up a single family, dns.lookup outputs an error
              * if the name exists but there are no records for that family, and that
              * error is indistinguishable from other kinds of errors */
-            this.pendingLookupPromise = dnsLookupPromise(hostname, { all: true });
+            this.pendingLookupPromise = dnsLookupPromise(hostname);
             this.pendingLookupPromise.then((addressList) => {
                 this.pendingLookupPromise = null;
-                const ip4Addresses = addressList.filter((addr) => addr.family === 4);
-                const ip6Addresses = addressList.filter((addr) => addr.family === 6);
-                this.latestLookupResult = mergeArrays(ip6Addresses, ip4Addresses).map((addr) => ({ host: addr.address, port: +this.port }));
+                this.latestLookupResult = addressList.map((addr) => ({ host: addr, port: +this.port }));
                 const allAddressesString = '[' +
                     this.latestLookupResult
                         .map((addr) => addr.host + ':' + addr.port)
-- 
2.24.3 (Apple Git-128)

It’s ugly, isn’t it?

Describe the solution you’d like

I’m not sure what is the best. Maybe one of these:

1. replace dns.lookup() with dns.resolve()
2. provide a way to add custom DnsResolver
3. another solution?

Describe alternatives you’ve considered

• More documentation
• Let me know what I could help with.

Additional context

• Node.js: 14.8.0
• OS: macOS Catalina
• grpc-js: 1.1.5

[murgatroid99]

My understanding is that CNAME records should be automatically handled by the underlying DNS resolver, such as the ones used by dns.lookup and dns.resolve*. Regarding SRV records, as far as I know gRPC in general only officially uses SRV records to implement the grpclb system, which we have chosen not to implement in grpc-js. There is nothing else there that we would officially support that I know of.

You are not the first person to ask about a custom resolver and I am sympathetic to that, but the current resolver API was not designed to be part of the public API and we would need to go through an API design and review process to change that.

[civilizeddev]

I’ll be waiting.