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.