Wildcard domain name proxy partially invalid

My domain name is junjie.pro and I have used multiple subdomains before (like blog.junjie.pro and git.junjie.pro) and they all use proxies.

When Cloudflare announced that free users can also proxy wildcard domain names, I tried to use *.junjie.pro, but only these two subdomains will not return any A records, any other (such as the randomly selected ljagjalgji.junjie.pro) subdomains are normal.

All A records:

Looks good to me:

% dig +short ljagjalgji.junjie.pro
104.21.87.140
172.67.143.133

1 Like

This domain name is also normal for me.

But the problem I’m having is that all subdomains except blog.junjie.pro and git.junjie.pro resolve fine :joy:.

I just randomly found a subdomain to prove that wildcard domain name resolution is normal.

blog.junjie.pro:

git.junjie.pro:

Yet another random subdomain:

Ah, I understand. blog and git don’t return results.

Do you have those hostnames showing anywhere else in your account?

You said you used them before. In this account? Or through a third party?

1 Like

No. Here are all my DNS records:

I’ve used blog and git before and both use proxies. I tried switching to *.junjie.pro after Cloudflare announced wildcard domain names for free users.

If I add blog and git again, they resolve fine, but I want to use wildcard domain names instead of subdomains.

Well, there are several TXT and MX records here, I don’t think they will affect the resolving of blog and git’s A records.

Perhaps they shouldn’t, but they do. I just went into a domain I’m not using and created a wildcard A record, and an MX record for a host named foo. Everything *.example.com resolves according to the wildcard A record, except the foo host, which does not resolve to any A record.

This happens whether the wildcard A record is proxied or not.

I created cockpit.junjie.pro before and replaced it with a wildcard domain name and it still resolves fine. This shows that the resolving failure has nothing to do with whether it has been used or not.

According to your test, the MX record will affect the resolving. The blog.junjie.pro in the screenshot above has HTTPS records, indicating that the HTTPS records may also be affected. It is also possible for TXT records to affect resolving.

I think it’s a programming bug at Cloudflare.

I don’t actually think it’s a bug, but it’s interesting. I’ve been running DNS since the '90s but I never did anything with wildcard records so I never ran into this before, but it seems that if a hostname exists at all with any record type then the lookup doesn’t go any further than “there is no A record for this host”. It never gets to the wildcard record. A wildcard record is only used for hostnames that don’t exist at all.

This is not Cloudflare-specific, but one could argue that Cloudflare could remedy it in their own DNS server software. One could also argue that Cloudflare’s DNS server should work according to standards, though they have already thrown that idea out by allowing CNAMEs at the root.

Well, technically they don’t. It’s still an A record.

True, that’s just a UI detail.

I get it, wildcard domain names will only work if there aren’t any associated records.

Wildcard A records are not isolated from other records. For example, when querying git.junjie.pro, there are MX records, or when querying blog.junjie.pro, there are HTTPS records. In this case, wildcard records will not take effect. The solution is to add plain A records.

I’d go back to using normal A records. Thanks for everyone’s help!

See also: dns - Do MX Records interfere with wildcard CNAME records? - Stack Overflow.

2 Likes

It is not just Hostnames. ANY DNS RR means that the wildcard does not match. This is as per the RFC.

Allowing CNAMEs at the root is internal magic. From the perspective of any DNS resolver Cloudflare follows the specifications by flattening CNAME records at the root.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.