dns.reverse incorrectly throws exception when no address found

[Worthaboutapig]

Version

v18.12.1

Platform

Linux live 5.4.0-132-generic #148-Ubuntu SMP Mon Oct 17 16:02:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

node:dns

What steps will reproduce the bug?

var dns = require("node:dns");
var resolver = new dns.Resolver();

resolver.reverse("142.250.180.4", function (err, addresses) {
  if (err) {
    console.error(err);
  } else {
    console.info("addresses:", addresses);
  }
});

resolver.reverse("5.150.98.53", function (err, addresses) {
  if (err) {
    console.error(err);
  } else {
    console.info("addresses:", addresses);
  }
});

How often does it reproduce? Is there a required condition?

This happens always as it is a design issue.

What is the expected behavior?

Rather than throwing an Error, the resultant list of addresses should indicate that the address lookup did not produce a reverse DNS record, say by returning false, instead of the string address.

addresses: [ false ]

What do you see instead?

The second result (where the reverse record does not exist) produces:

Error: getHostByAddr ENOTFOUND 5.150.98.53
    at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:47:19) {
  errno: undefined,
  code: 'ENOTFOUND',
  syscall: 'getHostByAddr',
  hostname: '5.150.98.53'

Additional information

There is no requirement that an IP address resolve to a DNS name, so this shouldn't throw an error, as it's not an exception state, it's that a record could not be found and that's a valid result from the DNS query. They're not the same thing.

Essentially, this makes debugging actual issues really hard, because catching all errors picks this up constantly where it shouldn't. The resolution is not expected to produce a record, and that's fine, so there should be a "not found" result of some sort.

[Trott]

@nodejs/dns

[bnoordhuis]

this shouldn't throw an error, as it's not an exception state

Even if if this ends up being the consensus (and reasonable people can disagree), the existing behavior has been around too long to change.

[bnoordhuis]

Since no one else chimed in, I'll go ahead and close this as a wontfix.