Odpowiedź Svena z edycją jest już słuszna, ale wystarczy sformułować rzeczy bezpośrednio.
TL; DR tak podkreślenie jest ważne w CNAMEzapisie po obu stronach, przeczytaj poniżej, dlaczego.
RFC 1034 i inne definiują rekordy na podstawie „nazw domen”, które są etykietami z dowolnym znakiem, a więc także _.
Jednak niektóre rekordy mają bardziej rygorystyczne reguły dla nazwy właściciela i / lub danych zasobów (RDATA). Akceptowana będzie tylko nazwa hosta, a zasady są teraz (w przeszłości były luźniejsze, gdy nazwa hosta nie mogła zaczynać się cyfrą), że możesz użyć dowolnej litery ASCII (bez rozróżniania wielkości liter), dowolnych cyfr ASCII i łączników , plus dodatkowe reguły pozycji: brak łącznika na początku i na końcu oraz brak podwójnych łączników na pozycjach 3 i 4 (z powodu „rezerwacji” dla domen IDN, które są w formie, xn--która jest dozwolona tylko w przypadku).
Na przykład nazwa właściciela Alub AAAArekordu jest nazwą hosta, a nie nazwą domeny. test.example.com A 192.0.2.1Jest więc
ważne, dlaczego nie wszystkie z nich są:
_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1
Program jest łatwy do testowania named-checkzone(część bindoprogramowania serwera nazw, ale można go używać i instalować osobno, a inne serwery nazw mogą mieć podobne narzędzia do sprawdzania i prawdopodobnie są do tego również interfejsy online), wystarczy umieścić rekordy w pliku i uruchomić to na:
$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)
(liczba przed INjest TTL, nie ma to związku z naszym problemem tutaj, ale wystarczyło tylko przekazać poprawność składniową rekordu).
W przypadku innych rekordów jest odwrotnie: NSnie ma żadnych ograniczeń dotyczących właściciela, ale ograniczenia dotyczące „celu”, czyli danych. Dane mogą być tylko nazwą hosta, a nie nazwą domeny, ponieważ musisz wskazać autorytatywne serwery nazw, które są fizycznymi hostami, które odpowiadają na zapytania DNS.
Teraz o CNAME, tutaj są odpowiednie cytaty z RFC 1034, w sekcji 3.6:
„właściciel: to nazwa domeny, na której znajduje się RR.” co oznacza domyślnie dowolną nazwę, nie tylko nazwę hosta (jako źródło rekordu CNAME)
„RDATA: który typ danych, a czasem dane zależne od klasy, które opisują zasób:”
„CNAME nazwa domeny”.
Tak więc zarówno właściciel CNAME(po lewej), jak i dołączone do niego dane zasobu, jego miejsce docelowe / cel (po prawej) to nazwy domen, a nie tylko nazwy hostów. Zasadniczo dowolna postać, więc włączenie _jest dozwolone po obu stronach.
Ponownie, łatwe do przetestowania za pomocą named-checkzone:
$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.
Żadnych błędów w CNAME(inne błędy są spodziewane, ponieważ w mojej fałszywej strefie nie umieściłem żadnych SOAlub NSzapisy takie jak w prawdziwej strefie)