Czy w subdomenach (nazwa domeny) może znajdować się znak podkreślenia „_”?

Czy w subdomenach (nazwach domen) może znajdować się podkreślenie _?

Większość podanych tutaj odpowiedzi jest fałszywych . Podkreślenie nazwy domeny jest całkowicie legalne. Pozwólcie, że zacytuję standard, RFC 2181, sekcja 11, „Składnia nazwy” :

Sam DNS nakłada tylko jedno ograniczenie na poszczególne etykiety, których można użyć do identyfikacji rekordów zasobów. To jedno ograniczenie dotyczy długości etykiety i pełnej nazwy. [...] Implementacje protokołów DNS nie mogą nakładać żadnych ograniczeń na etykiety, których można użyć. W szczególności serwery DNS nie mogą odmówić obsługi strefy, ponieważ zawiera etykiety, które mogą nie być akceptowane przez niektóre programy klienckie DNS.

Zobacz także oryginalną specyfikację DNS, RFC 1034 , sekcja 3.5 „Preferowana składnia nazwy”, ale przeczytaj ją uważnie.

Domeny z podkreśleniami są bardzo popularne na wolności. Sprawdź _jabber._tcp.gmail.comlub _sip._udp.apnic.net.

Inne wspomniane tutaj RFC dotyczą różnych rzeczy. Pierwotne pytanie dotyczyło nazw domen . Jeśli pytanie dotyczy nazw hostów (lub adresów URL, które zawierają nazwę hosta), to jest inaczej, odpowiednim standardem jest RFC 1123 , sekcja 2.1 „Nazwy hostów i numery”, która ogranicza nazwy hostów do łączników z cyframi.

Uwaga na temat terminologii, w nawiązaniu do odpowiedzi Bortzmeyera

Definicje powinny być jasne. Stosowane tutaj:

• nazwa domeny to identyfikator zasobu w bazie danych DNS
• etykieta jest częścią nazwy domeny pomiędzy kropkami
• nazwa hosta to specjalny typ nazwy domeny, który identyfikuje hosty internetowe

Nazwa hosta podlega ograniczeniom RFC 952 i lekkiemu rozluźnieniu RFC 1123

RFC 2181 wyjaśnia, że ​​istnieje różnica między nazwą domeny a nazwą hosta:

... [fakt, że] każda etykieta binarna może mieć rekord MX, nie oznacza, że ​​każda nazwa binarna może być używana jako część hosta adresu e-mail ...

Więc podkreślenia w nazwach hostów są nie, nie, podkreślenia w nazwach domen są w porządku.

W praktyce dobrze widać nazwy hostów z podkreśleniami. Jak mówi zasada solidności : „Bądź konserwatywny w tym, co wysyłasz, liberalny w tym, co akceptujesz”.

Uwaga na temat kodowania

Okazuje się, że w XXI wieku nazwy hostów i domeny mogą być umiędzynarodowione! Oznacza to uciekanie się do kodowania w przypadku etykiet zawierających znaki spoza dozwolonego zestawu.

W szczególności pozwala celu zakodowania _w hostów (Aktualizacja 2017-07. Jest wątpliwe, zobaczyć komentarze _.. Wciąż nie może być stosowany w hostów Rzeczywiście, nie mogą być używane nawet w umiędzynarodowionych etykiet)

Pierwszym RFC do internacjonalizacji był RFC 3490 z marca 2003 r. „Internacjonalizacja nazw domen w aplikacjach (IDNA)”. Dzisiaj mamy:

• RFC 5890 „IDNA: definicje i ramy dokumentów”
• RFC 5891 „IDNA: protokół”
• RFC 5892 „Punkty kodu Unicode i IDNA”
• RFC 5893 „Skrypty od prawej do lewej dla IDNA”
• RFC 5894 „IDNA: tło, objaśnienia i uzasadnienie”
• RFC 5895 „Mapowanie znaków dla IDNA 2008”

Możesz także sprawdzić wpis w Wikipedii

RFC 5890 wprowadza pojęcie etykiety LDH (Letter-Digit-Hypen) dla etykiet używanych w nazwach hostów i mówi:

Jest to klasyczna forma etykiety używana, choć z pewnymi dodatkowymi ograniczeniami, w nazwach hostów (RFC 952). Jego składnia jest identyczna ze składnią opisaną jako „preferowana składnia nazwy” w sekcji 3.5 RFC 1034 zmodyfikowanej przez RFC 1123. W skrócie, jest to ciąg znaków składający się z liter, cyfr i myślnika ASCII, z dalszym ograniczeniem, że myślnik nie może pojawiają się na początku lub na końcu łańcucha. Podobnie jak wszystkie etykiety DNS, jego całkowita długość nie może przekraczać 63 oktetów.

Wracając do prostszych czasów, ten internetowy szkic jest wczesną propozycją internacjonalizacji nazwy hosta . Nazwy hostów ze znakami międzynarodowymi mogą być kodowane przy użyciu, na przykład, kodowania „RACE” .

Autor propozycji „kodowania RACE” zauważa:

Zgodnie z RFC 1035 części hosta nie rozróżniają wielkości liter, zaczynają się i kończą literą lub cyfrą oraz mogą zawierać tylko litery, cyfry i znak łącznika („-”). Wyklucza to oczywiście wszelkie internacjonalizowane znaki, a także wiele innych znaków w repertuarze znaków ASCII. Ponadto, nazwy domen muszą mieć 63 oktety lub krócej ... Wszystkie później przekształcone części nazw zawierające znaki internacjonalizowane zaczynają się od ciągu „bq--”. (...) Wybrano ciąg „bq--”, ponieważ jest bardzo mało prawdopodobne, aby istniał w częściach hosta przed wyprodukowaniem tej specyfikacji.

Jest jedna dodatkowa rzecz, którą możesz wiedzieć: jeśli część adresu URL hosta lub subdomeny zawiera znak podkreślenia, IE9 (nie testowałem innych wersji) nie może zapisywać plików cookie.

Uważaj więc na to. :-)

Wyjaśniające bortzmeyer i David Tonhofer , etykiety nazw domen i subdomen mogą zawierać wiodące podkreślenia, ale nigdzie indziej.

Jak napisał David Tonhofer , etykiety są częściami pomiędzy okresami i powinny być zgodne z regułą LDH, z wyjątkiem sytuacji, gdy określa się etykiety usług i etykiety portów, aby odróżnić je od zwykłych etykiet. Następnie muszą występować na początku etykiety, którą powinny być „Krótkie nazwy” z rejestru nazwy usługi i numeru portu, numeru portu bez wiodących zer lub protokołu (tj. Tcp, udp). Te etykiety usług są ponadto ograniczone do 15 znaków.

• RFC2782 określa subdomeny rekordów usług prefiksowania znakami podkreślenia.
• RFC6698 określa prefiksy numerów portów podkreśleniami w rekordach certyfikatów TLSA.

W przeciwieństwie do odpowiedzi Davida Tonhofera , IDN nie pozwala na kodowanie podkreślenia („_” U + 005F LOW LINE) ani żadnego innego nieprawidłowego znaku ASCII.

Z RFC5890

[..] dwa nowe podzbiory etykiet LDH są tworzone przez wprowadzenie IDNA. Są to tak zwane zastrzeżone etykiety LDH (etykiety R-LDH) i niezarezerwowane etykiety LDH (etykiety NR-LDH). Zarezerwowane etykiety LDH, zwane w niektórych innych kontekstach „tagowanymi nazwami domen”, mają właściwość, którą zawierają „-” w trzecim i czwartym znaku ale w przeciwnym razie są zgodne z regułami etykietowania LDH .

Punycode koduje bezpośrednio wszystkie punkty kodowe ASCII jako ASCII, w tym podkreślenie. Powstały R-LDH nie byłby zgodny z regułami etykietowania LDH. Na przykład Σ_.combyłby zakodowany jakoxn--_-zmb.com naruszający reguły. Może istnieć homograficzny punkt kodowy, który wygląda jak znak podkreślenia, który można zakodować zgodnie z prawem (być może „＿” U + FF3F o niskiej szerokości linii), ale tego rodzaju punkty kodowe zostałyby sklasyfikowane jako WYŁĄCZONE przez RFC5892 w punkcie 2.3 IgnorableProperties jako Noncharacter_Code_Point.

RACE (inny proponowany schemat kodowania IDN) nie został zaakceptowany przez IETF jako standard i nie należy go używać.

Po kliknięciu linku do RFC1034 przeczytałem większość i byłem zaskoczony, widząc to:

Etykiety muszą być zgodne z regułami dla nazw hostów ARPANET. Muszą zaczynać się od litery, kończyć literą lub cyfrą i mieć jako znaki wewnętrzne tylko litery, cyfry i łączniki. Istnieją również pewne ograniczenia dotyczące długości. Etykiety muszą mieć maksymalnie 63 znaki.

Dla wyjaśnienia nazwy domen składają się z etykiet oddzielonych kropkami „.”. Ta specyfikacja musi być nieaktualna, ponieważ nie wspomina o użyciu podkreślników. Mogę zrozumieć zamieszanie, jeśli ktoś potknie się o tę specyfikację, nie wiedząc, że jest przestarzała. To jest przestarzałe, prawda?

Połączyłem się z linkiem do RFC2181 i przeczytałem trochę. Zwłaszcza tam, gdzie dotyczy to kwestii autorytatywnej lub kanonicznej nazwy oraz kwestii tego, co stanowi prawidłową etykietę DNS.

Jak napisano wcześniej, stwierdzono, że istnieje tylko ograniczenie długości, a następnie podsumowując, brzmi:

(o nazwach i prawidłowych etykietach)

Są one już odpowiednio określone, jednak specyfikacje wydają się czasem ignorowane. Staramy się wzmocnić istniejące specyfikacje.

W pewnym sensie zastanawiam się, czy „ograniczenie tylko długości” jest „odpowiednie”. Czy zaczniemy widzieć nazwy domen takie jak @ # $% !! wkrótce? Czy internet nie jest zepsuty?

Ostatnio zdecydowało o tym forum CAB (*)

Wszystkie certyfikaty zawierające znak podkreślenia w dowolnym wpisie dNSName i mające okres ważności dłuższy niż 30 dni MUSZĄ zostać odwołane przed 15 stycznia 2019 r. Https://cabforum.org/2018/11/12/ballot-sc-12- sunset-of-underscores-in-dnsnames /

Oznacza to, że nie możesz już używać podkreślników w domenach, które będą miały certyfikat ssl / tls.

(*) Forum przeglądarki urzędu certyfikacji (CA / Browser Forum) to dobrowolne zgromadzenie wiodących wystawców certyfikatów (zgodnie z definicją w sekcji 2.1 (a) (1) i (2) poniżej) oraz dostawców oprogramowania przeglądarki internetowej i innych aplikacji, które stosować certyfikaty (konsumenci certyfikatów, zgodnie z definicją w sekcji 2.1 (a) (3) poniżej).

Poszczególne domeny TLD mogą nakładać własne reguły i ograniczenia dotyczące nazw domen które uznają za stosowne, na przykład w celu dostosowania do lokalnych języków.

Na przykład według CIRA.ca dozwolone są nazwy domen Kanady :

• Litery apoprzez zoraz następujące znaki akcentowane: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Pamiętaj, że w nazwach domen nie jest rozróżniana wielkość liter. Oznacza to, że nie będzie rozróżnienia między dużymi i małymi literami ( A= a);

• Liczby 0123456789i

• Znak łącznika („ -) (chociaż nie może być użyty do rozpoczęcia ani zakończenia nazwy domeny).

Maksymalna długość wynosi 63 znaki, ale każda akcentowana postać zmniejsza ten limit o 4 znaki.

( Źródło )

_{Nawiasem mówiąc, pozwala to na około 4 czterokrotne możliwości nazw domen (nie licząc subdomen) dla domen dot-ca.}

Oto moje 2 centy ze świata Java:

Z konsoli Spark Scala z Javą 8:

scala> new java.net.URI("spark://spark_master").getHost
res10: String = null

scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master

scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null

scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr

scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr

scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null

To zdecydowanie zły pomysł ^^

Właśnie stworzyłem projekt lokalny (z włóczęgą) i działał idealnie, gdy był dostępny przez adres IP. Następnie dodałem plik nazwa_testu.test do pliku hosts i próbowałem uzyskać do niego dostęp w ten sposób, ale ciągle otrzymywałem „złe żądanie - 400”. Zmarnowałem godziny, zanim zorientowałem się, że zmiana nazwy domeny na some-name.test rozwiązuje problem. Więc przynajmniej lokalnie w systemie Mac OS nie działa.

Nie, w subdomenie nie można używać podkreślenia, ale łącznik (myślnik). tzn. moja-subdomena.agahost.com jest akceptowalna, a moja-subdomena.agahost.com nie byłaby akceptowana.

Nie, jeśli chcesz to rozwiązać w Internecie.

Nie możesz mieć: http://ma_subdomain.example.com jest nieprawidłowy.

Możesz mieć: http://my-subdomain.example.com z łącznikiem.