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

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?

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

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.