Seite 2: Belogen

Inhaltsverzeichnis

Belogen

Was unbedarften Surfern helfen mag, die eigentlich gemeinte Seite zu finden, verwirrt viele Anwendungen, die auf die NXDomain-Fehlermeldung angewiesen sind. So versucht Linux beim Zugriff auf die Windows-Freigabe //server/ordner zuerst, den Namen "server" per DNS aufzulösen. Wenn eine Such-Domain wie ct.heise.de eingestellt ist, lautet der abgefragte Name server.ct.heise.de. Den gibts zwar nicht, doch der manipulierende DNS-Server liefert trotzdem eine Adresse zurück. Und Linux versucht nun, die Freigabe /ordner auf dem Werbe-Server des Providers anzusprechen. Würde die korrekte Fehlermeldung den Linux-PC erreichen, würde er die Namensauflösung im lokalen Netz per Broadcast probieren und den richtigen Server problemlos finden. Ähnliche Probleme entstehen überall, wo verschiedene Methoden der Namensauflösung zur Verfügung stehen und DNS zuerst probiert wird.

Doch auch anderswo ist NXDomain wichtig. Manche Spam-Filter prüfen, ob es den absendenden Server überhaupt gibt. Dieses Kriterium ist bei manipulierten DNS-Antworten unwirksam.

Bei abgehender Mail mit einem Tippfehler in der Domain verzögert sich die Fehlermeldung. Denn falls der Versender-Server keinen zuständigen Empfänger-Server (MX-Eintrag im DNS) findet, versucht er, den Domain-Namen als Server-Namen zu interpretieren. Bei korrekter NXDomain-Antwort würde er den Fehler sofort bemerken. Mit einer manipulierten DNS-Anwort versucht der Mail-Server jedoch mehrfach, die Mail beim Such-Server des Providers abzuliefern. Je nach Konfiguration gibt er erst nach Stunden oder Tagen auf. So lange erfährt der Absender eventuell nichts von seinem Versehen. Diese technischen Probleme sind seit Jahren bekannt. Schon 2003 diskutierte man das DNS-Wildcarding, bei dem ein zuständiger Server zu allen Namen in seiner Domain "On the fly"-Antworten erzeugt. Im selben Jahr stellte Verisign seinen "Sitefinder" auf Proteste hin ein. Der für die Top-Level-Domains .com und .net zuständige Registrar hatte DNS-Fragen nach nicht registrieren Domains auf seinen Server umgeleitet. Dort bot er die Domain zum Kauf an. Ähnliches tun manche Top-Level-Registrare weiterhin.

Beide DNS-Manipulationen werfen einige derselben Probleme auf wie die Verbiegung beim Provider. Und die Ablehnung der zuständigen Gremien ist seit Jahren einhellig: Das Internet Architecture Board (IAB) der Internet Engineering Task Force (IETF) stellt fest, dass DNS-Wildcarding die Architektur des Internet beeinträchtigt. Die Kritik der Internet Corporation for Assigned Names and Numbers (ICANN) führte zum Ende des Sitefinder-Experiments. 2008 warnte ein Report des "Security and Stability Advisory Committee" (SSAC) der ICANN vor den Problemen durch "Änderungen an DNS-Antworten". Und der aktuelle Bericht der Arbeitsgruppe zur "DNS-Gesundheit" definiert als zwei wichtige Kriterien, dass die Antwort beim Abfragenden ankommt, die der Domain-Inhaber auf den Weg schickt, und dass zwei Server zur selben Zeit dieselbe Antwort liefern. 2009 brachte der amerikanische Provider Comcast einen RFC-Entwurf in die DNS-Arbeitsgruppe der IETF ein, der beschreibt, wie man als Provider DNS-Umleitungen am besten umsetzen sollte. Die Diskussion auf der Mailingliste der Arbeitsgruppe wandte sich schnell vom "wie" zum "ob" und die recht klare Meinung war: "Lieber nicht".