0

I have the following DNS entries for the root domain example.com:

  • * CNAME record pointing to foo.com
  • dummy.api TXT record containing the value dummy

When I try to resolve bla.foo.com then it correctly resolves to the CNAME entry, but when I try to resolve api.foo.com, the DNS server fails to resolve. This would make sense to me if there was a TXT entry for api.foo.com, but in this case there is only a TXT entry for the more specific domain dummy.api.foo.com.

Is it expected that a more specific domain overrides a wildcard match even if it's only a partial match, like in this case? And is there any way to fix this other than adding an explicit CNAME record for api?

For context: this is happening on Azure DNS and specifically _acme-challenge TXT records that are being created for Let's Encrypt.

Alexander Overvoorde
  • 71
  • 4
  • There are no "partial" match in DNS. The node is either there, or not, or implied by downstreams (called Empty Non-Terminals, on that maybe look at my answer here for deeper explanation: https://serverfault.com/a/973788/396475). And CNAME + wildcards have all sorts of edge cases, some being as designed (but still unexpected/hard to understand, I think this is the case you list), or not. – Patrick Mevzek Feb 20 '23 at 15:52

2 Answers2

3

It looks like this situation is covered by section 2.2.2 in RFC 4592 (https://www.rfc-editor.org/rfc/rfc4592), which states that the record dummy.api.example.com results in the implicit existence of an empty record api.example.com, which is why the wildcard entry stops matching. Therefore the only solution is to add an explicit entry for api.example.com with the same CNAME as the wildcard.

Alexander Overvoorde
  • 71
  • 4
0

When was the DNS record created/amended? Try checking the entry on something like: https://www.whatsmydns.net/

How are you trying to resolve the DNS entry?

If you are using a linux terminal try something like the following:

dig a api.foo.com +trace

This will give you a full output through all the DNS resolvers that your request travels and will show you the final reply from the Authoritive Name Server which should rule out any caching issues.

Scott McKeown
  • 1
  • 1
  • 2