DNS, i caratteri jolly A Record hanno la priorità su CNAME più specifici?

18

Abbiamo un carattere jolly impostato per gestire tutti i sottodomini per "esempio.com"

UN RECORD: * .example.com punta al 10.10.10.10

Abbiamo un record A più specifico per gestire un sottodominio speciale (funziona benissimo):

A Record: staging.example.com punti 10.10.10.9

Il problema che stiamo riscontrando è che stiamo migrando la gestione temporanea in un nuovo ambiente di hosting e ci è stato chiesto di utilizzare un CNAME:

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

Abbiamo pensato che avrebbe funzionato. Tuttavia, new-staging.example.com si risolve nel jolly di livello superiore 10.10.10.10 e non punta a proxy.heroku.com.

Cosa mi sto perdendo? Non è possibile? O è questa cattiva pratica? Grazie,

domain-name-system cname-record

— zdennis
fonte

1

Stai impostando questo live tramite un'interfaccia web di un ISP o stai eseguendo BIND o djbdns per esempio?

— Jonathan Ross,

Quando dici "risolve il jolly di livello superiore", come stai facendo questa risoluzione? dig -t ANY new-staging.example.com?

— Nickgrim,

@Jonathan, attualmente stiamo usando Slicehost per gestire il DNS, quindi è attraverso un'interfaccia web.

— zdennis,

@nickgrim quando eseguiamo dig -t QUALSIASI new-staging.example.com otteniamo: 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,

15

La risposta è generalmente "No": il record più specifico dovrebbe vincere, quindi dovrebbe funzionare come descritto / previsto. Suppongo che tu abbia il carattere jolly Un record memorizzato nella cache da qualche parte e devi attendere che la cache scada.

un test rapido con BIND 9.6.2-P2 / FreeBSD 8.1:
una zona contenente i record:

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.

Risolve come segue:

% 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

(Restituisce il 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

(Restituisce il record jolly A)

— voretaq7
fonte

È negli standard DNS o è specifico dell'implementazione?

— Bigbio2002,

@ Bigbio2002 Credo che faccia parte dello standard - RFC 4592 è il posto giusto in cui guardare - il mio cervello è un po 'troppo schifoso dalla stesura della documentazione per tutto il giorno allo stomaco che legge la RFC anche se, quindi, se sbaglio, schiaffeggiarmi con la sezione pertinente :-)

— voretaq7,

7

Secondo il tuo commento sulla domanda:

quando eseguiamo dig -t QUALSIASI new-staging.example.com otteniamo: new-staging.example.com. 82880 IN CNAME proxy.heroku.com.example.com. proxy.heroku.com.example.com. 86400 IN A 10.10.10.10

... hai configurato erroneamente il DNS. Devi impostare l'obiettivo del CNAME su proxy.heroku.com.: il periodo finale è importante! Senza di essa, il tuo server DNS presuppone che ti riferisci a un host all'interno della tua example.comzona proxy.heroku.com.example.com- e che viene catturato dal record jolly.

— nickgrim
fonte

Abbiamo il record CNAME impostato su "proxy.heroku.com". Quando scaviamo direttamente il server dei nomi di slicehost (dig @ ns1.slicehost.com) l'unica risposta fornita punta al CNAME per proxy.heroku.com. Quando scaviamo senza specificare ci dà le due risposte (quelle che ho postato sopra che la tua risposta qui riflette). Questo mi fa pensare che forse @ voretaq7 potrebbe essere giusto pensare che ci sia un problema con la cache? Questo si allinea con quello che vedo quando scavo?

— zdennis,

Sì, ciò sembra implicare che una cache DNS a monte di te abbia memorizzato nella cache la versione errata (non periodica). Nel frattempo dovrai aspettare che scada il TTL e / o impostare un nome diverso ( new-new-staging?).

— Nickgrim,

Il punto mancante è anche quello che mi ha fatto inciampare.

— loevborg,

0

Mi sono imbattuto in questo post alla ricerca di come viene eseguito un server Plesk Linux condiviso. Nel loro esempio fanno riferimento a una combinazione DNS / vhost.conf in cui è necessario aggiungere sia vhost.conf che aggiornare il DNS.

Citazione: "Deve essere l'ultimo nell'elenco del sottodominio, che è ordinato in ordine alfabetico, quindi inizia il suo nome con" zz. " Http://kb.parallels.com/2239

La mia ipotesi è che questo differisca dalla teoria DNS "normale" per cui sarebbe restituito il record più specifico.

— Eugene van der Merwe
fonte