Os caracteres curinga DNS, um registro têm prioridade sobre CNAMEs mais específicos?

Temos um curinga configurado para lidar com todos os subdomínios de "example.com"

A RECORD: * .example.com aponta para 10.10.10.10

Temos um registro A mais específico para lidar com um subdomínio especial (isso funciona bem):

Um registro: staging.example.com pontos 10.10.10.9

O problema que estamos enfrentando é que estamos migrando a preparação para um novo ambiente de hospedagem e fomos instruídos a usar um CNAME:

CNAME: new-staging.example.com aponta para proxy.heroku.com

Nós pensamos que isso iria funcionar. No entanto, new-staging.example.com resolve para o curinga de nível superior 10.10.10.10 e não aponta para proxy.heroku.com.

o que estou perdendo? Isso não é possível? Ou isso é uma prática ruim? Obrigado,

A resposta geralmente é "Não" - o registro mais específico deve vencer, portanto, deve funcionar como você descreveu / esperava. Meu palpite é que você tem o registro curinga A armazenado em cache em algum lugar e precisa aguardar a expiração do cache.

um teste rápido com o BIND 9.6.2-P2 / FreeBSD 8.1:
Uma zona contendo os registros:

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.

Resolve da seguinte maneira:

% 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

(Retorna o CNAME)
e

% 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

(Retorna o registro curinga A)

De acordo com o seu comentário sobre a questão:

ao executar dig -t QUALQUER new-staging.example.com, obtemos: new-staging.example.com. 82880 NO CNAME proxy.heroku.com.example.com. proxy.heroku.com.example.com. 86400 IN A 10.10.10.10

... você configurou incorretamente o DNS. Você precisa definir a meta do CNAME para proxy.heroku.com.- o período final é importante! Sem ele, seu servidor DNS está assumindo que você está se referindo a um host dentro da sua example.comzona - proxy.heroku.com.example.com- e que está sendo capturado pelo registro curinga.

Me deparei com este post pesquisando como isso é feito em um servidor Plesk Linux compartilhado. No exemplo deles, eles se referem a uma solução DNS / vhost.conf combinada, na qual é necessário adicionar o vhost.conf e atualizar o DNS.

Citação: "Ele deve ser o último na lista de subdomínios, que é ordenada alfabeticamente. Portanto, inicie seu nome com" zz ". Http://kb.parallels.com/2239

Meu palpite é que isso difere da teoria DNS 'normal', na qual o registro mais específico seria retornado.