DNS, ¿los comodines A Record tienen prioridad sobre los CNAME más específicos?

Tenemos un comodín configurado para manejar todos los subdominios de "example.com"

UN REGISTRO: * .example.com apunta a 10.10.10.10

Tenemos un registro A más específico para manejar un subdominio especial (esto funciona bien):

Un registro: staging.example.com puntos 10.10.10.9

El problema que tenemos es que estamos migrando la puesta en escena a un nuevo entorno de alojamiento y se nos ha indicado utilizar un CNAME:

CNAME: new-staging.example.com apunta a proxy.heroku.com

Pensamos que esto funcionaría. Sin embargo, new-staging.example.com se resuelve con el comodín de nivel superior 10.10.10.10 y no apunta a proxy.heroku.com.

¿Qué me estoy perdiendo? ¿No es esto posible? ¿O es esta una mala práctica? Gracias,

La respuesta es generalmente "No": el registro más específico debería ganar, por lo que debería funcionar como lo describió / esperaba. Supongo que tiene el registro comodín A almacenado en caché en algún lugar y necesita esperar a que caduque ese caché.

Una prueba rápida con BIND 9.6.2-P2 / FreeBSD 8.1:
Una zona que contiene los 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.

Resuelve de la siguiente manera:

% 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

(Devuelve el CNAME)
y

% 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

(Devuelve el registro comodín A)

Según su comentario sobre la pregunta:

al ejecutar dig -t CUALQUIER nuevo-staging.example.com obtenemos: new-staging.example.com. 82880 EN CNAME proxy.heroku.com.example.com. proxy.heroku.com.ejemplo.com. 86400 IN A 10.10.10.10

... has configurado mal el DNS. Debe establecer el objetivo del CNAME en proxy.heroku.com.: ¡el período final es importante! Sin él, su servidor DNS está asumiendo que se está refiriendo a un host dentro de su example.comzona proxy.heroku.com.example.com, y eso está siendo capturado por el registro comodín.

Encontré esta publicación investigando cómo se hace esto en un servidor Plesk Linux compartido. En su ejemplo, se refieren a una solución combinada DNS / vhost.conf donde debe agregar tanto a vhost.conf como a actualizar el DNS.

Cita: "Tiene que ser el último en la lista de subdominios, que está ordenada alfabéticamente, así que comience su nombre con" zz ". Http://kb.parallels.com/2239

Supongo que esto difiere de la teoría DNS 'normal' por la cual se devolvería el registro más específico.