In der Vergangenheit wurden mehrfach Sicherheitslücken und Angriffe gemeldet, die durch unvorsichtiges Benutzen von aus dem DNS gelieferten Hostnamen möglich wurden. Das ist insbesondere gefährlich, wenn solche Informationen als Parameter in Shell-Aufrufen benutzt oder sonstwie von einer Shell interpretiert werden, beispielsweise in CGI-Programmen, wie sie bei der Verarbeitung von WWW-Forms benutzt werden.
Der Schutz vor solchen Angriffen obliegt selbstverständlich zuerst dem Programmautor, allerdings ist heute nicht (mehr) davon auszugehen, daß CGI-Programme (es waren auch andere, durchaus prominente Programme betroffen) nur von in Sicherheitsfragen bewanderten Personen geschrieben werden. Da zudem eine solche Falle an dieser Stelle sehr unerwartet auftritt (das liegt irgendwie in der Natur der Sache), ist ein möglicher Lösungsansatz, die Resolverfunktionen gethostbyname() und gethostbyaddr() so zu modifizieren, daß sie nur noch "ungefährliche" Namen als Ausgabe haben.
Dabei stellt sich die Frage, aus welchen Zeichen solche "ungefährliche" Namen bestehen können. Die Antwort ist leicht gefunden, wenn man zwei Aspekte berücksichtigt:Die aktuellen Versionen des BIND-Nameservers, als dessen Bestandteil auch die Resolverbibliothek ausgeliefert wird, die die eben genannten Routinen enthält, erzwingen die Standardkonformität der Hostnamen in bestimmten Kontexten.
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names".
The syntax of a legal Internet host name was specified in RFC-952. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit.Aus den Zitaten ergibt sich, daß
<hostname> = <label> | <hostname>.<label> <label> = <let-dig> | <let-dig><let-dig> | <let-dig><ldh-string><let-dig> <ldh-string> = <let-dig-hyp> | <ldh-string><let-dig-hyp> <let-dig-hyp> = <let-dig> | '-' <let-dig> = <letter> | <digit> <digit> = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' <letter> = "jeder Buchstabe A - Z, ohne Berücksichtigung der Groß- und Kleinschreibung"
Die Syntaxregeln für Domainnamen im Gegensatz zu Hostnamen können auch weniger restriktiv ausgelegt werden.
Die Längenbeschränkung auf 24 Zeichen im obigen Zitat ist ebenfalls nicht mehr gültig. STD3 schreibt vor, daß Software mit Hostnamen von bis zu 63 Zeichen Länge umgehen können muß und tatsächlich Namen bis zur Länge von 255 Zeichen unterstützen sollte. In diesem Zusammenhang sei erwähnt, daß der längste unter DE beobachtete reale Hostname aus 69 Zeichen bestand, wobei solche Grenzen offenbar die Phantasie anregen.
Zu den Zeichen, die in einem Hostnamen nicht vorkommen dürfen, zählen also neben allen anderen oben nicht aufgeführten z.B. die deutschen Umlaute, die Symbole '/' und '&' sowie insbesondere der vielfach verwendete '_'.
Die beschriebenen Änderungen wurden zunächst nur für die IN-Klasse implementiert, sodaß Hesiod-Anwender weiterhin in der HS-Klasse Namen benutzen können, die etwa '/' enthalten. Außerdem werden in diesem Zusammenhang in den meisten Fällen TXTRecords eingesetzt, deren Eigentümer selbst in der IN-Klasse beliebige Domainnamen sein dürfen.
Die aktuelle BIND-Versionen 4.9.8 und 8.2.3 überprüfen Namen an zwei verschiedenen Stellen. Die Resolver-Bibliothek unterdrückt bei der Auflösung von IP-Adressen in Hostnamen solche mit unerlaubten Zeichen. Damit werden Anwendungsprogramme, die diese neue Bibliothek verwenden, bereits vor Angriffen geschützt.
Zusätzlich kann der Nameserver so konfiguriert werden, daß bereits beim Laden der Zonenfiles Namen mit unerlaubten Zeichen als Owner bestimmter Resource Records zurückgewiesen oder zumindest angemahnt werden. Da sich sowohl die Syntax als auch die Anwendungsmöglichkeiten zwischen der Version 4 und der Version 8 unterscheiden, werden zunächst die Regeln für Version 4 sowie anschließend die Unterschiede in Version 8 erläutert.
Mit der BIND-Direktive check-names wird global eingestellt, wie auf unzulässige Hostnamen in Zonen reagiert werden soll, abhängig davon, ob es sich um Zonen handelt, für die der Server als primary oder secondary konfiguriert ist. fail und warn bestimmen dabei, ob die Zone gar nicht erst geladen wird oder ob lediglich Warnungsmeldungen erzeugt werden.
check-names primary fail
check-names secondary warn
So wird zwar ein sinnvoller Beitrag zur "DNS-Hygiene" geleistet aber kein voll wirksamer Schutz für sämtliche Anwendungsprogramme geboten. Dieser Schutz ist denn auch umso schwieriger zu erzielen, als viele Applikationen bereits mit einer alten, zu toleranten Resolver-Bibliothek statisch gebunden sind und nicht neu gelinkt werden können. Selbst beim Einsatz dynamischer Biblitheken (shared libraries) ist es vielfach nicht möglich oder wünschenswert, die Systembibliotheken durch die aus der BIND-Distribution zu ersetzen und auch Systemhersteller liefern bisweilen schneller die neue Servervariante aus als die zugehörige Resolver-Bibliothek. Um dennoch auf die Sicherheitsproblematik eingehen zu können, bietet BIND auch für den Resolver in named die Unterdrückung von oder Warnung vor nicht konformen Namen an:
check-names response fail
Neben den Aktionen fail und warn steht in allen drei Kontexten auch die Alternative ignore offen, womit nicht konforme Namen unbeanstandet und kommentarlos verarbeitet werden. Voreingestellt sind z.Z. die Werte
check-names primary fail
check-names secondary warn
check-names response ignore
die den eigenen Server zum good network citizen machen,
der eigenen Klientel aber noch keinen Schutz bieten.
Generell hat sich hier die Benennung der Serverfunktion geändert, sodaß statt primary der Begriff master und anstelle von secondary der Ausdruck slave benutzt wird. Die Grundeinstellung gleicht der der Version 4 (bitte die ';' beachten):
check-names master fail;
check-names slave warn;
check-names response ignore;
Falls check-names response fail eingestellt wird, antwortet Version
8 mit REFUSED statt gar keine Antwort zu schicken.
Zusätzlich kann die globale Voreinstellung für jede Zone separat im zone-Statement abgeändert werden.
In BIND 9 sind die check-names-Direktiven aus BIND 8 bislang nicht übernommen worden, weil man der Meinung war und ist, daß diese Art der Überprüfung in den Resolver und nicht in den Nameserver gehört. Prinzipiell ist diese Ansicht sicher nicht verkehrt, die Erfahrung zeigt aber, dass es deutlich schwieriger (und zum Teil unmöglich) ist, alle Resolver zu aktualisieren. Momentan kann erwartet werden, daß diese Funktionalität ab Version 9.2 wieder aktiviert werden kann.
Die Überlegungen zur Syntax der Hostnamen (und einiges mehr) waren eine Zeit lang in einem Internet Draft von Mark Andrews mit dem Titel Clarification on the use of Hostnames, Mail Boxes and Mail Domains in the DNS nachzulesen, zuletzt in der Version draft-andrews-dns-hostnames-03.txt, vom 11. November 1996. Die sechsmonatige Lebenszeit dieses Dokumentes ist jedoch abgelaufen und mittlerweile ist durch das Erscheinen des RFC 2181, Clarifications to the DNS Specification, der in sich Abschnitt 11 des Themas annimmt, tatsächlich einiges an Klarheit geschaffen worden.
Die Tatsache, daß der folgende Absatz aus RFC 2181 dem Verhalten des aktuellen BIND nicht entspricht (oder umgekehrt), sollte nicht weiter verwirren:
Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default.
Zur Zeit werden in der IETF mehrere Ansätze für die Nutzung weiterer Zeichensätze in Domainnamen diskutiert, die jedoch noch nicht produktionsreif sind. Zwar gibt es bereits eine Schar von Testbeds oder vergleichbaren Pilotprojekten, die zum Teil gegen Gebühr die Registrierung von Domainnamen mit Umlauten oder etwa in chinesischen Schriftzeichen anbieten, jedoch sind diese Verfahren untereinander und insbesondere mit der installierten Basis nicht notwendig kompatibel, so daß es zu erheblichen Interoperabilitätsproblemen kommen kann.
Aus Gründen der Kompatibilität sind darum Verfahren im Gespräch, die eine logische Zwischenebene einziehen zwischen die Domainnamen, wie eine Applikation, also etwa ein Web-Browser, sie sieht und das Format, das über den Draht geschickt wird. Damit wären die weiter oben gemachten Überlegungen keineswegs obsolet.