Which of these DNS records has priority? - dns

Question

Say I have these two records defined:
*.example.com CNAME <some name>
foo.example.com TXT <some text>
What is expected to happen if I run a DNS query like this?
dig TXT foo.example.com
I would expect to get the TXT record defined above in the answer section, since it's more explicitly defined. But, what I get from my DNS provider is the CNAME defined for the wildcard.
I've raised this issue with them, and they say they are following the correct behaviour. This is the explanation they gave me:
Refer section 2.4 in RFC1912 about "Common DNS errors". http://www.rfc-editor.org/rfc/rfc1912.txt "A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record."
Basically, this means that, if you add a CNAME record for *.example.com, it will always take priority over any other record, even if those records are added for a specific subdomain, they're still ignored. There is nothing we can do in this case. It's how DNS is supposed to work, according to the DNS-standard.
Is this correct? Does the section in the referred RFC cover the case of a wildcard? Can anyone give me an authoritative answer and provide a link to the source?

Answer 1

Wikipedia page on DNS wildcard is pretty clear with examples (see the one about host1.example).
In short, a wildcard is only used if the "direct" full name is not found.
You can find all the explanations in section 4.3.2 of https://www.rfc-editor.org/rfc/rfc1034 and specifically point 3.a and point 3.c:
a. If the whole of QNAME is matched, we have found the
node.
If the data at the node is a CNAME, and QTYPE doesn't
match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
the CNAME RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
[..]
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see if a
the "*" label exists.
See how it specifically first searches for the full name, with extra condition if it is a CNAME, but this is not your case if you query for a TXT.
In your case if you query for the TXT record specifically, then that should be returned, irrespective of any wildcard.
In fact the TXT on foo.example.com will hide any other type, a CNAME request on it, should not return the value in the wildcard but instead stop with NOERROR NODATA meaning that the name exists, just not for this type.
This is exactly the host1.example case in the above Wikipedia page.
It is very easy to try in fact.
With this zonefile:
$TTL 1
# IN SOA localhost. root.localhost. (1 604800 86400 419200 604800)
IN NS a.example.org.
IN NS b.example.org.
IN NS c.example.org.
*.example.com. IN CNAME foobar.example.net.
foobar.example.com. IN TXT "I am here."
(the beginning is just boilerplate to have bind really load the zone)
if you do dig #127.0.0.1 foobar.example.com TXT you get as expected:
;; ANSWER SECTION:
foobar.example.com. 1 IN TXT "I am here."
if you query for any other record type on same name, including CNAME you get NOERROR without any CNAME in reply (the wildcard is hidden by the explicit name in zonefile, and you get NOERROR but no data for any other record type than TXT on this name as this is the only record type in the zonefile) and the wildcard works for any other name, like dig #127.0.0.1 not-foobar.example.com TXT gives:
;; ANSWER SECTION:
not-foobar.example.com. 1 IN CNAME foobar.example.net.
The explanations you are given are not the correct ones and do not apply on your use case. The quote would only apply to this kind of (invalid) configuration:
*.example.com. CNAME <some name>
*.example.com. TXT <some text>
but this is not related to the wildcard, the same problem appears with the following configuration that will be rejected by any compliant nameserver:
foobar.example.com. CNAME <some name>
foobar.example.com. TXT <some text>