Bug Report: Importing a DNS zone with Wildcards produces broken configuration

I tried opening a support ticket for this, but it seems like the support people totally misunderstood it so I’m going to have to try a different channel…

When I transferred a domain in to Cloudflare, I imported a DNS zone file from the old provider that contained some wildcard records. I left the default import setting to “Proxy all domains.”

Now I cannot toggle the cloud icon from orange to gray to turn off proxying for the wildcards because officially my free account doesn’t support wildcard proxying. I know that I can just delete the record and re-add it, but that is error-prone and annoying for large numbers of records.

To see this in action, create a zone file like this:

*.wildtest	3600	 IN 	CNAME	example.com.

Steps to reproduce:

  1. In the DNS management screen, click Advanced and select the zone file to import.
  2. Make sure the checkbox to “proxy the imported records” is checked.
  3. Finish the import.
  4. Observe that the imported record shows as proxied (see screenshot below).
  5. Click Edit for that record and observe that there is no way to change whether it is proxied or not and it incorrectly states that the record is “DNS only”. (see screenshot below)
  6. Use nslookup or dig to confirm that the IP addresses returned for this record are Cloudflare IPs, not the expected IP of the CNAME target.


When I posted this as a support ticket, I also added the following: “Of course, it doesn’t actually work - trying to get to any example subdomain (such as test.wildtest…) gives a TLS connection error.”

The support team latched onto this one side point in the message and completely ignored the bug report itself. They replied with a long message about how to purchase a plan (and a certificate) that supports second-level wildcard subdomains. This completely ignores the real issue - I don’t want or need these subdomains proxied (since they handle high numbers of WebSocket connections). I just want the bug fixed so that wildcard subdomains can’t accidentally be enabled on a plan that has no support for them and then be unable to be disabled.

Maybe @cscharff can check this. He loves DNS mysteries. No guarantees, though. He’s cranky on Wednesdays. :grin:

1 Like

? :thinking: :innocent:

1 Like

Anything?

This topic was automatically closed after 14 days. New replies are no longer allowed.