Repository navigation
Unable to resolve A when record points to CNAME containing asterisk #42171
Description
Activity
Here's a dig with the domain redacted too:
dig test.tld ; <<>> DiG 9.10.6 <<>> test.tld ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3826 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;test.tld. IN A ;; ANSWER SECTION: test.tld. 6529 IN CNAME *.test.tld.cdn.cloudflare.net. *.test.tld.cdn.cloudflare.net. 300 IN A 1.1.1.1 *.test.tld.cdn.cloudflare.net. 300 IN A 1.1.1.1 ;; Query time: 67 msec ;; SERVER: 192.168.0.1#53(192.168.0.1) ;; WHEN: Tue Mar 01 18:54:45 GMT 2022 ;; MSG SIZE rcvd: 128@nodejs/dns
I don't think
*.test.tld.cdn.cloudflare.net.is a valid CNAME. I'm not even sure what you'd do with it if it was.FWIW, musl libc rejects it too.
I don't think *.test.tld.cdn.cloudflare.net. is a valid CNAME. I'm not even sure what you'd do with it if it was.
I was trying to check, but didn't find anything conclusive. There's https://www.ietf.org/rfc/rfc4592.txt, but, at first glance didn't get a definitive answer.
To clarify, the CNAME record does not contain a wildcard, just the value (answer). It is valid to have a wildcard A record, so it would seem weird that you couldn't CNAME to it. Stranger things have happened.
Browsers, dig, nslookup, and older versions of node seem OK with it, fwiw?
The validation is done in c-ares so any changes would have to be made there.
The validation is done in c-ares so any changes would have to be made there.
Thank you, have raised an issue on c-ares. 🙏
c-ares/c-ares#457- added a commit that references this issue
on Mar 2, 2022 Fixed in c-ares/c-ares@b5a3d96. Someone want to open a cherry-pick PR? It's trivial enough that I don't think it can do harm.
Reacted by Benjamin GruenbaumThere's a cherry-pick PR ready for review. I had a battle with the commit message linter, it won.
- added a commit that references this issue
on Mar 21, 2022 - added 4 commits that reference this issue
on Apr 21, 2022 - added a commit that references this issue
on Apr 25, 2022 - added a commit that references this issue
on Jan 31, 2023 - added a commit that references this issue
on Jul 23, 2025 - added a commit that references this issue
on Dec 16, 2025 - added a commit that references this issue
on May 22, 2026
Version
16.14.0
Platform
20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
Subsystem
No response
What steps will reproduce the bug?
Perform a
dns.lookup()against a domain that resolves to a CNAME containing a wildcard asterisk (*).Domains pointing to CloudFlare seem to use this approach in particular.
Sample code (will try to find a domain that breaks that I can share publicly):
Using nslookup or dig does return an A record. Using a version of node <16.6.2 also works.
Probably related to this similar issue:
#39780
How often does it reproduce? Is there a required condition?
Can be reproduced every time.
What is the expected behavior?
dns.resolve()returns a successful result (A record addresses).What do you see instead?
Error: Error: queryA EBADRESP test.tld at QueryReqWrap.onresolve [as oncomplete] (node:dns:213:19) { errno: undefined, code: 'EBADRESP', syscall: 'queryA', hostname: 'test.tld' }Additional information
Seems related to: