Repository navigation
Unable to resolve A when record points to CNAME containing underscore #39780
Description
Activity
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.
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).
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.
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)Please see c-ares/c-ares@5c995d50
@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.
I'll be ready to press the necessary key combos to make it happen.
Reacted by Yaksh BariyaReacted by Yaksh Bariya@bagder: ready when you are c-ares/c-ares@800e472
Roger that. I'll make it happen later tonight my time.
c-ares 1.18.0 is officially shipped
Reacted by Yaksh Bariya and Mathieu Rousse1 remaining item
Can this please be backported to v16?
- added 2 commits that reference this issue
on Nov 25, 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.
Reacted by Mathieu Rousse- added a commit that references this issue
on Nov 30, 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.Reacted by Fred Zhao and Mathieu Rousse@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". 😢
- added 2 commits that reference this issue
on 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.
Reacted by Fred Zhao
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?
How often does it reproduce? Is there a required condition?
It reproduces everytime.
What is the expected behavior?
What do you see instead?
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.