Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dns: getServers returns IPv6 addresses without [] #13795

Closed
refack opened this issue Jun 19, 2017 · 10 comments
Closed

dns: getServers returns IPv6 addresses without [] #13795

refack opened this issue Jun 19, 2017 · 10 comments
Labels
cares Issues and PRs related to the c-ares dependency or the cares_wrap binding. dns Issues and PRs related to the dns subsystem.

Comments

@refack
Copy link
Contributor

refack commented Jun 19, 2017

  • Version: v5-v9
  • Platform: *
  • Subsystem: dns,ceres

dns.getServers mis formats IPv6 addresses

> d.setServers(['192.168.1.1', '[2001:4860:4860::8888]'])
undefined
> d.getServers()
[ '192.168.1.1', '2001:4860:4860::8888' ]
@refack refack added cares Issues and PRs related to the c-ares dependency or the cares_wrap binding. dns Issues and PRs related to the dns subsystem. labels Jun 19, 2017
@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

Ref: nodejs/node-v0.x-archive#5435

@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

I just noticed this, IMHO we should format IPv6 with []:
e.g.

return ret.map(([host, port]) => {
  if (isIP(host) === 6) host = `[${host}]`;
  return (!port || port === 53) host : `${host}:${port}`;
}

Fix will be semver-major

@silverwind
Copy link
Contributor

I think a bare IPv6 without [] is fine as long as it's not in an contained in an URL. Also see rfc5952 which suggests to only use[] when a port is included.

@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

I was going by rfc3986, which is ratified while rfc5952 is still "proposed".
IMHO this issue is not urgent and could stay open forever, or closed with known limitation.

@silverwind
Copy link
Contributor

rfc3986 is about URIs, which I think host:port is not (IIRC, a valid URI always requires a protocol). Anyways, If you want to treat it like an URL, you can use the legacy url module to format it (not sure if the same is possible using WHATWG URL, as it doesn't allow calling the constructor without arguments):

> u = new url.Url(); u.hostname = "::1"; u.format()
'[::1]'
> u = new url.Url(); u.hostname = "::1"; u.port = 53; u.format()
'[::1]:53'
> u = new url.Url(); u.hostname = "127.0.0.1"; u.format()
'127.0.0.1'
> u = new url.Url(); u.hostname = "127.0.0.1"; u.port = 53; u.format()
'127.0.0.1:53'

@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

As suggested just now #13723 (comment) dns://[addr]:port...

A semver-major fix could return a list of dns:// URLs (even raw not toStringed) 🤷‍♂️

@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

 💡
🤓
Or add getServersURLs() as semver-minor (or getServers(true))

@silverwind
Copy link
Contributor

dns://[addr]:port

Declaring a DNS server like this is rather uncommon. Why not require and return [] style IPv6 when port is specified and not 53, e.g.:

2001::db8
[2001::db8]:5353
127.0.0.1
127.0.0.1:5353

@refack
Copy link
Contributor Author

refack commented Jun 19, 2017

Declaring a DNS server like this is rather uncommon. Why not require and return [] style IPv6 when port is specified and not 53, e.g.:

(again for context, I think this is of very low priority if at all, I just enjoy the discussion)

Passing URLs (in and out) eliminates hand spun parsing code, by us in setServers and by the user in getServers
We could as well "re-invent" a degenerated URL {addr, port} but even then we'll need to validate that addr is a string representing an IP, and port is a valid port number (0 < port < 2**16-1)

@Trott
Copy link
Member

Trott commented Jun 7, 2018

Closing as known limitation. Feel absolutely free to re-open or comment if you feel it should stay open, especially if you think it might be addressed some point in the not-too-distant future.

@Trott Trott closed this as completed Jun 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cares Issues and PRs related to the c-ares dependency or the cares_wrap binding. dns Issues and PRs related to the dns subsystem.
Projects
None yet
Development

No branches or pull requests

3 participants