Wildcard CNAME is taking precedence over specific entries

[adrianmace]

• subdomain.domain.net is an A record pointing to a.b.c.d
• *.subdomain.domain.net is CNAME record to subdomain.domain.net.
• These are ‘grey cloud’ DNS only entries.

When generating letsencrypt certificates, I am (automatically) adding specific T.XT records for _acme-challenge.app.subdomain..

When I run a dig command for this, I get back the CNAME rather than the specific TXT record.

$ dig +noall +answer _acme-challenge.app.subdomain.domain.net txt
_acme-challenge.app.subdomain.domain.net. 300 IN CNAME subdomain.domain.net

This behaviour has changed in the last few days/weeks, because before that this setup worked correctly.

Please let me know if you need any further information, but it feels like a bug internally. I’m unable to generate any valid certificates at the moment.

Links have been removed due to ‘new user’ status.

[sandro]

I am afraid I do not seem to be able to reproduce that.

Can you post the actual hostnames?

[sdayman]

I’m also unable to replicate. I use CNAMEs for DKIM at Fastmail, so I already had fm1._domainkey, fm2, fm3. So I added a *._domainkey that pointed to the same place as my fm1.

fm5 now returns the same result as fm1 with:
dig +noall +answer fm5._domainkey.EXAMPLE.net txt

First the CNAME itself, then the TXT record at the target.

[sandro]

@sdayman

First

Order shouldn’t even matter. I get the correct response in any case.

IMHO this will have been a propagation issue.

[adrianmace]

Thanks @sandro - this was a propagation issue on my end.

For additional info: Oracle Cloud is where the compute is running to generate/use the certificates, with the instance configured to use the 169.254.169.254 DNS upstream.

It seems the configured DNS server aggressively caches null domains (as does my home network which meant testing revealed a red herring), I have resolved it by explicitly telling my generation script to use Cloudflare 1.1.1.1 for it’s DNS.