Czy opublikowałeś rekordy SRV wskazujące na alias CNAME z naruszeniem RFC 2782?

W trakcie niektórych obowiązków służbowych muszę zagłębić się w rekordy SRV i staram się pogodzić oświadczenie Wikipedii z tym, co widzę w wykopach DNS.

Według SRV wpisu rekordu Wikipedii ,

cel w rekordach SRV musi wskazywać na nazwę hosta z rekordem adresu (rekord A lub AAAA). Wskazanie nazwy hosta z rekordem CNAME nie jest prawidłową konfiguracją.

ale widzę rekordy, w których digzwraca rekord SRV wskazujący nazwę, która jest aliasem w rekordzie CNAME.

To znaczy coś takiego:

> 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

Wygląda na to, że rekord SRV jest skonfigurowany dokładnie tak, jak mówi wpis w Wikipedii, że jest niedozwolony. Co ja mylę? Czy to nie pokazuje, że rekord SRV wskazuje na alias.domain.com, który ma rekord CNAME, a nie rekord adresu?

domain-name-system cname-record srv-record

— Scott
źródło

w mojej firmie często używamy rekordów SRV, a większość z nich używa CNAME i działa dobrze, więc wbrew zasadom czy nie, działa ładnie :)

— olivierg

Odpowiedzi:

Artykuł w Wikipedii, który cytujesz, podaje, co stwierdza odpowiedni dokument RFC 2782 dla rekordów SRV:

Cel

Nazwa domeny hosta docelowego. Dla tej nazwy MUSI znajdować się co najmniej jeden rekord adresu, nazwa NIE MOŻE być pseudonimem (w znaczeniu RFC 1034 lub RFC 2181).

To, co widzisz, jest wyraźnym naruszeniem zasad; Jednak to może działać (i zwykle jest), jeśli cokolwiek aplikacji klienta poszukuje tego rekordu SRV jest wystarczająco inteligentny, aby prawidłowo obsługiwać rekord CNAME, nawet jeśli należy oczekując tylko rekord A w odpowiedzi.

Ale może też w ogóle nie działać: jest nieobsługiwany i całkowicie zależny od aplikacji klienckiej; dlatego należy tego unikać, ponieważ nie przestrzega właściwych zasad i może prowadzić do błędnych i / lub nieprzewidywalnych rezultatów.

Jest to podobne do wskazywania rekordu MX na CNAME, który jest zdefiniowany jako po prostu zły nie tylko w jednym , ale w dwóch RFC, a jednak jest to dość powszechna praktyka (i żaden serwer pocztowy nie wydaje się mieć z tym problemu).

— Massimo
źródło

Pamiętaj, że „wystarczająco inteligentny” jest względny. Niektórzy projektanci oprogramowania są zdania, że znoszenie implementacji braindead tylko zachęca do kolejnych implementacji tego samego. RFC 2781 został zaktualizowany tylko przez jeden RFC, a język o tym, czego się spodziewać, jest bardzo stanowczy, więc nie spodziewałbym się tutaj zbyt wiele litości.

— Andrew B,

Większość aplikacji klienckich polega na bibliotekach systemowych do wykonywania zapytań DNS, a większość bibliotek (szczególnie w językach wyższego poziomu) dołoży wszelkich starań, aby odpowiedzieć na każde zapytanie, które zadasz, i z radością i cicho podąży za CNAME do miejsca docelowego Rekord A i Adres IP.

— Massimo

Aplikacja nie wymaga wiele inteligencji, po prostu poprosi system operacyjny o połączenie się z „alias.domain.com” na porcie 4443 i pozostawi wszystkie szczegóły.

— Massimo

Aplikacja kliencka i biblioteki systemowe nie będą miały możliwości śledzenia aliasu, jeśli poprzedni rekursor odrzuci wiarygodne dane i odmówi kontynuacji. (co jest względnym sprytem, o którym mówiłem) Obsługa NSrekordów przez BIND i zabronione aliasing to klasyczny przykład tego. Niezależnie od tego jesteśmy zgodni, że jest to gra każdego z nieprzewidywalnymi rezultatami.

— Andrew B

Niektóre serwery pocztowe zaczęły aktywnie ignorować MX dla CNAME, np. GMX medienconsulting.at/…

— Marcel Waldvogel

To przykład ograniczonego zachowania, tak. Samo ograniczenie pochodzi z RFC 2781 w definicji „celu”:

   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.

Niestety oprogramowanie serwera DNS pozwalające na zabronione konfiguracje nie jest niczym nowym. Może i zdarza się, jak ma to miejsce w przypadku innych typów rekordów gdzie aliasingiem cele są zakazane, takich jak NSi MX. (wspomniano powyżej)

To, że można go znaleźć na wolności, nie oznacza, że jest „w porządku”, a to, co dzieje się, gdy standard jest ignorowany, różni się w zależności od produktu. Nie testowałem interakcji z SRVrekordami, ale bardzo dobrze znaną decyzją projektową ISC BIND w odniesieniu do NSrekordów wskazujących na aliasy jest całkowite usunięcie rekordu, jeśli zostanie znalezione podczas rekurencji. Jeśli wszystkie NSrekordy zostaną usunięte w ten sposób, wynikiem wszystkich zapytań będą SERVFAILdane subdomeny.

Krótko mówiąc, trzymaj się standardu. To jedyna bezpieczna rzecz do zrobienia.

— Andrew B.
źródło