retry with family=0 when family=6,4 throws ENOTFOUND

[cburduja]

In 2.x.x versions of the MongoDB Driver the connection was made in this way:
dns.lookup(host, () => {...}). This type of lookup uses a default IP family of 0 in the dns library.
WIth 3.x.x versions of the driver the lookup is first tried with IPv6, then with IPv4 and if both fail the connection fails.
However the lookup would still work with the method used in 2.x.x, with the family defaulting to 0.

[daprahamian]

Hi @cburduja,

Is there a reason you need this to operate in the old manner? This was an explicit change so that by default, we attempt to use IPv6 first, followed by IPv4.

- Dan

[cburduja]

Hi @daprahamian,
The problem is that when attempting to lookup using IPv6 first, followed by IPv4 the connection fails.
After debugging and comparing to the old method of connecting where the lookup is performed with family=0 the connection works. I'm not sure what is causing the lookup to fail with the new method, but I couldn't find an other way to make it work.

[daprahamian]

@cburduja Can you provide an example of a URL where this would fail with an IPv6/IPv4 lookup, but work with a no-family lookup?

[cburduja]

Our servers are on our internal network so I don't know if this is useful. We have multiple replicasets and the connection URI looks like this: mongodb://user:password@internal-projects-01.server,internal-projects-02.server/db?replicaSet=internal-projects. Is it possible to make a log with everything that mongo does when trying to connect, since I don't know what exactly make the connection fail unless using no-family lookup? Do you have any suggestions on how to find the problem since it only reproduces on our internal network? It is important for us to upgrade to the 3.* version of the mongo driver since we need the new features. Also I want to point out that the connection works when using the mongo console or the python driver.

[cburduja]

@daprahamian Since there doesn't seem to be any other reports of this issue we will use the family parameter to make it work. I might have rushed to make a pull request with a bad solution. However I still consider it a bug that when the family is null the driver fails to connect.
When debugging the driver attempts to connect with IPv6 and fails and then it falls back to IPv4, as expected, but then it also FAILS on IPv4, even though it works when specifying IPv4 through the family parameter. While debugging I also noticed that if I set a breakpoint and pause a couple of seconds between the attempt to connect with IPv6 and the fallback to IPv4, the IPv4 connection succeeds.

If you don't think there's a way to reach the root of this problem and maybe fix it the pull request can be closed. I appreciate you taking the time and I would be happy to hear any suggestions you might have. Thanks!

[daprahamian]

@cburduja I am a little worried about passing a 0 directly to the function. It appears to work, but is not documented. I filed https://github.com/nodejs/help/issues/1970 to ask for more info.

Question: if you change the code to be as follows, does it work?:

  return makeConnection(6, options, (err, ipv6Socket) => {
    if (err) {
      makeConnection(undefined, options, (err, ipv4Socket) => {
        if (err) {
          callback(err, ipv4Socket);
        }

        performInitialHandshake(new Connection(ipv4Socket, options), options, callback);
      });

      return;
    }

    performInitialHandshake(new Connection(ipv6Socket, options), options, callback);
  });

[cburduja]

@daprahamian I tested the code you provided and it works.
I also made a separate test file for the dns.lookup function and it throws ENOTFOUND only when called first with family 6 and then 4. I'm not sure if this is a problem with the DNS library or our DNS configuration, since the above test works with the host google.com, but also using directly family 4 with our internal host works.

[cburduja]

@daprahamian According to this https://support.microsoft.com/en-gb/help/4057932/getaddrinfo-failed-with-wsahost-not-found-11001-error it seems to be a better approach to leave the family unspecified and let the GetAddrInfo code determine the the A/AAAA results.

[daprahamian]

@cburduja it's very interesting that the 6/4 lookup fails with dns.lookup. Im interested to see why that is happening, and whether or not that is a bug in node.

In the meantime, you should be able to get away with passing family: 0 to get around this issue, and we will look into making 0 the backup family lookup.