Können (Domainnamen-) Subdomains einen Unterstrich "_" enthalten?


212

Können Subdomains (Domainnamen) Unterstriche enthalten _?


12
Ich habe Ihre Frage wörtlich genommen: dass Sie wirklich DOMAIN NAMES gemeint haben. Wenn Sie stattdessen HOST NAMES gemeint haben, bearbeiten Sie Ihre Frage, da die Antwort anders sein wird.
Bortzmeyer

Antworten:


362

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.comoder _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.


73
+1 für den Unterschied zwischen "Domainnamen" und "Hostnamen"
Alnitak

3
Die Frage (sofern sie nicht bearbeitet wurde) bezieht sich auf Subdomains, dh. Hostnamen. Sie liegen nicht falsch in Bezug auf Ihre tatsächlichen Aussagen, außer dass Sie darauf hinweisen, dass die Antworten falsch sind, je nachdem, wie die Frage derzeit formuliert ist.
Redreinard

4
Ich bin verwirrt, 1034 sagt: "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." Welcher Teil davon erlaubt einen Unterstrich?
Cladekennilol

2
Der Wortlaut ist verwirrend. URLs dürfen keine Unterstriche haben. Eine URL ist immer ein vollqualifizierter Domänenname, kein Hostname. Ein FQDN kann einen leeren Hostnamen haben, in diesem Fall FQDN = Domäne. _jabber._tcp.gmail.comist 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.
Kapsel

1
Ich kann das Zitat in 2.1 von rfc1123 nicht sehen, in dem erwähnt wird, dass Bindestriche zulässig sind. Ich kann im rfc952 sehen, dass ein Name <let-or-digit-or-hyphen> sein kann. Ist es das, worauf Sie sich bezogen haben?
AJP

93

Ein Hinweis zur Terminologie zur Unterstützung von Bortzmeyers Antwort

Über Definitionen sollte man sich klar sein. Wie hier verwendet:

  • Der Domänenname ist die Kennung einer Ressource in einer DNS-Datenbank
  • label ist der Teil eines Domainnamens zwischen Punkten
  • Hostname ist ein spezieller Typ von Domainnamen, der Internet-Hosts identifiziert

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

Ein Hinweis zur Codierung

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:

  • RFC 5890 "IDNA: Definitionen und Dokumenten-Framework"
  • RFC 5891 "IDNA: Protokoll"
  • RFC 5892 "Die Unicode-Codepunkte und IDNA"
  • RFC 5893 "Skripte von rechts nach links für IDNA"
  • RFC 5894 "IDNA: Hintergrund, Erklärung und Begründung"
  • RFC 5895 "Zuordnen von Zeichen für IDNA 2008"

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.


Nebenbei bemerkt: "Systeme wie DomainKeys und Servicedatensätze verwenden den Unterstrich, um sicherzustellen, dass ihr Sonderzeichen nicht mit Hostnamen verwechselt wird. Beispielsweise gibt _http._sctp.www.example.com einen Servicezeiger für ein SCTP an fähiger Webserver-Host (www) in der Domain example.com. " ( Link )
x-yuri

Ignorieren Sie die RACE-Codierungsteile. IDN hat bereits die Konvertierung des internaitonisierten Zeichens in ASCII mithilfe des Präfixes 'xn--' festgelegt.
Mootmoot

2
@ Nelda.techspiress Es ist einige Zeit her, aber laut RFC 1034: Domain - Namen - Konzepte und Einrichtungen , was ein „Sub - Domain“ einer Domäne genannt wird , 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 .
David Tonhofer

2
Im täglichen Gebrauch kann es vorkommen, dass die Zeichenfolge 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.bazund bar.bazkönnen Hostnamen sein oder nicht .
David Tonhofer

1
Auf Seite 8 von RFC 1034 lesen wir: Eine Domäne wird durch einen Domänennamen identifiziert und besteht aus dem Teil des Domänennamenbereichs, der sich unter oder unter dem Domänennamen befindet, der die Domäne angibt. Eine Domain ist eine Subdomain einer anderen Domain, wenn sie in dieser Domain enthalten ist. Diese Beziehung kann getestet werden, indem festgestellt wird, ob der Name der Subdomain mit dem Namen der enthaltenen Domain endet. Beispielsweise ist ABCD eine Subdomäne von BCD, CD, D und "".
David Tonhofer

47

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



3
Wir hatten das gerade in einem Projekt - und ich war verrückt nach den seltsamen IE-Problemen dort. Bis wir den Unterstrich in der Subdomain entdeckten. ; o)
Kai Mattern

3
Immer noch ein Problem in IE10. Weiß MS davon?
Piotr Kula

15
Relevanter: Interessiert sich MS dafür?
Ajax


11

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.

  • RFC2782 gibt vor, dass Dienstdatensatz-Subdomänen mit Unterstrichen versehen werden.
  • RFC6698 gibt vor, dass Portnummern mit Unterstrichen in TLSA-Zertifikatdatensätzen vorangestellt werden.

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 Σ_.comwürde codiert, xn--_-zmb.comwas 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.


1
Schließlich. Ich kann nicht glauben, dass dies der einzige Beitrag auf der ganzen Seite ist, der überhaupt über Punycode spricht.
Pacerier

6

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?


3
Nein, es ist nicht veraltet. RFC1034 ist eine Spezifikation für Hostnamen , ein Sonderfall von Domänennamen , die generische Kennungen von Ressourcen in der DNS-Datenbank sind. Beispielsweise wird der "Host" -Teil von URIs eher entspannt definiert ( tools.ietf.org/html/rfc3986#section-3.2.2 ), aber der RFC warnt: "Ein durch einen registrierten Namen identifizierter Host ist normalerweise eine Folge von Zeichen bestimmt für die Suche in einer lokal definierten Host- oder Dienstnamenregistrierung ... ein registrierter Name, der für die Suche im DNS bestimmt ist, verwendet die in Abschnitt 3.5 von [RFC1034] und Abschnitt 2.1 von [RFC1123] definierte Syntax. "
David Tonhofer

3

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


1

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 .caDomainnamen zulässig:

  • Buchstaben adurch zund 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 0123456789und

  • Das 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.


0

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


0

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.


0

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.


-2

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.


Es ist nach dem 15. Januar 2019 - Ihr Gegenbeispiel funktioniert nicht.
Joe Inwap

@ JoeInwap Kannst du mich bitte auf eine Quelle für deinen Kommentar verweisen?
Ankshah

Ich ging zu cabforum.org/2018/11/12/… und der Tatsache, dass o_o.lgms.nl ein Zertifikat vorlegt, das für diesen Hostnamen nicht gültig ist. Der Name wird jedoch aufgelöst.
Joe Inwap
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.