@ Svens Antwort mit der Bearbeitung ist bereits richtig, aber nur um die Dinge direkt zu formulieren.
TL; DR Ja Unterstrich ist in einem CNAME
Datensatz auf beiden Seiten gültig. Lesen Sie unten, warum.
RFC 1034 und andere definieren Datensätze basierend auf "Domänennamen", die Bezeichnungen mit einem beliebigen Zeichen sind, einschließlich _
.
Aber einige Datensätze haben strengere Regeln für den Eigentümer als Namen und / oder die Ressourcendaten (RDATA). Dort wird nur ein Hostname akzeptiert, und tatsächlich gelten jetzt (sie wurden in der Vergangenheit gelockert, als ein Hostname nicht mit einer Ziffer beginnen konnte), dass Sie einen beliebigen ASCII-Buchstaben (ohne Berücksichtigung der Groß- und Kleinschreibung), beliebige ASCII-Ziffern und die Bindestriche verwenden können , plus einige zusätzliche Positionsregeln: kein Bindestrich am Anfang oder Ende und keine doppelten Bindestriche an Position 3 und 4 (wegen "Reservierung" für IDNs in der Form, xn--
die nur in Groß- und Kleinschreibung zulässig ist).
Beispielsweise ist der Eigentümername eines A
oder eines AAAA
Datensatzes ein Hostname und kein Domänenname. Es
test.example.com A 192.0.2.1
gilt also, warum all dies nicht der Fall ist:
_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1
Es ist einfach, Dinge mit dem named-checkzone
Programm zu testen (Teil der bind
Nameserver-Software, kann jedoch separat verwendet und installiert werden, und andere Nameserver verfügen möglicherweise über ähnliche Überprüfungswerkzeuge, und wahrscheinlich gibt es auch dafür Online-Schnittstellen). Fügen Sie einfach Datensätze in eine Datei ein und führen Sie sie aus es auf:
$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)
(Die Zahl vor dem IN
ist die TTL. Dies hängt nicht mit unserem Problem hier zusammen, sondern muss nur die Syntaxvalidierung eines Datensatzes bestehen.)
Bei anderen Datensätzen ist das Gegenteil der Fall: NS
Es gibt keine Einschränkungen für den Eigentümer, sondern Einschränkungen für das "Ziel", das die Daten sind. Die Daten können nur ein Hostname sein, kein Domänenname, da Sie auf autorisierende Nameserver verweisen müssen, die physische Hosts sind, die auf DNS-Abfragen antworten.
Nun zu CNAME
, hier sind die entsprechenden Zitate aus RFC 1034, in Abschnitt 3.6:
"Eigentümer: Dies ist der Domainname, unter dem die RR gefunden wird." Dies bedeutet standardmäßig einen beliebigen Namen, nicht nur einen Hostnamen (als Quelle des CNAME-Datensatzes).
"RDATA: Dies sind die typ- und manchmal klassenabhängigen Daten, die die Ressource beschreiben:"
"CNAME einen Domainnamen."
Sowohl der Eigentümer von a CNAME
(was sich links davon befindet) als auch die damit verbundenen Ressourcendaten, sein Ziel / Ziel (was sich rechts davon befindet) sind Domänennamen und nicht nur Hostnamen. Grundsätzlich ist jedes Zeichen, also einschließlich _
, auf beiden Seiten erlaubt.
Wieder einfach zu testen mit named-checkzone
:
$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.
Keine Fehler bezüglich der CNAME
(die anderen Fehler werden erwartet, da ich in meiner gefälschten Zone keine SOA
oder NS
Aufzeichnungen wie eine echte Zone platziert habe)