DNS, les caractères génériques A Record ont-ils priorité sur les CNAME plus spécifiques?


18

Nous avons un caractère générique configuré pour gérer tous les sous-domaines pour "example.com"

UN ENREGISTREMENT: * .example.com pointe vers 10.10.10.10

Nous avons un enregistrement A plus spécifique pour gérer un sous-domaine spécial (cela fonctionne très bien):

Un record: staging.example.com points 10.10.10.9

Le problème que nous rencontrons est que nous migrons le transfert vers un nouvel environnement d'hébergement et nous avons été invités à utiliser un CNAME:

CNAME: new-staging.example.com pointe vers proxy.heroku.com

Nous pensions que cela fonctionnerait. Cependant, new-staging.example.com résout le caractère générique de niveau supérieur 10.10.10.10 et ne pointe pas vers proxy.heroku.com.

Qu'est-ce que je rate? N'est-ce pas possible? Ou est-ce une mauvaise pratique? Merci,


1
Le définissez-vous en direct via l'interface Web d'un FAI ou exécutez-vous BIND ou djbdns par exemple?
Jonathan Ross

Lorsque vous dites "résout le caractère générique de niveau supérieur", comment procédez-vous pour cette résolution? dig -t ANY new-staging.example.com?
nickgrim

@Jonathan, nous utilisons actuellement Slicehost pour gérer le DNS, c'est donc via une interface web.
zdennis

@nickgrim lors de l'exécution de dig -t ANY new-staging.example.com, nous obtenons: 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

Réponses:


15

La réponse est généralement "Non" - le record le plus spécifique devrait gagner, donc cela devrait fonctionner comme vous l'avez décrit / prévu. Je suppose que vous avez le générique Un enregistrement mis en cache quelque part et que vous devez attendre que ce cache expire.

un test rapide avec BIND 9.6.2-P2 / FreeBSD 8.1:
Une zone contenant les enregistrements:

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.

Décide comme suit:

% 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

(Renvoie le CNAME)
et

% 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

(Renvoie l'enregistrement générique A)


Est-ce dans les normes DNS ou est-ce spécifique à l'implémentation?
Bigbio2002

@ Bigbio2002 Je crois que cela fait partie de la norme - RFC 4592 est l'endroit approprié pour regarder - mon cerveau est un peu trop bouillant de la rédaction de documentation toute la journée à la lecture du RFC estomac, donc si je me trompe, veuillez me gifler avec la section appropriée :-)
voretaq7

7

Selon votre commentaire sur la question:

lors de l'exécution de dig -t ANY new-staging.example.com, nous obtenons: new-staging.example.com. 82880 IN CNAME proxy.heroku.com.example.com. proxy.heroku.com.example.com. 86400 DANS UN 10.10.10.10

... vous avez mal configuré DNS. Vous devez définir l'objectif du CNAME sur proxy.heroku.com.- la dernière période est importante! Sans cela, votre serveur DNS suppose que vous faites référence à un hôte dans votre example.comzone -proxy.heroku.com.example.com - et qui est pris par l'enregistrement générique.


L'enregistrement CNAME est défini sur "proxy.heroku.com". Lorsque nous creusons le serveur de noms slicehost directement (dig @ ns1.slicehost.com), la seule réponse fournie indique le CNAME pour proxy.heroku.com. Lorsque nous creusons sans préciser, cela nous donne les deux réponses (celles que j'ai postées ci-dessus que reflète votre réponse ici). Cela me fait penser que peut-être @ voretaq7 pourrait penser qu'il y a un problème de cache? Cela correspond-il à ce que je vois en creusant?
zdennis

Ouais, cela semble impliquer qu'un cache DNS en amont de vous a mis en cache la version incorrecte (non périodique). Vous devrez attendre l'expiration du TTL et / ou configurer un nom différent en attendant ( new-new-staging?).
nickgrim

Le point manquant est aussi ce qui m'a fait trébucher.
loevborg

0

Je suis tombé sur ce post en recherchant comment cela se fait sur un serveur Plesk Linux partagé. Dans leur exemple, ils font référence à une solution de combinaison DNS / vhost.conf dans laquelle vous devez ajouter à la fois vhost.conf et mettre à jour le DNS.

Citation: "Il doit être le dernier de la liste des sous-domaines, qui est trié par ordre alphabétique, alors commencez son nom par" zz ". Http://kb.parallels.com/2239

Je suppose que cela diffère de la théorie DNS «normale» selon laquelle l'enregistrement plus spécifique serait retourné.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.