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.
Cubbit ist das weltweit erste Unternehmen, das Cloud-Objektspeicher anbietet. Es wurde 2016 gegründet und bedient…
Unbefugte können Schadcode einschleusen und ausführen. Auslöser ist eine fehlerhafte Implementierung einer Android-Funktion.
iPhones und iPads belasten das Ergebnis. Außerdem schwächelt Apple im gesamten asiatischen Raum inklusive China…
Die Anzeigen richten sich an IT-Teams und Administratoren. Ziel ist der Zugriff auf IT-Systeme.
Betroffen sind Windows 10 und Windows 11. Laut Microsoft treten unter Umständen VPN-Verbindungsfehler auf. Eine…
Server-CPUs und Server-GPUs legen deutlich zu. Das Gaming-Segment schwächelt indes.