2. Namen

Hostname (Hostname): Dies hat mehrere widersprüchliche Definitionen in unterschiedlichen DNS-Dokumenten und hat viel Verwirrung verursacht. Ein "Hostname" wurde ursprünglich (vor der Einführung von DNS) als der gesamte Name eines Rechners, normalerweise ein einzelner Name ohne interne Struktur, definiert (siehe Abschnitt 2 von [RFC952]). Mit der Einführung der DNS-Delegation wurden Hostnamen typischerweise mit der internen Struktur behandelt, die durch den DNS-Baum vorgegeben wurde, wie z.B. ein lokaler Teil eines Namens innerhalb einer Zone, der Stamm der Namenshierarchie und/oder ein vollständig qualifizierter Domänenname (fully qualified domain name). Im zeitgenössischen Sprachgebrauch bezieht sich "Hostname" auf nur den lokalen Teil eines DNS-Namens (manchmal auch als "Knotennamen" bezeichnet).

Einige Dokumente, wie [RFC1912], verwenden "hostname", um zu bedeuten "ein einzelnes Label, ohne jegliche Punkte". Das gleiche Dokument verwendet dann "host" und "domain name" als Synonyme, aber sie sind es nicht.

Für weiteren Hintergrund siehe [RFC1983], Anhang B. Für die Zwecke dieses Dokuments bezieht sich ein Hostname auf ein DNS-Label, das einen speziellen Knoten in einer Zone repräsentiert. Dies sollte ein bevorzugter Verwendungsfall im Gegensatz zu Hostnamen sein, die Knoten auf einem beliebigen Niveau der DNS-Hierarchie spezifizieren.

Domain Name (Domänenname): "Ein Domänenname wird durch ein Label (ein einzelnes Wort oder eine Menge von Labels bestehend aus einer Folge von Labels) identifiziert." (Zitiert aus [RFC1034], Abschnitt 2.3)

Label (Label): Ein geordnetes Element in einem Domänennamen. "Jedes Node [in der Namenshierarchie] hat ein Label, das null bis 63 Oktette lang ist. Brother Nodes können nicht das gleiche Label haben, obwohl das gleiche Label für Nodes verwendet werden kann, die nicht Brothers sind." (Zitiert aus [RFC1034], Abschnitt 2.3) Dies bedeutet, dass Nodes, die nicht Brothers sind, die gleichen Labels haben können.

FQDN (Fully Qualified Domain Name, Vollständig Qualifizierter Domänenname): Dies wird häufig verwendet, aber nicht im DNS-Kontext definiert. [RFC1594], Abschnitt 5.2, diskutiert es, aber nur im Kontext der Registrierung von Organisationen mit geografischen Domänen. [RFC1983] definiert es als "die gesamte Adresse eines Internet-Emailpostfachs oder eines Hosts" und bezieht sich auf [RFC1123], der es nicht definiert. [RFC2181] definiert ebenfalls nicht FQDN, aber es ist Gegenstand der Diskussion in Abschnitt 11 dieses Dokuments: "Ein Domänenname wird oft als absolut bezeichnet, wenn er im Draht-Format endet (mit einer Nulllängen als letztem Label), und relativ, wenn dieser Null-Label nicht vorhanden ist. Ein absoluter Domänenname wird oft 'Fully Qualified' genannt, häufig abgekürzt als FQDN, was eine klare Referenz auf den Abschluss darstellt, der vom Null-Label bereitgestellt wird."

Aus historischen Gründen bestand ein Teil der Verwirrung um das Konzept "Fully Qualified Domain Names" darin, dass einige DNS-Software Anfragen über den Domänennamensraum in verschiedene Dokumente oder Datensätze zersplittern würde. Domänennamen innerhalb jedes dieser Dokumente könnten "lokal" zu dem Dokument oder Datensatz sein, und ein Qualifikationsprozess würde durchgeführt werden, bevor versucht würde, die Namen aufzulösen. Moderne DNS-Server-Software verlangt nicht mehr, dass Domänennamen auf diese Weise qualifiziert werden, obwohl Stub-Resolver Software immer noch oft eine Suchliste für lokale Qualifikation enthalten. "FQDN" wird immer noch häufig verwendet, um sich auf den Domänennamen zu beziehen, auf den verwiesen wird, nachdem eine solche Qualifikation abgeschlossen ist.

TLD (Top-Level Domain, Top-Level-Domäne): "Der Name in der DNS-Hierarchie direkt unter dem Root ist eine TLD". (Zitiert aus [RFC4033], Abschnitt 9)

Internationalized Domain Name (Internationalisierter Domänenname): Die meisten Labels in DNS können nicht mit nicht-ASCII-Zeichen beschrieben werden. Internationalisierte Domänennamen (IDNs) sind Domänennamen, die eine Unicode-Darstellung haben und intern in DNS als ein ASCII-kompatibles Kodierungsformat dargestellt werden. Diese Kodierung wird auch als "Punycode" bezeichnet. Für IDNs existieren [RFC5890], [RFC5891], [RFC5892], [RFC5893] und [RFC5894]. Es gibt auch [RFC6055], [RFC6365] und [RFC4690].

Subdomain (Subdomäne): "Eine Domäne ist eine Subdomäne einer anderen Domäne, wenn sie in dieser anderen Domäne enthalten ist. Diese Beziehung kann indirekt getestet werden, indem man sieht, ob die Ursprungsdomäne unter der End-Domäne auf allen Pfaden liegt, die zum Root aufsteigen." (Zitiert aus [RFC1034], Abschnitt 2.3.1)

Alias: "Ein Alias ist ein Domänenname, der auf einem CN RR [canonical name resource record] abgebildet wird, dessen Wert ein kanonischer Name ist." (Zitiert aus [RFC2181], Abschnitt 10.1.1) CNAME-RRs ermöglichen den Betreibern von Domänennamen-Speicher (oft DNS-Server), Einträge zu pflegen, die DNS-Namen auf andere DNS-Namen verweisen. Obwohl CNAME RRs nicht speziell notwendig sind, um Anfragen zu beantworten, bieten sie eine Funktionalität der "Indirektion". Das heißt, ein Betreiber kann einen bestimmten Domänennamen (ein Label, das ein Netzwerkendgerät benennt) an unterschiedlichen Standorten belegen, oder seine Bedeutung oder Assoziationen häufig ändern, während andere Domänennamen, die auf diesen Namen verweisen (durch CNAME RRs), relativ statisch bleiben können. Es gibt oft technische oder geschäftliche Gründe, warum Indirektion wünschenswert ist; DNS bietet durch CNAME RRs eine Möglichkeit, Indirektion zu erreichen. [RFC1912] ist ein nützliches Dokument für Namensdienst-Betreiber, um zu verstehen, wann und wie das CNAME RR verwendet werden sollte. [RFC2181] hilft, das Verständnis zu klären, wie die CNAME RR funktioniert und warum seine Verwendung auf bestimmte Arten begrenzt ist.

Public Suffix (Öffentliches Suffix): "Ein öffentliches Suffix ist ein Label oder eine Folge von Labels, unter denen ein registrierungsfähiger Domänenname von einem bestimmten Registry nach bestimmten Bedingungen und Richtlinien registriert werden kann, die außerhalb des Geltungsbereichs dieses Dokuments liegen. Beispiele für öffentliche Suffixe sind .com, .co.uk und pvt.k12.wy.us. Der Begriff wurde ursprünglich im Kontext von HTTP State Management Cookies definiert, aber es wird auch anderswo verwendet, zum Beispiel im Grenzfall-Problem [DBOUND]." (Diese Definition ist eine Neuformulierung dessen, was in [RFC6265] gesagt wird.) In der Praxis ist das, was als öffentliches Suffix gilt, weitgehend von einer eher willkürlichen Liste abhängig, die öffentlich zugänglich gemacht wird und nicht Teil eines Standards ist.

Historisch gesehen hat man gemeint, die "öffentlichen Suffixe" wären alle TLDs. Das wäre immer noch eine gute Regel gewesen, wenn nicht historische TLDs eine flachere Hierarchie hatten, die "kaum unter dem Root" liegt. Beispielsweise wurden in den frühen Tagen des DNS .uk, .us und einige andere TLDs Domains zugewiesen, die "direkt unter" der TLD lagen, wie foo.uk, und es wurden auch Subdomänen unter anderen Labels erstellt, wie foo.co.uk, wodurch zwei "öffentliche Suffixe" dort erstellt wurden. Mehr oder weniger Struktur kann je nach TLD existieren, und viele TLDs verwenden kompliziertere Domänennamensstrukturen, zum Beispiel die gTLDs. (Einige beschreiben diese Praxis abwertend, weil sie keine Konsistenz hat.) Diese Strukturen führen zu komplexeren öffentlichen Suffixen, je nach TLD.

IDNA: "Internationalized Domain Names in Applications", das aktuelle IETF-Protokoll für die Handhabung von internationalisieren Domänennamen. Der Begriff "IDNA" sollte sich nur auf die Protokolle beziehen, die in [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894] und [RFC5895] definiert sind. Die gemeinsame Praxis, "IDNA" zu verwenden, um sich auf das inzwischen historische RFC 3490 zu beziehen und damit verbundene Dokumente, sollte aufhören, da keine Protokollspezifikation diese mehr auf dem Standardpfad hat. Einige Anwendungen haben die Aktualisierungen des IDNA-Protokolls nicht vorgenommen; diese sind mit dem aktuellen DNS nicht konform. (Ein früherer Begriff für IDNA war "IDNA2008", aber das war nie Teil irgendeiner RFC und sollte definitiv nicht mehr verwendet werden.)