DNS, haben A Record-Platzhalter Vorrang vor spezifischeren CNAMEs?

18

Wir haben einen Platzhalter eingerichtet, der alle Subdomains für "example.com" behandelt.

A RECORD: * .example.com zeigt auf 10.10.10.10

Wir haben einen spezifischeren A-Datensatz, um eine spezielle Unterdomäne zu behandeln (dies funktioniert einwandfrei):

A Record: staging.example.com points 10.10.10.9

Das Problem bei der Migration von Staging auf eine neue Hosting-Umgebung ist, dass wir angewiesen wurden, einen CNAME zu verwenden:

CNAME: new-staging.example.com verweist auf proxy.heroku.com

Wir dachten, das würde funktionieren. New-staging.example.com wird jedoch in den Platzhalter 10.10.10.10 der obersten Ebene aufgelöst und verweist nicht auf proxy.heroku.com.

Was vermisse ich? Geht das nicht Oder ist das schlechte Praxis? Vielen Dank,

domain-name-system cname-record

— zdennis
quelle

1

Stellen Sie dies live über die Internetschnittstelle eines Internetdienstanbieters ein, oder führen Sie beispielsweise BIND oder djbdns aus?

— Jonathan Ross

Wenn Sie "Auflösen zum Platzhalter der obersten Ebene" sagen, wie gehen Sie bei dieser Auflösung vor? dig -t ANY new-staging.example.com?

— Nickgrim

@ Jonathan, wir verwenden derzeit Slicehost zum Verwalten von DNS, also über eine Webschnittstelle.

— Zdennis

@nickgrim Wenn Sie dig -t ANY new-staging.example.com ausführen, erhalten Sie: 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

Die Antwort lautet im Allgemeinen "Nein" - der spezifischere Datensatz sollte gewinnen, daher sollte dies so funktionieren, wie Sie es beschrieben / erwartet haben. Ich vermute, Sie haben den Wildcard-A-Datensatz irgendwo zwischengespeichert und müssen warten, bis dieser Cache abläuft.

Schnelltest mit BIND 9.6.2-P2 / FreeBSD 8.1:
Eine Zone mit den Einträgen:

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.

Wird wie folgt gelöst:

% 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

(Gibt den CNAME zurück)
und

% 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

(Gibt den Platzhalter A-Datensatz zurück.)

— voretaq7
quelle

Befindet sich dies in den DNS-Standards oder ist dies implementierungsspezifisch?

— Bigbio2002

@ Bigbio2002 Ich glaube, es ist Teil des Standards - RFC 4592 ist der relevante Ort zum Anschauen - mein Gehirn ist ein bisschen zu nervös, vom Schreiben der Dokumentation den ganzen Tag bis zum Lesen des RFC durch den Magen :-)

— voretaq7

7

Nach Ihrem Kommentar zu der Frage:

Wenn Sie dig -t ANY new-staging.example.com ausführen, erhalten Sie: new-staging.example.com. 82880 IN CNAME proxy.heroku.com.example.com. proxy.heroku.com.example.com. 86400 IN A 10.10.10.10

... Sie haben DNS falsch konfiguriert. Sie müssen das Ziel des CNAME auf setzen proxy.heroku.com.- die letzte Periode ist wichtig! Andernfalls geht Ihr DNS-Server davon aus, dass Sie sich auf einen Host in Ihrer example.comZone beziehen proxy.heroku.com.example.com- und dies wird vom Platzhalterdatensatz abgefangen.

— nickgrim
quelle

Wir haben den CNAME-Datensatz auf "proxy.heroku.com" gesetzt. Wenn wir den Slicehost-Nameserver direkt durchsuchen (dig @ ns1.slicehost.com), verweist die einzige angegebene Antwort auf den CNAME für proxy.heroku.com. Wenn wir ohne Angabe graben, erhalten wir zwei Antworten (die, die ich oben gepostet habe und die Ihre Antwort hier wiedergibt). Das lässt mich denken, dass vielleicht @ voretaq7 richtig denken kann, dass es ein Cache-Problem gibt? Stimmt das mit dem überein, was ich beim Graben sehe?

— Zdennis

Ja, das scheint darauf hinzudeuten, dass ein DNS-Cache, der Ihnen vorgeschaltet ist, die falsche (nicht periodische) Version zwischengespeichert hat. Sie müssen warten, bis die TTL abläuft, und / oder in der Zwischenzeit einen anderen Namen vergeben ( new-new-staging?).

— Nickgrim

Der fehlende Punkt ist es, der mich ebenfalls auslöste.

— Loevborg

0

In diesem Beitrag wurde untersucht, wie dies auf einem gemeinsam genutzten Plesk Linux-Server durchgeführt wird. In ihrem Beispiel beziehen sie sich auf eine Kombination aus DNS / vhost.conf-Lösung, bei der Sie sowohl die vhost.conf-Datei hinzufügen als auch den DNS aktualisieren müssen.

Zitat: "Es muss der letzte in der Subdomain-Liste sein, der alphabetisch sortiert ist. Beginnen Sie den Namen also mit" zz ". Http://kb.parallels.com/2239

Ich vermute, dass dies von der "normalen" DNS-Theorie abweicht, nach der der spezifischere Datensatz zurückgegeben wird.

— Eugene van der Merwe
quelle