Unable to resolve A when record points to CNAME containing asterisk

[arronwoods]

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):

const dns = require('dns');
dns.setServers([ "8.8.8.8", "8.8.4.4" ]);

domain="test.tld";

dns.resolve(domain, function (error, addresses) {
 console.log("Error: ", error); // null
 console.log("DNS servers: ", dns.getServers()); // [ '8.8.8.8', '8.8.4.4' ]
 console.log(domain + " resolves to: ", addresses); // [ '192.168.0.10' ]
});

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:

• Unable to resolve A when record points to CNAME containing underscore #39780
• Validate hostnames in DNS responses and discard from malicious servers c-ares/c-ares#406

[arronwoods]

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

[benjamingr]

@nodejs/dns

[bnoordhuis]

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.

[arronwoods]

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?

[richardlau]

The validation is done in c-ares so any changes would have to be made there.

[arronwoods]

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

[bnoordhuis]

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.

[arronwoods]

There's a cherry-pick PR ready for review. I had a battle with the commit message linter, it won.