[
https://issues.apache.org/jira/browse/CASSNODEJS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Park Jaeon updated CASSNODEJS-16:
---------------------------------
Description:
h2. Problem
Contact-point hostname resolution currently calls dns.resolve4() and
dns.resolve6(), using Node.js's c-ares DNS resolver. This bypasses operating
system resolution facilities such as hosts files, NSS, Windows name-resolution
policy, VPN/split-DNS configuration, and Tailscale MagicDNS.
The implementation only falls back to dns.lookup() when the direct DNS queries
fail. As a result, names that are valid to the operating system may not resolve
in the driver.
This might interact badly with search domains. For example, trying to access
localhost with cassandra nodejs driver can instead resolve to
localhost.search.domain.
The Node.js documentation about the difference between dns.resolve*() and
dns.lookup(): [https://nodejs.org/api/dns.html#implementation-considerations]
resolve*() always initiates a remote lookup and bypasses the usual OS resolver.
h2. Historical context
The current implementation originated when the driver supported Node.js 0.10
and needed a way to obtain every address for a hostname. Modern versions of
Node.js support dns.lookup(name, \{ all: true }), and the driver now requires
Node.js 20 or later.
The originating PR: [https://github.com/apache/cassandra-nodejs-driver/pull/147]
h2. Proposed change
Use:
{code:javascript}
dns.lookup(name, { all: true })
{code}
This uses the operating system resolver while retaining every returned IPv4
and IPv6 address.
This is also consistent with the resolver approach used by other official
Cassandra drivers:
* Java: InetAddress.getAllByName()
* Python: socket.getaddrinfo(..., AF_UNSPEC, SOCK_STREAM)
* C++: uv_getaddrinfo() with AF_UNSPEC
was:
h2. Problem
Contact-point hostname resolution currently calls dns.resolve4() and
dns.resolve6(), using Node.js's c-ares DNS resolver. This bypasses operating
system resolution facilities such as hosts files, NSS, Windows name-resolution
policy, VPN/split-DNS configuration, and Tailscale MagicDNS.
The implementation only falls back to dns.lookup() when the direct DNS queries
fail. As a result, names that are valid to the operating system may not resolve
in the driver.
This might interact badly with search domains. For example, trying to access
localhost with cassandra nodejs driver can instead resolve to
localhost.search.domain.
The Node.js documentation about the difference between dns.resolve*() and
dns.lookup(): [https://nodejs.org/api/dns.html#implementation-considerations]
resolve*() always initiates a remote lookup and bypasses the usual OS resolver.
h2. Historical context
The current implementation originated when the driver supported Node.js 0.10
and needed a way to obtain every address for a hostname. Modern versions of
Node.js support dns.lookup(name, \{ all: true }), and the driver now requires
Node.js 20 or later.
The originating PR: [https://github.com/apache/cassandra-nodejs-driver/pull/147]
h2. Proposed change
Use:
{code:javascript}
dns.lookup(name, { all: true })
{code}
This uses the operating system resolver while retaining every returned IPv4
and IPv6 address.
This is also consistent with the resolver approach used by other official
Cassandra drivers:
* Java: InetAddress.getAllByName()
* Python: socket.getaddrinfo(..., AF_UNSPEC, SOCK_STREAM)
* C++: uv_getaddrinfo() with AF_UNSPEC
h2. Proposed patch
[https://github.com/finalchild/cassandra-nodejs-driver/tree/fix/system-resolver-contact-points]
> Use the operating system resolver for contact-point hostnames
> -------------------------------------------------------------
>
> Key: CASSNODEJS-16
> URL: https://issues.apache.org/jira/browse/CASSNODEJS-16
> Project: Apache Cassandra NodeJS Driver
> Issue Type: Bug
> Reporter: Park Jaeon
> Priority: Normal
> Labels: pull-request-available
>
> h2. Problem
> Contact-point hostname resolution currently calls dns.resolve4() and
> dns.resolve6(), using Node.js's c-ares DNS resolver. This bypasses operating
> system resolution facilities such as hosts files, NSS, Windows name-resolution
> policy, VPN/split-DNS configuration, and Tailscale MagicDNS.
> The implementation only falls back to dns.lookup() when the direct DNS queries
> fail. As a result, names that are valid to the operating system may not
> resolve
> in the driver.
> This might interact badly with search domains. For example, trying to access
> localhost with cassandra nodejs driver can instead resolve to
> localhost.search.domain.
>
> The Node.js documentation about the difference between dns.resolve*() and
> dns.lookup(): [https://nodejs.org/api/dns.html#implementation-considerations]
> resolve*() always initiates a remote lookup and bypasses the usual OS
> resolver.
> h2. Historical context
> The current implementation originated when the driver supported Node.js 0.10
> and needed a way to obtain every address for a hostname. Modern versions of
> Node.js support dns.lookup(name, \{ all: true }), and the driver now requires
> Node.js 20 or later.
>
> The originating PR:
> [https://github.com/apache/cassandra-nodejs-driver/pull/147]
> h2. Proposed change
> Use:
> {code:javascript}
> dns.lookup(name, { all: true })
> {code}
> This uses the operating system resolver while retaining every returned IPv4
> and IPv6 address.
> This is also consistent with the resolver approach used by other official
> Cassandra drivers:
> * Java: InetAddress.getAllByName()
> * Python: socket.getaddrinfo(..., AF_UNSPEC, SOCK_STREAM)
> * C++: uv_getaddrinfo() with AF_UNSPEC
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
