3 Answers
3

The answer is generally "No" - the more specific record should win, so this should work as you described/expected. My guess is you have the wildcard A record cached somewhere, and need to wait for that cache to expire.

a quick test with BIND 9.6.2-P2/FreeBSD 8.1:
A zone containing the records:

example.net. IN A 127.0.0.2
*.test.example.net. IN A 127.0.0.1
specific.test.example.net. IN CNAME example.net.

Is this in the DNS standards, or is this implementation-specific?
–
Bigbio2002Mar 26 '12 at 22:12

@Bigbio2002 I believe it's part of the standard - RFC 4592 is the relevant place to look - my brain is a bit too soupy from writing documentation all day to stomach reading the RFC though so if I'm wrong please slap me with the relevant section :-)
–
voretaq7♦Mar 26 '12 at 22:18

when running dig -t ANY new-staging.example.com we get: new-staging.example.com. 82880 IN CNAME proxy.heroku.com.example.com. proxy.heroku.com.example.com. 86400 IN A 10.10.10.10

...you've misconfigured DNS. You need to set the target of the CNAME to proxy.heroku.com. - the final period is important! Without it, your DNS server is assuming you're referring to a host within your example.com zone - proxy.heroku.com.example.com - and that is being caught by the wildcard-record.

We've got the CNAME record set to "proxy.heroku.com." When we dig the slicehost name server directly (dig @ns1.slicehost.com) the only answer provided points to the CNAME for proxy.heroku.com. When we dig without specifying it gives us the two answers (the ones I posted above that your answer here reflects). This makes me think that perhaps @voretaq7 may right thinking there's a cache issue? Does that line up with what I'm seeing when digging?
–
zdennisMar 29 '11 at 15:58

Yeah, that seems to imply that a DNS-cache upstream of you has cached the incorrect (non-period) version. You'll have to wait for the TTL to expire and/or set up a different name in the meantime (new-new-staging ?).
–
nickgrimMar 29 '11 at 16:35

I came across this post researching how this is done a shared Plesk Linux server. In their example they refer to a combination DNS / vhost.conf solution where you have to add to both the vhost.conf and update the DNS.

Quote:
"It has to be the last in the subdomain list, which is ordered alphabetically, so start its name with "zz."
http://kb.parallels.com/2239

My guess is this differs from 'normal' DNS theory whereby the more specific record would be returned.