Dlaczego rekord CNAME nie może być używany na szczycie (aka root) domeny?

To jest kanoniczne pytanie o CNAME na wierzchołkach (lub korzeniach) stref

Stosunkowo powszechnie wiadomo, że CNAMEzapisy na szczycie domeny są praktyką tabu.

Przykład: example.com. IN CNAME ithurts.example.net.

W najlepszym przypadku oprogramowanie serwera nazw może odmówić załadowania konfiguracji, aw najgorszym przypadku może zaakceptować tę konfigurację i unieważnić konfigurację na przykład.com.

Ostatnio miałem firmę hostingową, która przekazała instrukcje jednostce biznesowej, która była nam potrzebna do CNAME wierzchołka naszej domeny do nowego rekordu. Wiedząc, że byłaby to konfiguracja samobójcza po karmieniu BIND, poradziłam im, że nie będziemy w stanie się zastosować i że jest to ogólnie porada prycza. Firma zajmująca się hostingiem przyjęła stanowisko, że nie jest to absolutnie zabronione przez standardowe definiowanie RFC i że ich oprogramowanie to obsługuje. Gdybyśmy nie mogli CNAME wierzchołka, ich radą było, aby w ogóle nie mieć rekordu wierzchołka i nie zapewniliby serwera przekierowującego. ...Co?

Większość z nas wie, że RFC1912 nalega na to A CNAME record is not allowed to coexist with any other data., ale bądźmy szczerzy tutaj, że RFC ma jedynie charakter informacyjny. Najbliższe znane mi słowo, które zabrania praktyki, pochodzi z RFC1034 :

Jeśli CNAME RR jest obecny w węźle, żadne inne dane nie powinny być obecne; zapewnia to, że dane dla nazwy kanonicznej i jej aliasów nie mogą się różnić.

Niestety, jestem w branży wystarczająco długo, aby wiedzieć, że „nie powinien” to nie to samo, co „nie wolno”, i to wystarczy, aby większość projektantów oprogramowania mogła się zawiesić. Wiedząc, że nic poza zwięzłym linkiem do slamowego wsadu byłoby stratą mojego czasu, w końcu pozwoliłem firmie uniknąć zbesztania za zalecanie konfiguracji, które mogłyby zepsuć powszechnie używane oprogramowanie bez odpowiedniego ujawnienia.

To prowadzi nas do pytań i odpowiedzi. Tym razem chciałbym, abyśmy naprawdę spytali o szaleństwo wierzchołków CNAME, a nie omijali tego problemu, jak to zwykle bywa, gdy ktoś pisze na ten temat. RFC1912 jest poza limitem, podobnie jak inne informacyjne RFC obowiązujące tutaj, o których nie myślałem. Zamknijmy to dziecko.

CNAMErekordy zostały pierwotnie utworzone, aby umożliwić aliasy wielu nazw zapewniających ten sam zasób do pojedynczej „nazwy kanonicznej” dla zasobu. Wraz z pojawieniem się wirtualnego hostingu opartego na nazwach stało się powszechne stosowanie ich jako ogólnej formy aliasingu adresów IP. Niestety większość osób pochodzących z hostingu oczekuje, że CNAMErekordy wskażą równoważność w systemie DNS , co nigdy nie było zamierzone. Wierzchołek zawiera typy rekordów, które najwyraźniej nie są używane do identyfikacji kanonicznego zasobu hosta ( NS, SOA), którego nie można aliasować bez złamania standardu na poziomie podstawowym. (szczególnie w odniesieniu do cięć stref )

Niestety oryginalny standard DNS został napisany, zanim organy zarządzające standardami zdały sobie sprawę z tego, że wyraźne określenie było konieczne do zdefiniowania spójnego zachowania ( RFC 2119 ). Konieczne było stworzenie RFC 2181 w celu wyjaśnienia kilku przypadków narożnych z powodu niejasnego sformułowania, a zaktualizowany verbage wyjaśnia, że CNAME nie można użyć aliasingu wierzchołka bez złamania standardu.

6.1 Władze strefy

Autorytatywne serwery dla strefy są wyliczone w rekordach NS dotyczących pochodzenia strefy, które wraz z rekordem Start of Authority (SOA) są rekordami obowiązkowymi w każdej strefie. Taki serwer jest autorytatywny dla wszystkich rekordów zasobów w strefie, która nie znajduje się w innej strefie. Rekordy NS wskazujące na cięcie strefy są własnością utworzonej strefy podrzędnej, podobnie jak wszelkie inne rekordy dotyczące pochodzenia tej strefy podrzędnej lub jej subdomen. Serwer strefy nie powinien zwracać autorytatywnych odpowiedzi na zapytania związane z nazwami w innej strefie, która obejmuje NS, i być może A, rekordy przy odcięciu strefy, chyba że jest to również serwer dla innej strefy.

Potwierdza to, że SOAi NSzapisy są obowiązkowe, ale nie mówi nic o Alub innych rodzajów występujących tutaj. To może wydawać się zbyteczne, że zacytuję to, ale za chwilę stanie się ono bardziej odpowiednie.

RFC 1034 był nieco niejasny w kwestii problemów, które mogą pojawić się, gdy CNAMEistnieje obok innych typów rekordów. RFC 2181 usuwa niejasności i wyraźnie określa typy rekordów, które mogą istnieć obok nich:

10.1 Rekordy zasobów CNAME

Istnieje rekord CNAME DNS („nazwa kanoniczna”) zapewniający nazwę kanoniczną powiązaną z nazwą aliasu. Może istnieć tylko jedna taka nazwa kanoniczna dla dowolnego aliasu. Ta nazwa powinna na ogół być nazwą, która istnieje gdzie indziej w DNS, chociaż istnieją rzadkie aplikacje dla aliasów z towarzyszącą im nazwą kanoniczną niezdefiniowaną w DNS. Nazwa aliasu (etykieta rekordu CNAME) może, jeśli DNSSEC jest używany, zawierać SIG, NXT i KLUCZOWE RR, ale może nie zawierać innych danych. Oznacza to, że dla dowolnej etykiety w DNS (dowolnej nazwie domeny) dokładnie jedna z następujących czynności:

• istnieje jeden rekord CNAME, opcjonalnie wraz z SIG, NXT i KEY RR,
• istnieje jeden lub więcej rekordów, żaden nie jest rekordem CNAME,
• nazwa istnieje, ale nie ma żadnych powiązanych RR żadnego typu,
• nazwa w ogóle nie istnieje.

„nazwa aliasu” w tym kontekście odnosi się do lewej strony CNAMErekordu. Wypunktowanie sprawia, że wyraźnie jasne, że SOA, NSi Arekordy nie mogą być postrzegane w węźle, w którym CNAMEpojawia się również. Kiedy połączymy to z sekcją 6.1, niemożliwe jest CNAMEistnienie na szczycie, ponieważ musiałby żyć obok obowiązkowych SOAi NSzapisów.

(Wydaje się, że to robi robotę, ale jeśli ktoś ma krótszą ścieżkę do udowodnienia, prosimy o złamanie tego.)

Aktualizacja:

Wydaje się, że ostatnie zamieszanie wynika z niedawnej decyzji Cloudflare o zezwoleniu na zdefiniowanie nielegalnego rekordu CNAME na szczycie domen, dla których będą one syntetyzować rekordy A. „Zgodny z RFC”, zgodnie z opisem w powiązanym artykule, odnosi się do faktu, że rekordy zsyntetyzowane przez Cloudflare będą dobrze działać z DNS. Nie zmienia to faktu, że jest to zachowanie całkowicie niestandardowe.

Moim zdaniem jest to szkoda dla większej społeczności DNS: w rzeczywistości nie jest to rekord CNAME i wprowadza w błąd ludzi, którzy wierzą, że inne oprogramowanie nie jest w stanie na to pozwolić. (jak pokazuje moje pytanie)

Konsorcjum Systemów Internetowych opublikowało niedawno na szczycie strefy napis na CNAME , dlaczego istnieje to ograniczenie, oraz szereg alternatyw. Niestety nie zmieni się to w najbliższym czasie:

Nie możemy zmienić sposobu używania specjalnego rekordu CNAME bez jednoczesnej zmiany wszystkich implementacji serwera DNS na świecie. Jest tak, ponieważ jego znaczenie i interpretacja zostały ściśle określone w protokole DNS; wszystkie bieżące implementacje klienta i serwera DNS są zgodne z tą specyfikacją. Próba „rozluźnienia” sposobu używania CNAME na autorytatywnych serwerach bez jednoczesnej zmiany wszystkich aktualnie działających resolwerów DNS spowoduje, że rozpoznawanie nazw zostanie zerwane (a usługi internetowe i e-mailowe będą chwilowo niedostępne dla tych organizacji, które wdrażają „zrelaksowane” autorytatywne rozwiązania serwerowe.

Ale jest nadzieja:

Innym potencjalnym obecnie omawianym rozwiązaniem byłoby dodanie nowego typu rekordu zasobu dns, który przeglądałyby przeglądarki, który mógłby istnieć na szczycie. Będzie to specyficzna dla aplikacji nazwa hosta dla żądań HTTP (podobnie do sposobu działania MX).

Plusy: Jest to całkowicie zgodne z projektem DNS.
Minusy: To jeszcze nie jest dostępne i wymagałoby aktualizacji klienta przeglądarki.

Jeśli przekierowujesz całą strefę, powinieneś użyć DNAME. Zgodnie z RFC 6672 ,

The DNAME RR and the CNAME RR [RFC1034] cause a lookup to (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two resource records is that the CNAME RR directs the lookup of data at its owner to another single name, whereas a DNAME RR directs lookups for data at descendants of its owner's name to corresponding names under a different (single) node of the tree.

For example, take looking through a zone (see RFC 1034 [RFC1034], Section 4.3.2, step 3) for the domain name "foo.example.com", and a DNAME resource record is found at "example.com" indicating that all queries under "example.com" be directed to "example.net". The lookup process will return to step 1 with the new query name of "foo.example.net". Had the query name been "www.foo.example.com", the new query name would be "www.foo.example.net".