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.
+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
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:
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.
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.
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.
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.
[..] 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ć.
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?
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]. ”
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.
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.
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.
Odpowiedzi:
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” :
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.com
lub_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.
źródło
_jabber._tcp.gmail.com
to 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.Uwaga na temat terminologii, w nawiązaniu do odpowiedzi Bortzmeyera
Definicje powinny być jasne. Stosowane tutaj:
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:
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:
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:
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:
źródło
bar.baz.
(na przykład) jest po prostu zbiorem nazw domen, które są hierarchicznie pod spodembar.baz.
, npa.bar.baz.
,f.g.bar.baz.
,h.bar.baz.
itp. Ta „subdomena” może zawierać rzeczywiste nazwy hostów .a.bar.baz
(nazwa domeny) „subdomeną” ciągubar.baz
(inna nazwa domeny). Nazwy domen (zasoby bazy danych DNS)a.bar.baz
ibar.baz
mogą, ale nie muszą, być nazwami hostów .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. :-)
źródło
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
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
Σ_.com
był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ć.
źródło
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?
źródło
Ostatnio zdecydowało o tym forum CAB (*)
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).
źródło
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 :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.
źródło
Oto moje 2 centy ze świata Java:
Z konsoli Spark Scala z Javą 8:
To zdecydowanie zły pomysł ^^
źródło
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.
źródło
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.
źródło
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.
źródło