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

212

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

Daniel Kivatinos
źródło
12
Podjąłem twoje pytanie dosłownie: że naprawdę miałeś na myśli DOMAIN NAMES. Jeśli zamiast tego miałeś na myśli HOST NAMES, edytuj swoje pytanie, ponieważ odpowiedź będzie inna.
bortzmeyer

Odpowiedzi:

362

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.

bortzmeyer
źródło
73
+1 za różnicę między „nazwami domen” a „nazwami hostów”
Alnitak
3
Pytanie (chyba że było edytowane) dotyczy subdomen, tj. nazwy hostów. Nie mylisz się co do swoich faktycznych stwierdzeń, z wyjątkiem wskazania, że ​​odpowiedzi są fałszywe, w oparciu o to, jak sformułowane jest obecnie pytanie.
redreinard
4
Jestem zdezorientowany, 1034 mówi: „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”. Która część tego pozwala na podkreślenie?
claudekennilol
2
Sformułowanie jest mylące. Adresy URL nie mogą zawierać podkreślników. Adres URL jest zawsze nazwą FQDN, nie jest to nazwa hosta. Nazwa FQDN może mieć pustą nazwę hosta, w tym przypadku FQDN = domena. _jabber._tcp.gmail.comto nie domena, to FQDN. Ponieważ adresy URL nie mogą zawierać podkreślników, prawdopodobnie nigdy nie będziesz w stanie kupić domeny z podkreśleniem. Tak więc, nawet w przypadku domen może istnieć podkreślenie z punktu widzenia składni DNS, nigdy ich nie spotkasz, chyba że jest to lokalny.
Kapsuła
1
Nie widzę cytatu w 2.1 rfc1123, który wspomina o dozwolonych łącznikach. Widzę w rfc952, że nazwa może być <let-or-digit-or-hyphen>. Czy o to ci chodziło?
AJP
93

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.

David Tonhofer
źródło
Na marginesie: „Systemy takie jak DomainKeys i rekordy usług używają podkreślenia jako środka zapewniającego, że ich znak specjalny nie jest mylony z nazwami hostów. Na przykład _http._sctp.www.example.com określa wskaźnik usługi dla SCTP zdolny host serwera WWW (www) w domenie example.com. ” ( link )
x-yuri
Zignoruj ​​części kodujące RACE, IDN już ustawił konwersję znaków internacjonalizowanych do ASCII przy użyciu prefiksu „xn--”.
mootmoot
2
@ Nelda.techspiress Minęło trochę czasu, ale zgodnie z RFC 1034: Domeny - Pojęcia i Urządzeń , co nazywa się „subdomeny” domeny bar.baz.(na przykład) jest po prostu zbiorem nazw domen, które są hierarchicznie pod spodem bar.baz., np a.bar.baz., f.g.bar.baz., h.bar.baz.itp. Ta „subdomena” może zawierać rzeczywiste nazwy hostów .
David Tonhofer,
2
W codziennym użyciu może się niepoprawnie nazywać ciąg a.bar.baz(nazwa domeny) „subdomeną” ciągu bar.baz(inna nazwa domeny). Nazwy domen (zasoby bazy danych DNS) a.bar.bazi bar.bazmogą, ale nie muszą, być nazwami hostów .
David Tonhofer,
1
Na stronie 8 RFC 1034 czytamy: Domena jest identyfikowana przez nazwę domeny i składa się z tej części przestrzeni nazw domeny, która znajduje się pod nazwą domeny lub poniżej niej, która określa domenę. Domena jest poddomeną innej domeny, jeśli jest zawarta w tej domenie. Ten związek można przetestować, sprawdzając, czy nazwa subdomeny kończy się nazwą zawierającą domenę. Na przykład ABCD jest poddomeną BCD, CD, D i „”.
David Tonhofer,
47

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. :-)

Kai Mattern
źródło
2
Powtarzalne w IE7: stackoverflow.com/questions/794243/…
Piskvor opuścił budynek
3
Właśnie to mieliśmy w projekcie - i miałem już szaleć za dziwnymi problemami z IE. Dopóki nie odkryliśmy podkreślenia w subdomenie. ; o)
Kai Mattern,
3
Nadal problem w IE10. Czy stwardnienie rozsiane wie o tym?
Piotr Kula
15
Bardziej istotne: czy MS obchodzi to?
Ajax,
11

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.

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ć.

Andrzej Domaszek
źródło
1
Wreszcie. Nie mogę uwierzyć, że jest to jedyny post na całej stronie, który mówi nawet o punycode.
Pacerier
6

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?

Ted Cambron
źródło
3
Nie, to nie jest przestarzałe. RFC1034 to specyfikacja nazw hostów , szczególnego przypadku nazw domen , które są ogólnymi identyfikatorami zasobów w bazie danych DNS. Na przykład część „hosta” identyfikatorów URI jest definiowana raczej spokojnie ( tools.ietf.org/html/rfc3986#section-3.2.2 ), ale przestroga RFC: „Host identyfikowany przez zarejestrowaną nazwę jest zwykle ciągiem znaków przeznaczony do wyszukiwania w lokalnie zdefiniowanym rejestrze nazw hosta lub usługi ... zarejestrowana nazwa przeznaczona do wyszukiwania w DNS wykorzystuje składnię zdefiniowaną w sekcji 3.5 [RFC1034] i sekcji 2.1 [RFC1123]. ”
David Tonhofer,
3

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).

użytkownik906489
źródło
1

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.

ashleedawg
źródło
0

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ł ^^

Thomas Decaux
źródło
0

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.

MilanG
źródło
0

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.

Kashif Iqbal
źródło
-2

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.

zaradny idiota
źródło
Jest po 15 stycznia 2019 r. - Twój licznik nie działa.
Joe Inwap
@JoeInwap Czy możesz wskazać mi źródło swojego komentarza?
ankshah
Byłem na cabforum.org/2018/11/12/… i fakt, że o_o.lgms.nl przedstawia certyfikat, który nie jest prawidłowy dla tej nazwy hosta. Nazwa jednak rozwiązuje.
Joe Inwap,