Veröffentlichte SRV-Einträge, die auf einen CNAME-Alias ​​verweisen, verstoßen gegen RFC 2782?

14

Im Verlauf einiger Aufgaben muss ich mich mit SRV-Datensätzen befassen und versuche, eine Wikipedia-Aussage mit dem in DNS-Digs angezeigten Ergebnis in Einklang zu bringen.

Laut Wikipedia SRV Rekordeintrag ,

Das Ziel in SRV-Datensätzen muss auf den Hostnamen mit einem Adressdatensatz (A- oder AAAA-Datensatz) verweisen. Der Verweis auf einen Hostnamen mit einem CNAME-Eintrag ist keine gültige Konfiguration.

Es werden jedoch Datensätze digangezeigt, in denen ein SRV-Datensatz zurückgegeben wird, der auf einen Namen verweist, der als Alias ​​in einem CNAME-Datensatz verwendet wird.

Das heißt so etwas wie:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

Es sieht so aus, als ob der SRV-Datensatz genau so konfiguriert ist, wie es laut Wikipedia-Eintrag nicht zulässig ist. Was verstehe ich falsch? Zeigt es nicht, dass der SRV-Datensatz auf alias.domain.com verweist, der einen CNAME-Datensatz und keinen Adressdatensatz enthält?

domain-name-system cname-record srv-record Scott
quelle
In meiner Firma verwenden wir häufig SRV-Datensätze, und die meisten von ihnen verwenden CNAMEs, und es funktioniert einwandfrei, also gegen die Regeln oder nicht, es funktioniert gut :)
Olivierg

Antworten:

9

In dem von Ihnen zitierten Wikipedia-Artikel heißt es in dem relevanten RFC 2782 für SRV-Datensätze:

Ziel

Der Domänenname des Zielhosts. Es MUSS einen oder mehrere Adressdatensätze für diesen Namen geben, der Name darf KEIN Alias ​​sein (im Sinne von RFC 1034 oder RFC 2181).

Was Sie sehen, ist ein klarer Verstoß gegen die Regeln. aber es könnte funktionieren (und es in der Regel der Fall ist), wenn was auch immer Client - Anwendung für das SRV - Datensatz suchen , ist intelligent genug , um richtig einen CNAME - Datensatz zu behandeln, auch wenn es nur einen A - Eintrag in der Antwort erwarten.

Möglicherweise funktioniert es aber auch überhaupt nicht : Es wird nicht unterstützt und ist vollständig von der Client-Anwendung abhängig. Daher sollte es vermieden werden, da es nicht den richtigen Regeln entspricht und zu fehlerhaften und / oder unvorhersehbaren Ergebnissen führen kann.

Dies ähnelt dem Verweisen eines MX-Datensatzes auf einen CNAME, der in nicht nur einem , sondern auch in zwei RFCs als falsch definiert ist. Dies ist jedoch eine weit verbreitete Praxis (und kein Mailserver scheint ein Problem damit zu haben).

Massimo
quelle
Denken Sie daran, dass "intelligent genug" relativ ist. Einige Software-Designer sind der Meinung, dass das Ertragen von Braindead-Implementierungen nur mehr Implementierungen derselben fördert. RFC 2781 wurde nur von einem einzigen RFC aktualisiert und die Sprache, in der zu erwarten ist, ist sehr streng, daher würde ich hier nicht viel Gnade erwarten.
Andrew B
Die meisten Clientanwendungen verlassen sich nur auf Systembibliotheken, um DNS-Abfragen durchzuführen, und die meisten Bibliotheken (insbesondere in höheren Sprachen) werden ihr Bestes geben, um die von Ihnen geworfenen Abfragen aufzulösen. Sie folgen einem CNAME problemlos und unbemerkt zu seinem Ziel-A-Datensatz und IP Adresse.
Massimo
Die Anwendung benötigt nicht viel Fingerspitzengefühl. Sie fordert das Betriebssystem lediglich auf, eine Verbindung zu "alias.domain.com" auf Port 4443 herzustellen und alle Details zu überlassen.
Massimo
1
Die Clientanwendung und die Systembibliotheken haben nicht die Möglichkeit, dem Alias ​​zu folgen, wenn der Upstream-Recursor die autorisierenden Daten ablehnt und sich weigert, fortzufahren. (das ist die relative Schlauheit, auf die ich mich bezog) BINDs Umgang mit NSDatensätzen und verbotenem Aliasing ist das klassische Beispiel dafür. Unabhängig davon sind wir uns einig, dass es sich um ein Spiel handelt, bei dem die Ergebnisse nicht vorhersehbar sind.
Andrew B
1
Einige Mailserver haben begonnen, MXes zu CNAMEs aktiv zu ignorieren, zB GMX medienconsulting.at/…
Marcel Waldvogel
1

Das ist ein Beispiel für das eingeschränkte Verhalten, ja. Die Einschränkung selbst stammt aus RFC 2781 in der Definition von "Ziel":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

DNS-Server-Software, die verbotene Konfigurationen zulässt, ist leider nichts Neues. Dies kann und passiert genauso wie bei anderen Datensatztypen, bei denen Alias-Ziele wie NSund verboten sind MX. (oben erwähnt)

Nur weil es in der Natur zu finden ist, heißt das noch lange nicht, dass es in Ordnung ist. Und was passiert, wenn ein Standard ignoriert wird, ist von Produkt zu Produkt unterschiedlich. Ich habe die Interaktion mit SRVDatensätzen nicht getestet , aber eine sehr bekannte Entwurfsentscheidung von ISC BIND in Bezug auf NSDatensätze, die auf Aliase verweisen, besteht darin , den Datensatz vollständig zu löschen, wenn er während der Rekursion gefunden wird. Wenn alle NSDatensätze auf diese Weise gelöscht werden, gilt das Ergebnis aller Abfragen SERVFAILfür die betreffende Unterdomäne.

Kurz gesagt, halten Sie sich an den Standard. Es ist die einzig sichere Sache.

Andrew B
quelle