DNS, Os curingas de registro têm prioridade sobre os CNAMEs mais específicos?

Question

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

UM REGISTRO: * .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 aponta 10.10.10.9

O problema que estamos tendo é que estamos migrando o teste para um novo ambiente de hospedagem e fomos instruídos a usar um CNAME:

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

Achamos que isso funcionaria. No entanto, new-staging.example.com resolve 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,

    

Answer 1

A resposta é geralmente "Não" - o registro mais específico deve vencer, então isso deve funcionar como você descreveu / esperou. Meu palpite é que você tem o curinga Um registro em cache em algum lugar e precisa esperar que o cache expire.

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 forma:

% 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)

    

Answer 2

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

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

... você configurou mal o DNS. Você precisa definir o destino do CNAME para proxy.heroku.com. - o período final é importante! Sem isso, seu servidor DNS está supondo que você está se referindo a um host dentro de seu example.com zone - proxy.heroku.com.example.com - e que está sendo capturado pelo registro de caractere curinga.

    

Answer 3

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

Quote: "Tem que ser o último na lista de subdomínio, que é ordenada alfabeticamente, então inicie seu nome com" zz ". link

Meu palpite é que isso difere da teoria do DNS "normal", segundo a qual o registro mais específico seria retornado.