Es ist offensichtlich, dass ein autoritativer Server für eine TLD wie f.nic.de keine Anfragen zu jeder Domain beantwortet. Da es über zwölf Millionen .de-Domains gibt, haben die sechs TLD-Server genug zu tun, ihren Clients die autoritativen DNS-Server für jede .de-Domain mitzuteilen.
Client-Computer benötigen jedoch einen DNS-Server, der alle Anfragen beantwortet. Dies können nur DNS-Server, die so konfiguriert sind, dass sie alle Fragen eines Rechners beantworten. Dies machen sie „rekursiv“, indem sie bei den Root-Servern beginnen und sich durch die Nameserver-Hierarchie hangeln, bis sie die richtige Antwort von einem autoritativen Server der angefragten Zone erhalten. Diese leiten sie an den Client weiter.
Solche rekursiven Server sind bei den Providern installiert und werden normalerweise dem Client-PC oder NAT-Router automatisch mitgeteilt. Typischerweise erlauben die rekursiven Server keine Nutzung durch jedermann. Die Providerserver lösen in der Regel nur Anfragen aus dem eigenen Netz auf. Ist man beispielsweise über M-Net im Netz, beantwortet ein DNS-Server von Kabel Deutschland keine Anfragen, siehe Bild 5. Aus dem eigenen Netz funktioniert die Auflösung ohne Probleme, siehe Bild 6.
Rekursive Server und Autoritative Server schließen sich nicht grundsätzlich aus. Ein gemischter Betrieb ist durchaus üblich. Viele Firmen-DNS-Server fungieren als autoritative Server für die firmeneigenen Domains und erlauben gleichzeitig allen Intranet-Rechnern die rekursive Auflösung aller anderen Domains.
Diesen Mischbetrieb machen sich die Zensurprovider zu Nutze. Es ist bei jedem DNS-Server möglich, beliebige Zonen als autoritativ zu kennzeichnen, obwohl die TLD-Server nicht auf diesen Server verweisen. Beim Microsoft-DNS-Server kann man das bequem über das GUI erledigen, siehe Bild 7. Unter Unix-Betriebssystemen muss für den Standard-Nameserver BIND eine Konfigurationsdatei wie in Bild 8 gezeigt erstellt werden.
Die Beispielkonfiguration lenkt alle Anfragen an example.com und www.example.com auf den Stopp-Schild-Webserver um. Außerdem werden alle Mails an die Domain example.com direkt an das Bundeskriminalamt geschickt. Obwohl die TLD-Server für die Domain .com weiterhin auf die richtigen DNS-Server a.iana-servers.net und b.iana-servers.net zeigen, werden alle Nutzer der Server ns1.zensurprovider.de und ns2.zensurprovider.de mit Falschinformationen versorgt, da sich der Server für autoritativ erklärt. Einen Cross-Check gegen die zuständigen TLD-Server macht kein DNS-Client. Das würde zusätzlichen Netzwerktraffic verursachen und Zeit kosten.
Die Beispiele aus den Bildern 7 und 8 zeigen zudem, dass der Name example.com in den Konfigurationen nicht vorkommt. Es ist also möglich, für jede Domain, die zensiert werden soll, exakt die gleiche Datei zu verwenden. Sie muss nicht einmal mehrfach auf dem primären DNS-Server vorgehalten werden. Soll neben example.com auch example.net gesperrt werden, reicht es aus dieselbe Datei in die BIND-Konfigurationsdatei einzubinden. Am besten bindet man dazu eine Include-Datei ein, die die zensierten Domains enthält. Das könnte dann etwa so aussehen, wie in Bild 9 gezeigt. Bild 10 zeigt, dass mit derselben Datei die Domains example.com und example.net zensiert werden können.
Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…
Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…
Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…
Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.
Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…
Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.