Können Subdomains (Domainnamen) Unterstriche enthalten _
?
Können Subdomains (Domainnamen) Unterstriche enthalten _
?
Antworten:
Die meisten hier gegebenen Antworten sind falsch . Es ist völlig legal, einen Unterstrich in einem Domainnamen zu haben. Lassen Sie mich den Standard RFC 2181, Abschnitt 11, "Namenssyntax" zitieren :
Der DNS selbst legt nur eine Einschränkung für die bestimmten Bezeichnungen fest, mit denen Ressourceneinträge identifiziert werden können. Diese eine Einschränkung bezieht sich auf die Länge des Etiketts und den vollständigen Namen. [...] Durch die Implementierung der DNS-Protokolle dürfen die verwendbaren Labels nicht eingeschränkt werden. Insbesondere dürfen DNS-Server die Bereitstellung einer Zone nicht verweigern, da sie Beschriftungen enthält, die für einige DNS-Clientprogramme möglicherweise nicht akzeptabel sind.
Siehe auch die ursprüngliche DNS-Spezifikation, RFC 1034 , Abschnitt 3.5 "Bevorzugte Namenssyntax", aber lesen Sie sie sorgfältig durch.
Domänen mit Unterstrichen sind in freier Wildbahn sehr verbreitet. Überprüfen Sie _jabber._tcp.gmail.com
oder _sip._udp.apnic.net
.
Andere hier erwähnte RFC befassen sich mit anderen Dingen. Die ursprüngliche Frage betraf Domainnamen . Wenn es sich um Hostnamen handelt (oder um URLs, die einen Hostnamen enthalten), ist dies anders. Der relevante Standard ist RFC 1123 , Abschnitt 2.1 " Hostnamen und -nummern", der Hostnamen auf Buchstaben-Ziffern-Bindestrich beschränkt.
_jabber._tcp.gmail.com
ist keine Domain, sondern ein vollqualifizierter Domänenname. Da URLs keinen Unterstrich enthalten dürfen, können Sie wahrscheinlich nie eine Domain mit einem Unterstrich kaufen. Selbst wenn Domains aus Sicht der DNS-Syntax Unterstriche haben könnten, werden Sie niemals auf einen stoßen, es sei denn, es handelt sich um einen lokalen.
Über Definitionen sollte man sich klar sein. Wie hier verwendet:
Der Hostname unterliegt den Einschränkungen von RFC 952 und der leichten Lockerung von RFC 1123
RFC 2181 macht deutlich, dass es einen Unterschied zwischen einem Domänennamen und einem Hostnamen gibt:
... [die Tatsache, dass] jedes Binäretikett einen MX-Eintrag haben kann, bedeutet nicht, dass ein Binärname als Host-Teil einer E-Mail-Adresse verwendet werden kann ...
Unterstriche in Hostnamen sind also ein Nein-Nein, Unterstriche in Domainnamen .
In der Praxis kann man durchaus Hostnamen mit Unterstrichen sehen. Als Robustheitsprinzip sagt: "Sei konservativ in dem, was du sendest, liberal in dem, was du akzeptierst."
Im 21. Jahrhundert stellt sich heraus, dass sowohl Hostnamen als auch Domainnamen internationalisiert werden können! Dies bedeutet, dass bei Etiketten auf Codierungen zurückgegriffen wird dass , die Zeichen enthalten, die außerhalb des zulässigen Satzes liegen .
Insbesondere ermöglicht es einem, die _
in Hostnamen zu codieren (Update 2017-07: Dies ist zweifelhaft, siehe Kommentare_
immer noch nicht in Hostnamen verwendet werden. Tatsächlich kann sie nicht einmal in internationalisierten Labels verwendet werden.)
Der erste RFC für die Internationalisierung war der RFC 3490 vom März 2003, "Internationalisierung von Domainnamen in Anwendungen (IDNA)". Heute haben wir:
Vielleicht möchten Sie auch den Wikipedia-Eintrag überprüfen
RFC 5890 führt den Begriff LDH-Label (Letter-Digit-Hypen) für Labels ein, die in Hostnamen verwendet werden, und lautet:
Dies ist die klassische Etikettenform, die, wenn auch mit einigen zusätzlichen Einschränkungen, in Hostnamen verwendet wird (RFC 952). Seine Syntax ist identisch mit der in Abschnitt 3.5 von RFC 1034 als "bevorzugte Namenssyntax" beschriebenen, von RFC 1123 geänderten Syntax. Kurz gesagt handelt es sich um eine Zeichenfolge, die aus ASCII-Buchstaben, Ziffern und dem Bindestrich mit der weiteren Einschränkung besteht, die der Bindestrich nicht kann erscheinen am Anfang oder Ende der Zeichenfolge. Wie bei allen DNS-Labels darf die Gesamtlänge 63 Oktette nicht überschreiten.
Dieser Internetentwurf geht auf einfachere Zeiten zurück und ist ein früher Vorschlag für die Internationalisierung von Hostnamen . Hostnamen mit internationalen Zeichen können beispielsweise mit der RACE-Codierung codiert werden .
Der Autor des Vorschlags zur RACE-Codierung stellt fest:
Gemäß RFC 1035 müssen Host-Teile die Groß- und Kleinschreibung nicht berücksichtigen, mit einem Buchstaben oder einer Ziffer beginnen und enden und dürfen nur Buchstaben, Ziffern und den Bindestrich ("-") enthalten. Dies schließt natürlich alle internationalisierten Zeichen sowie viele andere Zeichen im ASCII-Zeichenrepertoire aus. Außerdem müssen Domain-Namensteile 63 Oktette oder kürzer sein. Alle nachkonvertierten Namensteile, die internationalisierte Zeichen enthalten, beginnen mit der Zeichenfolge "bq--". (...) Die Zeichenfolge "bq--" wurde gewählt, da es äußerst unwahrscheinlich ist, dass sie in Host-Teilen vorhanden ist, bevor diese Spezifikation erstellt wurde.
bar.baz.
nur die Sammlung von Domain - Namen (zum Beispiel) , die hierarchisch unterhalb sind bar.baz.
, zum Beispiel a.bar.baz.
, f.g.bar.baz.
, h.bar.baz.
usw. Diese "Subdomain" kann tatsächliche Hostnamen enthalten oder nicht .
a.bar.baz
(ein Domänenname) fälschlicherweise als "Subdomain" der Zeichenfolge bar.baz
(ein anderer Domänenname) bezeichnet wird. Die Domänennamen (DNS-Datenbankressourcen) a.bar.baz
und bar.baz
können Hostnamen sein oder nicht .
Es gibt noch eine weitere Sache, die Sie möglicherweise wissen müssen: Wenn der Host- oder Subdomain-Teil der URL einen Unterstrich enthält, kann IE9 (andere Versionen nicht getestet) keine Cookies schreiben.
Also sei vorsichtig damit. :-)
Zur Klärung von Bortzmeyer und David Tonhofer können Domain- und Subdomain-Namensbezeichnungen führende Unterstriche enthalten, aber nirgendwo anders.
Wie David Tonhofer schrieb, sind Etiketten die Teile zwischen den Perioden und sollten der LDH-Regel folgen, außer wenn Serviceetiketten und Portetiketten angegeben werden, um sie von regulären Etiketten zu unterscheiden. Dann müssen sie am Anfang des Etiketts stehen. Dies sollten die "Kurznamen" aus der Registrierung für Dienstnamen und Portnummern, die Portnummer ohne führende Nullen oder das Protokoll (dh tcp, udp) sein. Diese Service-Labels sind weiterhin auf 15 Zeichen beschränkt.
Im Gegensatz zu David Tonhofers Antwort erlaubt IDN keine Codierung von Unterstrichen ('_' U + 005F LOW LINE) oder anderen ungültigen ASCII-Zeichen.
Von RFC5890
[..] Durch die Einführung von IDNA werden zwei neue Untergruppen von LDH-Labels erstellt. Diese werden als reservierte LDH-Etiketten (R-LDH-Etiketten) und nicht reservierte LDH-Etiketten (NR-LDH-Etiketten) bezeichnet. Reservierte LDH-Labels, die in einigen anderen Kontexten als "getaggte Domain-Namen" bezeichnet werden, haben die Eigenschaft, dass sie im dritten und vierten Zeichen "-" enthalten , ansonsten aber den LDH-Label-Regeln entsprechen .
Punycode codiert alle ASCII-Codepunkte direkt als ASCII, einschließlich Unterstrich. Das resultierende R-LDH würde nicht den LDH-Kennzeichnungsregeln entsprechen. Zum Beispiel Σ_.com
würde codiert, xn--_-zmb.com
was gegen die Regeln verstößt. Möglicherweise gibt es einen homografischen Codepunkt, der wie ein Unterstrich aussieht, der legal codiert werden kann (möglicherweise niedrige Zeile _ U + FF3F mit voller Breite), aber diese Arten von Codepunkten werden von RFC5892 als NICHT ERLAUBT eingestuft unter 2.3 IgnorableProperties als Noncharacter_Code_Point als NICHT zulässig eingestuft.
RACE (das andere vorgeschlagene IDN-Codierungsschema) wurde von der IETF nicht als Standard akzeptiert und sollte nicht verwendet werden.
Ich folgte dem Link zu RFC1034 und las das meiste davon und war überrascht, dies zu sehen:
Die Beschriftungen müssen den Regeln für ARPANET-Hostnamen entsprechen. Sie müssen mit einem Buchstaben beginnen, mit einem Buchstaben oder einer Ziffer enden und als innere Zeichen nur Buchstaben, Ziffern und Bindestriche enthalten. Es gibt auch einige Einschränkungen hinsichtlich der Länge. Beschriftungen dürfen maximal 63 Zeichen lang sein.
Zur Verdeutlichung bestehen Domainnamen aus Labels, die durch Punkte "." Getrennt sind. Diese Spezifikation muss veraltet sein, da die Verwendung von Unterstrichen nicht erwähnt wird. Ich kann die Verwirrung verstehen, wenn jemand über diese Spezifikation stolpert, ohne zu wissen, dass sie veraltet ist. Es ist veraltet, nicht wahr?
Ich folgte dem Link zu RFC2181 und las einige davon. Insbesondere, wenn es um die Frage geht, was ein maßgeblicher oder kanonischer Name ist, und um die Frage, was ein gültiges DNS-Label ausmacht.
Wie bereits erwähnt, gibt es nur eine Längenbeschränkung. Zusammenfassend heißt es:
(über Namen und gültige Etiketten)
Diese sind bereits ausreichend spezifiziert, jedoch scheinen die Spezifikationen manchmal ignoriert zu werden. Wir bemühen uns, die bestehenden Spezifikationen zu verstärken.
Ich frage mich, ob "eine Beschränkung nur auf die Länge" "angemessen" ist. Werden wir Domainnamen wie @ # $% sehen !! demnächst? Ist das Internet nicht kaputt genug?
Kürzlich hat das CAB-Forum (*) das entschieden
Alle Zertifikate, die in einem dNSName-Eintrag einen Unterstrich enthalten und eine Gültigkeitsdauer von mehr als 30 Tagen haben, MÜSSEN vor dem 15. Januar 2019 widerrufen werden. Https://cabforum.org/2018/11/12/ballot-sc-12- Sonnenuntergang-von-Unterstrichen-in-DNS-Namen /
Dies bedeutet, dass Sie in Domänen mit einem ssl / tls-Zertifikat keine Unterstriche mehr verwenden dürfen.
(*) Das Zertifizierungsstellen-Browserforum (CA / Browser-Forum) ist eine freiwillige Zusammenkunft führender Zertifikatsaussteller (wie in Abschnitt 2.1 (a) (1) und (2) unten definiert) und Anbietern von Internetbrowsersoftware und anderen Anwendungen, die Zertifikate verwenden (Zertifikatsverbraucher, wie in Abschnitt 2.1 (a) (3) unten definiert).
Einzelne TLDs können nach eigenem Ermessen ihre eigenen Regeln und Einschränkungen für Domain-Namen festlegen , z. B. um lokale Sprachen aufzunehmen.
Laut CIRA sind beispielsweise Kanadas .ca
Domainnamen zulässig:
Buchstaben
a
durchz
und die folgenden Zeichen mit Akzent :é ë ê è â à æ ô œ ù û ü ç î ï ÿ
. Beachten Sie, dass bei Domänennamen nicht zwischen Groß- und Kleinschreibung unterschieden wird. Dies bedeutet, dass nicht zwischen Groß- und Kleinbuchstaben (A
=a
) unterschieden wird.Die Zahlen
0123456789
undDas Bindestrichzeichen ("
-
) (obwohl es nicht zum Starten oder Beenden eines Domainnamens verwendet werden kann).
Die maximale Länge beträgt 63 Zeichen, außer dass jedes Zeichen mit Akzent diese Begrenzung um 4 Zeichen verringert .
( Quelle )
Dies ermöglicht im Übrigen etwa 4 Quadragintillion Domainnamen-Möglichkeiten (ohne Sub-Domains) für Dot-Ca-Domains.
Hier meine 2 Cent aus der Java-Welt:
Von einer Spark Scala-Konsole mit Java 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
Es ist definitiv eine schlechte Idee ^^
Gerade ein lokales Projekt (mit Vagabund) erstellt und es funktionierte perfekt, wenn über die IP-Adresse zugegriffen wurde. Dann habe ich some_name.test zur Hosts-Datei hinzugefügt und versucht, auf diese Weise darauf zuzugreifen, aber ich habe die ganze Zeit "schlechte Anfrage - 400" erhalten. Verschwendete Stunden, bis ich herausfand, dass nur das Ändern des Domainnamens in some-name.test das Problem löst. Zumindest lokal unter Mac OS funktioniert es also nicht.
Nein, Sie können keinen Unterstrich in der Subdomain verwenden, sondern einen Bindestrich (Bindestrich). dh my-subdomain.agahost.com ist akzeptabel und my_subdomain.agahost.com wäre nicht akzeptabel.
Nicht, wenn Sie möchten, dass es im Internet aufgelöst wird.
Sie können nicht haben: http://my_subdomain.example.com ist ungültig.
Sie können haben: http://my-subdomain.example.com mit einem Bindestrich.