Unable to resolve A when record points to CNAME containing underscore

[m-rousse]

Version

v14.17.5

Platform

Darwin abc.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64 i386 MacBookPro15,2 Darwin

Subsystem

No response

What steps will reproduce the bug?

dns.resolve4('alshaya-alshayatrmobileqa.fastcache.net', console.log)

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

It reproduces everytime.

What is the expected behavior?

dns.resolve4('alshaya-alshayatrmobileqa.fastcache.net', console.log)
QueryReqWrap {
bindingName: 'queryA',
callback: [Function: log],
hostname: 'alshaya-alshayatrmobileqa.fastcache.net',
oncomplete: [Function: onresolve],
ttl: false
}
null [ '34.120.237.120' ]

What do you see instead?

dns.resolve4('alshaya-alshayatrmobileqa.fastcache.net', console.log)
QueryReqWrap {
bindingName: 'queryA',
callback: [Function: log],
hostname: 'alshaya-alshayatrmobileqa.fastcache.net',
oncomplete: [Function: onresolve],
ttl: false
}
Error: queryA EBADRESP alshaya-alshayatrmobileqa.fastcache.net
at QueryReqWrap.onresolve [as oncomplete] (dns.js:206:19)
at QueryReqWrap.callbackTrampoline (internal/async_hooks.js:131:17) {
errno: undefined,
code: 'EBADRESP',
syscall: 'queryA',
hostname: 'alshaya-alshayatrmobileqa.fastcache.net'
}

Additional information

It seems to have been introduced in latest release (it works fine under 14.17.4) and seems related to hostname validation, I suspect it fails because the CNAME record contains underscores.

[Ayase-252]

Yeah, it was introduced on v16.6.2 release. c-ares was updated in that release.

c-ares seems start to enforce hostname validation in c-ares/c-ares#406.

[m-rousse]

Hi @Ayase-252, thanks for the explanation.

This validation seems too strict as it does not allow for underscores in hostnames (for A, AAAA and CNAME records) contrary to what RFC 2181 states in its 11th section: https://www.rfc-editor.org/rfc/rfc2181.html#section-11

Namely, browsers, dns utilities (think dig, nslookup) and usual utilities relying on system resolvers (thinking about ping) all support hostnames containing underscore (and IIUC they should support any ASCII character).

[AdamMajer]

So, there is a difference between acceptable domain name and acceptable hostname. One should not be confused with another.

_ldap._tcp. <Domain_Name>

This should resolve even though _ldap is not a valid hostname.

[m-rousse]

I see, thanks for the explanation.
Would it be possible to opt-out from this behavior?
As most common programming languages, tools and applications do not apply this rule it is unexpected and not desirable in some cases (I work on a tool to perform queries on websites/endpoints which should work for any website loadable through a browser)

[bradh352]

Please see c-ares/c-ares@5c995d50

[m-rousse]

Many thanks @bradh352, I'll wait for the node release to test it before closing the issue.
(Though feel free to close it if you prefer)

[m-rousse]

Hi @bradh352, would it be possible to include this fix in the next version of Node?
I see it has been committed but I see no c-ares release for it, is there a planned release date?

[bradh352]

@m-roussee, @bagder: I don't see any reason to not start staging a c-ares 1.18.0 release. There have been quite a few code changes and now that we have Cirrus-CI as a replacement for Travis-CI so auto-builds are happening again, I have greater confidence in the release process going smoothly. I'll start the process on my end, but @bagder is the one that needs to actually push it live.

[bagder]

I'll be ready to press the necessary key combos to make it happen.

[bradh352]

@bagder: ready when you are c-ares/c-ares@800e472

[bagder]

Roger that. I'll make it happen later tonight my time.

[bagder]

c-ares 1.18.0 is officially shipped

[Ayase-252]

We have updated c-ares to 1.18.1 in #40660, and released it in v17.1.0

It should be resolved now. Feel free to reopen the issue if it is not the case.

[dougmoscrop]

Can this please be backported to v16?

[FredZhao-at]

Can this also be backported to v12 please? I'm seeing the same issue there on 12.22.7, and it looks like this started from 12.22.5.

[richardlau]

I've cherry-picked #40660 onto the v12.x-staging branch, so it should go out in the next Node.js 12 release. We do not have a firm date for when that will be.

[FredZhao-at]

@richardlau Thanks for the update! Is it possible to request some help prioritizing a release, or get an estimated timeframe for when the next v12 release will happen?

To forward some context, this is currently causing a consistent issue for some of our customers. While the problem isn't super widespread, those specific customers' use cases (that is, when requesting a specific URL) is just totally broken right now. "20% of the time, it fails all the time". 😢

[richardlau]

@FredZhao-at I've opened #41161 for discussion -- let's try to get a release on Thursday. There's an OpenSSL release due out tomorrow so hopefully we'll be able to include that as well. I'm taking time off work next week until the New Year so if the release doesn't happen by the end of this week it'll probably be early January.