Rekord CNAME

nazwy kanonicznej (CNAME) to typ rekordu zasobu w systemie nazw domen (DNS), który odwzorowuje jedną nazwę domeny (alias) na inną ( nazwę kanoniczną ).

Może to okazać się wygodne w przypadku uruchamiania wielu usług (takich jak serwer FTP i serwer WWW , z których każda działa na różnych portach) z jednego adresu IP. Można na przykład użyć rekordów CNAME, aby wskazać ftp.example.com i www.example.com na wpis DNS na przykład.com , który z kolei ma rekord A wskazujący na adres IP. Wtedy, jeśli kiedykolwiek zmieni się adres IP, wystarczy odnotować zmianę w jednym miejscu w sieci: w rekordzie DNS A, np. example.com .

Rekordy CNAME muszą zawsze wskazywać inną nazwę domeny, nigdy bezpośrednio na adres IP.

Detale

Rekordy DNS CNAME są określone w dokumencie RFC 1034 i wyjaśnione w sekcji 10 dokumentu RFC 2181.

Rekordy CNAME są obsługiwane specjalnie w systemie nazw domen i mają kilka ograniczeń dotyczących ich używania. Gdy program rozpoznawania nazw DNS napotka rekord CNAME podczas wyszukiwania zwykłego rekordu zasobu, ponownie uruchomi zapytanie, używając nazwy kanonicznej zamiast nazwy oryginalnej. (Jeśli program tłumaczący ma specjalnie nakazać szukanie rekordów CNAME, zwracana jest nazwa kanoniczna (po prawej stronie) zamiast ponownego uruchamiania zapytania.) Nazwa kanoniczna, na którą wskazuje rekord CNAME, może znajdować się w dowolnym miejscu w DNS, niezależnie od tego, czy jest lokalna lub na zdalnym serwerze w innej strefie DNS .

Na przykład, jeśli istnieje strefa DNS w następujący sposób:

NAZWA TYP WARTOŚĆ -------------------------------- --- bar.example.com. CNAME foo.example.com. foo.example.com. 192.0.2.23

gdy przeprowadzane jest wyszukiwanie rekordu A dla bar.example.com , program tłumaczący zobaczy rekord CNAME i ponownie rozpocznie sprawdzanie pod adresem foo.example.com , a następnie zwróci 192.0.2.23.

Możliwe zamieszanie

Za pomocą rekordu CNAME można wskazać nazwę, taką jak „ bar.example.com ” na „ foo.example.com ”. Z tego powodu podczas swobodnej dyskusji bar.example.com . (lewa strona) wpisu DNS może zostać błędnie zidentyfikowana jako „CNAME” lub „CNAME”. Jest to jednak niedokładne. Kanoniczna (prawdziwa) nazwa „ bar.example.com. ” to „ foo.example.com ”. Ponieważ CNAME oznacza nazwę kanoniczną, prawa strona to rzeczywista „ CNAME”; po tej samej stronie co adres „A”.

To zamieszanie jest wyraźnie wspomniane w RFC 2181, „Wyjaśnienia specyfikacji DNS”. Lewa etykieta jest aliasem prawej strony (część RDATA), która jest (lub powinna być) nazwą kanoniczną. Innymi słowy, taki rekord CNAME:

bar.example.com. CNAME foo.example.com.

można odczytać jako: bar.example.com jest aliasem nazwy kanonicznej (CNAME) foo.example.com . Klient zażąda bar.example.com , a odpowiedzią będzie foo.example.com .

Ograniczenia

Rekordy CNAME muszą zawsze wskazywać inną nazwę domeny, nigdy adres IP.
Jeśli rekord CNAME 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ć. (RFC 1034 sekcja 3.6.2, RFC 1912 sekcja 2.4) Wyjątkiem jest sytuacja, gdy używane jest DNSSEC , w którym to przypadku mogą istnieć rekordy związane z DNSSEC, takie jak RRSIG, NSEC itp. (RFC 2181 sekcja 10.1)
Rekordów CNAME wskazujących na inne rekordy CNAME należy unikać ze względu na ich małą wydajność, ale nie są one błędem. Możliwe jest zatem tworzenie nierozwiązywalnych pętli z rekordami CNAME, jak w:
```
 foo.example.com. Pasek CNAME.example.com.  bar.example.com.  CNAME foo.example.com.  
```
rekord CNAME nie może znajdować się na wierzchołku strefy. RFC 1034 sekcja 4.2.1 wymaga rekordu SOA w wierzchołku strefy, a RFC 1034 sekcja 3.6.2 wymaga, aby żadne inne rekordy nie były obecne, jeśli obecny jest rekord CNAME. Dlatego rekord CNAME nie może pojawić się na wierzchołku strefy.
Rekordy CNAME obsługiwane przez rekordy DNAME mogą powodować pętle rekurencyjne w starszych programach rozpoznawania nazw. ^{[ wymagane wyjaśnienie ]}
Rekordy MX i NS nigdy nie mogą wskazywać na alias CNAME (RFC 2181 sekcja 10.3). Na przykład strefa nie może zawierać konstrukcji takich jak:
```
 example.com. MX 0 foo.example.com.  foo.example.com.  CNAME host.example.com.  host.example.com.  192.0.2.1  
```
Domeny używane w poleceniach SMTP MAIL i RCPT mogą nie mieć rekordu CNAME. W praktyce może to działać, ale może mieć różne zachowanie na różnych serwerach pocztowych i może mieć niepożądane skutki.

Rekord DNAME

Rekord DNAME lub Delegation Name jest zdefiniowany w RFC 6672 (oryginalny RFC 2672 jest już przestarzały). Rekord DNAME tworzy alias dla całego poddrzewa drzewa nazw domen. Natomiast rekord CNAME tworzy alias dla pojedynczej nazwy, a nie dla jej subdomen. Podobnie jak w przypadku rekordu CNAME, wyszukiwanie DNS będzie kontynuowane, ponawiając próbę wyszukiwania z nową nazwą. Serwer nazw syntetyzuje rekord CNAME, aby faktycznie zastosować rekord DNAME do żądanej nazwy — rekordy CNAME dla każdego węzła w poddrzewie mają taki sam efekt jak DNAME dla całego poddrzewa.

Na przykład, jeśli istnieje strefa DNS w następujący sposób:

foo.example.com. Pasek DNAME.example.com. bar.example.com. A 192.0.2.23 xyzzy.bar.example.com. A 192.0.2.24 *.bar.example.com. 192.0.2.25

A dla foo.example.com nie zwróci żadnych danych, ponieważ DNAME nie jest CNAME i nie ma rekordu A bezpośrednio w foo .

Jednak wyszukiwanie xyzzy. foo .example.com zostanie odwzorowane na DNAME i zwróci rekord A dla xyzzy. bar .example.com , czyli 192.0.2.24; gdyby rekord DNAME był rekordem CNAME, to żądanie zwróciłoby nazwę, której nie znaleziono.

Na koniec żądanie foobar.foo.example.com zostałoby zmapowane jako DNAME i zwrócone 192.0.2.25.

Rekord ANAME

Kilka zarządzanych platform DNS implementuje niestandardowy typ rekordu ALIAS lub ANAME. Te pseudorekordy są zarządzane przez administratorów DNS, takich jak rekordy CNAME, ale są publikowane i rozstrzygane przez (niektórych) klientów DNS, takich jak rekordy A. Rekordy ANAME są zwykle skonfigurowane tak, aby wskazywały inną domenę, ale gdy klient zapyta, odpowiedz, podając adres IP. Typy rekordów ANAME przechodziły standaryzację, ale prawdopodobnie istnieje wiele niezgodnych implementacji, więc mogą robić wszystko, co wybierze właściciel platformy DNS, w tym istnieć na szczycie strefy i istnieć dla domen odbierających pocztę. Jedną z możliwych przewag rekordów ANAME nad rekordami CNAME jest szybkość; klient DNS wymaga co najmniej dwóch zapytań, aby przetłumaczyć CNAME na rekord A na adres IP, podczas gdy tylko jedno zapytanie jest potrzebne, aby przetłumaczyć ANAME na adres IP. Zakłada się, że serwer DNS może rozpoznać rekord A i buforować żądany adres IP wydajniej iz mniejszym opóźnieniem niż jego klienci DNS. Typ rekordu ANAME był projektem standardu rozważanym przez IETF, ale ostatni projekt dokumentu wygasł w styczniu 2020 r.

Zobacz też

Linki zewnętrzne

RFC 1912 jest błędny — analiza ograniczeń CNAME przeprowadzona przez Meng Weng Wonga
RFC 2219 — Używanie aliasów DNS dla usług sieciowych