Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a wildcard set up to handle all subdomains for "example.com"

A RECORD: *.example.com points to 10.10.10.10

We have a more specific A record to handle a special subdomain (this works fine):

A Record: staging.example.com points 10.10.10.9

The problem we're having is we're migrating staging to a new hosting environment and we've been instructed to use a CNAME:

CNAME: new-staging.example.com points to proxy.heroku.com

We thought this would work. However, new-staging.example.com resolves to the top-level wildcard 10.10.10.10 and doesn't point to proxy.heroku.com.

What am I missing? Is this not possible? Or is this bad practice? Thanks,

share|improve this question
1  
Are you setting this live through an ISP's web interface or are you running BIND or djbdns for example ? –  Jonathan Ross Mar 29 '11 at 15:12
    
When you say "resolves to the top-level wildcard", how are you doing this resolution? dig -t ANY new-staging.example.com ? –  nickgrim Mar 29 '11 at 15:24
    
@Jonathan, we are currently using Slicehost to manage DNS, so it's through a web-interface. –  zdennis Mar 29 '11 at 15:26
    
@nickgrim 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 –  zdennis Mar 29 '11 at 15:29
add comment

3 Answers 3

up vote 5 down vote accepted

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.

Resolves as follows:

% dig specific.test.example.net

; <<>> DiG 9.6.2-P2 <<>> specific.test.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17222
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;specific.test.example.net. IN  A

;; ANSWER SECTION:
specific.test.example.net. 3600 IN  CNAME   example.net.
example.net.               3600 IN  A   127.0.0.2

;; AUTHORITY SECTION:
example.net.        3600    IN  NS  ns1.example.net.

;; ADDITIONAL SECTION:
ns1.example.net.    3600    IN  A   127.0.0.1

(Returns the CNAME)
and

% dig nonspecific.test.example.net

; <<>> DiG 9.6.2-P2 <<>> nonspecific.test.example.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;nonspecific.test.example.net.  IN  A

;; ANSWER SECTION:
nonspecific.test.example.net. 3600 IN   A   127.0.0.1

;; AUTHORITY SECTION:
example.net.        3600    IN  NS  ns1.example.net.


;; ADDITIONAL SECTION:
ns1.example.net.    3600    IN  A   127.0.0.1

(Returns the wildcard A record)

share|improve this answer
    
Is this in the DNS standards, or is this implementation-specific? –  Bigbio2002 Mar 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
add comment

According to your comment on the question:

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.

share|improve this answer
    
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? –  zdennis Mar 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 ?). –  nickgrim Mar 29 '11 at 16:35
    
thank you @nickgrim –  zdennis Mar 29 '11 at 17:56
    
The missing dot is what tripped me up as well. –  loevborg Sep 24 '13 at 7:24
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.