Repository navigation
Unable to resolve A when record points to CNAME containing underscore #39780
Description
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.
Activity
Ayase-252 commentedon Aug 17, 2021
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 commentedon Aug 27, 2021
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 commentedon Sep 7, 2021
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 commentedon Sep 7, 2021
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 commentedon Sep 8, 2021
Please see c-ares/c-ares@5c995d50
m-rousse commentedon Sep 8, 2021
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 commentedon Oct 25, 2021
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-aresrelease for it, is there a planned release date?bradh352 commentedon Oct 25, 2021
@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 commentedon Oct 25, 2021
I'll be ready to press the necessary key combos to make it happen.
bradh352 commentedon Oct 25, 2021
@bagder: ready when you are c-ares/c-ares@800e472
bagder commentedon Oct 25, 2021
Roger that. I'll make it happen later tonight my time.
bagder commentedon Oct 25, 2021
c-ares 1.18.0 is officially shipped
Ayase-252 commentedon Nov 18, 2021
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.
1 remaining item
dougmoscrop commentedon Nov 24, 2021
Can this please be backported to v16?
2021-11-30, Version 14.18.2 'Fermium' (LTS)
2021-11-30, Version 14.18.2 'Fermium' (LTS)
FredZhao-at commentedon Nov 29, 2021
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.
2021-11-30, Version 14.18.2 'Fermium' (LTS)
richardlau commentedon Dec 9, 2021
I've cherry-picked #40660 onto the
v12.x-stagingbranch, 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 commentedon Dec 13, 2021
@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". 😢
2012-12-16, Version 12.22.8 'Erbium' (LTS)
2012-12-16, Version 12.22.8 'Erbium' (LTS)
richardlau commentedon Dec 13, 2021
@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.
2012-12-16, Version 12.22.8 'Erbium' (LTS)
2012-12-16, Version 12.22.8 'Erbium' (LTS)
2012-12-16, Version 12.22.8 'Erbium' (LTS)