In der Sperrverfügung werden den Access-Providern auch direkt die Methoden aufgezählt, mit denen nach Ansicht der Bezirksregierung für die Access-Provider verhältnismäßig, technisch möglich und zumutbar eine erfolgreiche Webblockade einzurichten sei.
Dabei bleiben die Sperrverfügungen ungenau, verwenden teilweise Begriffe aus allen Bereichen der Filtermethoden falsch oder fordern unangebrachte Methoden. So wird z. B. das Filtern auf Layer 3 Ebene gefordert, das nur auf IP-Adressen abzielt, obwohl Filtern auf Layer 4 Ebene, das neben IP-Adressen auch Ports einbezieht, weniger negative Nebeneffekte hätte. Nicht nur, dass die Provider zu Zensur-Erfüllungsgehilfen gemacht werden, werden sie auch noch mit Zensurverfügungen konfrontiert, deren Erfüllung ein gehöriges Maß an Interpretationsfähigkeit erfordert.

Zur Darstellung der Methoden wurde der Artikel Government mandated blocking of foreign Web content (2003) von Max Dornseif verwendet.

Der Zugangsprovider muss seinen rekursiven DNS-Server so konfigurieren, dass z. B. Anfragen nicht beantwortet oder nicht an den verantwortlichen DNS-Server weitergeleitet werden.

Wenn der User in seinem Browser die Website http://hp.kairaven.de/ besucht, wird vom Rechner des Users aus eine Anfrage an den rekursiven DNS-Server seines Providers gesendet, um "hp.kairaven.de" (den Host (Rechner) "hp" innerhalb der Domain "kairaven" innerhalb der Topleveldomain "de") in seine IP-Adresse zu übersetzen. Dazu fragt sich der rekursive DNS-Server, ausgehend vom Root Name-Server über die Name-Server, die für die Toplevel-Domain "de" und die Domain "kairaven" verantwortlich sind bis zum Name-Server durch, der hp.kairaven.de vollständig als IP-Adresse auflösen kann. Hat der rekursive DNS-Server des Providers die IP-Adresse der angefragten Website vollständig vorliegen, gibt er sie an den Rechner des Users weiter, der nun mittels seines Browsers Datenpakete direkt zur IP-Adresse von hp.kairaven.de versenden kann.

Deshalb spricht man wegen des sich im DNS-System verzweigenden Abfrageweges mit dem Ziel, für einen Host dessen vollständige IP-Adresse aufzulösen auch vom rekursiven DNS-Server oder Resolver ("Auflöser") des eigenen Providers - man könnte auch von "DNS-Proxys" sprechen.

In Abgrenzung dazu stehen die Authorative Name-Server, die für die Domains verantwortlich sind und von den rekursiven DNS-Servern befragt werden. Auf dem Authorative Name-Server sind Informationen gespeichert, die letzendlich zur vollständigen Identifizierung in Form der IP-Adresse eines entfernten Rechners (Host) führen. Dazu zählen u. a. die Zone-Dateien, die Daten zu einer Domain und aller Unterdomains (Subdomains) enthalten und die DNS A Ressource Records, die von einem Hostnamen zu seiner IP-Adresse verweisen.

Die folgenden Manipulationen sind eigentlich als legitime Konfigurationen für die eigene Zone den dafür verantwortlichen Authorative Name-Servern vorbehalten und müssen vom Provider in dessen Resolver "eingepflanzt" werden, was gegen die Funktionsweise als Resolver und die beabsichtigten Zwecke des DNS-Systems verstößt. Die Manipulationen können zu Störungen des Resolver Betriebs und des weltweiten DNS-Systems führen. Denn der Provider muß einerseits illegalerweise gefälschte Daten als Konfigurationen für Zonen anlegen, für die er gar nicht verantwortlich ist und deren Domains ihm nicht gehören und dabei sicherstellen, dass diese Falschdaten nicht in das weltweite DNS-System "herauslecken". Andererseits muß er dafür sorgen, alle anderen Daten zu Domains und Subdomains, die nicht zu blockieren sind, direkt und stets aktuell von den verantwortlichen DNS-Servern zu erhalten und mit den gefälschten Anteilen in den Zone-Dateien abzugleichen. Fehler bei dieser Art der auf Fälschung und Manipulation abzielenden Konfiguration können z. B. bewirken, dass auch der Zugang zum Mailserver oder der Zugang zu einer Vielzahl nicht zu sperrender Subdomains blockiert wird. Hinzu kommt, dass der User mit nicht verständlichen oder überhaupt nicht vorhandenen Fehlermeldungen konfrontiert wird, die für ihn keinen Rückschluss zulassen, warum er jetzt die Website XYZ nicht erreichen kann.

Im Resolver wird für eine Zone bestimmt, dass eine Anfrage abgelehnt wird. Der Resolver meldet dem Rechner des Users "Anfrage abgelehnt" und der User erhält eine Fehlermeldung mit der Angabe "Host not found".

Der Provider legt für eine fremde Zone eine leere Zonen-Datei an und konfiguriert den Resolver so, dass er als Authorative Name-Server für die Zone fungiert. Der Resolver gibt sich also dem User gegenüber fälschlicherweise als Authorative Name-Server aus. Bei einer Anfrage liefert der gefälschte Name-Server dem Rechner des Users einen Namensfehler zurück, der NXDOMAIN genannt wird, mit der Aussage, dass der angefragte Host nicht existiert.
Der User bekommt die Fehlermeldung "Host not found".

Im Resolver des Providers werden in einer Zone-Datei für eine bestimme Zone die Daten einer anderen Domain eingetragen, so dass der User nach einer Anfrage auf eine andere Domain, bzw. eine andere Website umgeleitet wird.

Im Resolver des Providers werden in die Zone-Datei für eine bestimmte Zone IP-Adressen als Rückantwort eingegeben, die aus dem privaten Adressbereich stammen, bzw. im Internet nicht weitergeleitet werden wie z. B. 127.0.0.1, der IP-Adresse für den eigenen Rechner des Users.

Für eine Zone wird im Resolver konfiguriert, dass kein DNS-Resolver eine Anfrage entgegennimmt, so dass kein DNS-Resolver eine Antwort zurückliefert.
Nach einer Wartezeit erhält der User die Fehlermeldung "Host not found".

Da Manipulationen am Resolver für die betroffenen Provider und die Bezirksregierung das aktuell probateste Mittel zur Durchführung der Sperrverfügungen darstellt, untersuchte Max Dornseif, welche Methoden zur Manipulation am meisten angewendet wurden, wie genau die Sperrverfügungen von den Providern umgesetzt wurden und welche negativen Nebeneffekte zu beobachten waren. In seinem Artikel kommt Dornseif zu folgenden Ergebnissen:

• einige zu blockierende Websites wurden von einem Teil der Provider gar nicht gesperrt
• alle Provider bewirkten durch die Manipulationen, dass nicht nur eine bestimmte Website oder -seite blockiert wurde, sondern auch eine oder mehrere E-Mail Adresse der zugehörigen Domain
• Maßnahmen, um die Privatsphäre der User, die auf zu sperrende Domains zugriffen, zu schützen wurden nicht getroffen. E-Mails, die für Accounts von Domains bestimmt waren, landeten direkt beim Provider, dritten Parteien (wie der Bezirksregierung) wurde erlaubt, die Umleitung auf deren Domain mitzuprotokollieren
• die Information des Users über den Grund der Zugriffsverweigerung wurde meistens unterlassen und dem User wurde stattdessen eine schwer verständliche Fehlermeldung präsentiert
• 30% aller Provider unternahmen schwere Fehlkonfigurationen an ihren Resolvern, wenn die Konfiguration nicht eh zu restriktiv war
• nicht in den Sperrverfügungen genannte Webhosts wurden durch die Manipulationen ebenfalls blockiert, während genannte Webhosts teilweise nicht blockiert wurden

Die bekannten Caching HTTP-Proxys, die häufig angefragte Websites und -seiten zwischenspeichern, um den Webzugriff für den User zu beschleunigen und vom User auf seinem Rechner oder dem Provider als zusätzlicher Bestandteil innerhalb seiner Netzwerkinfrastruktur eingesetzt wird, können durch Zwangsproxys und transparente Überwachungsproxys auf Providerebene ersetzt werden.

Bei Einsatz eines Zwangsproxys wird dem User vom Provider vorgeschrieben, einen bereitgestellten Proxy in die Konfiguration seines Webbrowser einzutragen oder dessen Adresse über die automatische Proxykonfiguration zu erhalten. Beim transparenten Überwachungsproxy, einem speziellen Typs des Zwangsproxys, ist die Konfiguration seitens des Users nicht notwendig, weil jedes Datenpaket, das Angaben zum HTTP Protokoll enthält, automatisch über die Router oder Gateways des Providers zu einem Proxy weitergeleitet werden.

Der Proxy kann vom Provider so konfiguriert werden, dass Anfragen zu URLs mit bestimmten Adressen erkannt und vom Proxy nicht weitergeleitet oder auf eine andere URL, bzw. Website umgeleitet werden, um den Zugriff des Users zu verhindern. Es ist auch möglich, den Proxy so zu konfigurieren, dass die Inhalte von Webseiten untersucht und entweder ausgeblendet oder durch andere Inhalte ersetzt werden.

Dragan Espenschied und Alvar Freude zeigten in ihrem Experiment insert_coin im Jahr 2000, in welchem Umfang auf diese Art Webinhalte manipuliert und kontrolliert werden können.

Der User bekommt entweder gar nicht mit, dass ihm verfälschte Inhalte vom Provider zurückgeliefert werden, er bekommt eine andere Webpage im Browser angezeigt, ohne zu wisen warum oder im "günstigsten" Fall wird er auf eine Webpage umgeleitet, auf der ihm erklärt wird, dass und warum ihm der Zugriff auf eine bestimmte Webressource verweigert wurde. Bei ungenau arbeitenden oder falsch konfigurierten Proxys kann es zudem vorkommen, dass auch Websites gesperrt werden, deren Blockade nicht beabsichtigt war. Mit dem Einsatz transparenter Proxys wird außerdem eine zusätzliche und vom User unbemerkte Überwachungsinstanz auf Providerebene installiert, an der über die Auswertung der Proylogs detailliert Interessen und Vorlieben für bestimmte Webinhalte eines Users ablesbar werden.

Der Router kann so konfiguriert werden, dass der komplette Datenverkehr zu einer bestimmten IP-Adresse nicht weitergeleitet wird.

wird auf die Vermittlungsschicht, bzw. Network Layer, der 3. Schicht des OSI-Modells im Router des Providers angewendet, deren Aufgabe es ist, Adressierungs- und Transportweginformationen in den IP Headern der Datenpakete unterzubringen, sprich die IP-Adresse von Sender, Empfänger und Zwischenstationen. Zielobjekt der Filter kann also die IP-Adresse des Senders oder Empfängers sein.

Durch eine Sperr-Regel auf die IP-Adresse des Zielwebhosts in seinem Router blockiert der Provider den gesamten aus seinem Netz herausgehenden und zur IP-Adresse des Zielwebhosts fließenden Datenverkehr, bzw. den von der IP-Adresse des Zielwebhosts kommenden und in sein Netz fließenden Datenverkehr.

Im ersten Fall erhält der User direkt die Fehlermeldungen "eine Verbindung kann nicht hergestellt werden" oder "Verbindungs-Zeitüberschreitung". Im zweiten Fall muß der User erst eine Zeitlang warten, bevor er die Fehlermeldung der Verbindungs-Zeitüberschreitung erhält. Da nur die IP-Adresse des zu blockierenden Zielrechners das Filterkriterium darstellt, wird nicht nur der Dienst für das WWW blockiert, sondern alle anderen Dienste wie E-Mail, Usenet, IRC usw., die der Zielrechner dem User anbietet. Allerdings sind die Ressourcen der Router zur Filterung und Blockierung von IP-Adressen begrenzt.

wird auf die Transportschicht, bzw. Transport Layer, der 4. Schicht des OSI-Modells im Router des Providers angewendet, deren Aufgabe es ist, den Auf- und Abbau, die überwachung der Verbindung und den störungsfreien Datenfluß über TCP und UDP zu steuern. Zielobjekt der Filter sind neben der IP-Adresse die Portnummern, die im Header der Pakete auf der Ebene der Transportschicht angegeben sind und die Art des Internetdienstes angeben, für den die Daten bestimmt sind, z. B. Port 21 für FTP, Port 80, 8000 für WWW, Port 110 für POP3 usw.

Durch Sperr-Regeln auf die Ports kann der Provider den Datenverkehr, der für einen speziellen Dienst auf dem Zielrechner bestimmt ist, blockieren. Wird z. B. Port 80 gesperrt, blockiert der Provider den Datenverkehr zu allen Websites, die über Port 80 des Zielrechners zugänglich sind, während andere Dienste wie z. B. FTP über Port 21, die der Zielrechner gleichzeitig anbietet, weiterhin für den User erreichbar sind.

Mit Sperre auf die Ports für das HTTP Protokoll, sprich WWW, werden wie gesagt "alle" Webseiten "aller" Websites blockiert und nicht nur eine einzelne Webseite einer einzelnen Website. Dazu ist als Einschätzung der Auswirkung einer IP-Adresse/Port basierten Sperre anzufügen, dass der Webserver eines Zielrechners unter einer IP-Adresse und einem Port viele Websites mit unterschiedlichen Rechnernamen beheimaten kann, die alle unterschiedslos von der Sperre betroffen wären. Hinzu kommt, dass ohne Information seitens des Zielrechnerbetreibers nicht feststellbar ist, wieviele unterschiedliche Websites unterhalten werden.

Neben diesen providerseitig vorzunehmenden Zensurmaßnahmen hatte die Bezirksregierung im Rahmen eines Arbeitskreises am 19.12.2001 den Start eines "Filter-Pilotversuches" verkündet, der bis zum April 2002 dauerte und von der Universität Dortmund unter Leitung des Direktors des Hochschulrechenzentrums der Universität Dortmund, Dipl. Phys. Günter Schwichtenberg, durchgeführt wurde.

Das Filterpilot-System, das dem Arbeitskreis Mitte Dezember 2001 präsentiert wurde, basiert auf einem Gesamtkonzept des Rechtsanwalts Michael Schneider für die BOCATEL GmbH & Co. KG, einer Gesellschaft für Beteilungsverwaltung und Beratung von Unternehmen aus dem Telekommunikationsbereich, Dr. Horst Joepen für die webwasher.com AG, deren Technologien aus den Filter-Produkten WebWasher und DynaBlocator in den Filterpiloten einfloss, sowie Andreas Schachtner für die IntraNet GmbH, jahrelanger Betreiber des deutschen Austauschpunktes der Internet-Provider DE-CIX und verantwortlich für das Usenet Content-Monitoring-System NewsWatch.

Aktuell unterhalten die BOCATEL GmbH und Michael Schneider die Website Jugendmedienschutz.Net, die sich der Darstellung der Rechtsgrundlagen zum Jugendschutz im Internet (Medien- und Jugendmedienschutz-Staatsvertrag) und der Informationen zum "Filterpilot" Projekt widmet.
Die BOCATEL GmbH hat es dazu geschafft, an der Kommission für Jugendmedienschutz (KJM) beteiligt zu werden, denn Michael Schneider wurde als einer der beiden Sachverständigen, die für den Bund einen Sitz in der KJM haben, in die KJM bestellt, wo er bis 2008 als Stellvertreter für Thomas Krüger, den Präsident der Bundeszentrale für politische Bildung, fungiert.

Zur Funktion von Jugendmedienschutz.Net wird weiter auf der Website ausgeführt:

Diese Website ist nicht zu verwechseln, mit der Institution jugendschutz.net, auch wenn die Verwechselung wohl beabsichtigt ist.

"jugendschutz.net" ist die von den "Jugendministerinnen und Jugendministern der Länder gemeinsam eingerichtete staatliche Stelle für die Beachtung des notwendigen Jugendschutzes in den neuen Informations- und Kommunikationsdiensten (Multimedia, Internet)", die "in erster Linie dabei für Mediendienste, also für Angebote, die sich an die Allgemeinheit richten, zuständig" ist.

"jugenschutz.net" ist also anders ausgedrückt der "Überwachungstrupp", der an vorderster Front Internetinhalte auf Verstöße überprüft und Ergebnisse der KJM zuleitet, die dann ggf. Sanktionen einleitet und verhängt.

Siehe auch § 18 jugendschutz.net, Jugendmedienschutz-Staatsvertrag.

Anders als die später in der Sperrverfügung genannten Maßnahmen, die nur durch den Zugangsprovider selbst durchzuführen sind, sieht das Filterpilot-System eine zentrale Steuerung mit bundesweiter Wirkung vor.

Ironischerweise wurden von den drei Firmen alle Maßnahmen, die später in der Sperrverfügung als technisch machbar und zumutbar charakterisiert wurden, in Puncto Skalierbarkeit (d. h. Funktionalität auch bei hohem oder wachsendem Datenverkehr) und Selektivität (d. h. Sicherheit, dass nur die Webserver, Websites und Webpages, die gefiltert werden sollen, auch getroffen werden und nicht andere, unbeteiligte Ziele) als "...nicht tragfähig" verworfen.

Was sich die drei Firmen stattdessen in ihrem Konzept für einen Internet-Filterdienst vorstellen, liest sich wie eine Neuauflage der alten WebBlock Pläne.

Die Anfragen des Users wurden über den Router seines Providers aus dessen Netz über den Eingangs-Router der zentralen Filter-Infrastruktur in deren Netz weitergeleitet, auf einem Linux Filter-Rechner, auf dem webwasher Filtersoftware lief, verarbeitet und wenn zulässig, über den Ausgangsrouter der zentralen Filter-Infrastruktur zu den Hosts mit den nicht zu sperrenden Websites weitergeleitet (im Versuchsaufbau mit einem Zwischen-Router zur besseren Anbindung an das Netz der Universität Dortmund).

Das Netz der Universität Dortmund übernahm die Rolle des Internets, sechs Webserver in diesem Netz die Rolle von Servern mit zu sperrenden Inhalten.

Nach Informationen des Chaos Computer Clubs (CCC) konnte Ende April 2002 kein technisch befriedigendes Ergebnis des Filterpilot-Projektes erzielt werden, weshalb die Sperrverfügungen die drei genannten Maßnahmen beinhalten. Wäre das Filterpilot-Projekt von Erfolg gekrönt gewesen, hätte Deutschland vermutlich jetzt eine bundesweite Zensur-Filter-Infrastruktur mit einer zentralen Zensurinstanz.

Ob das alte oder ein neues Filterpilot-Projekt weiter fortgeführt wird, ist unklar (s. o.). Hierzu bieten sich den Filterverfechtern vielleicht die zusätzlichen 13.3 Millionen Euro an, die im Rahmen der Fortführung des The Safer Internet Action Plan der Europäischen Union zur "Bekämfung von illegalen und schädlichen Inhalten im Internet" - auch zur Entwicklung neuer Filtertechnologien - für die Jahre 2003/2004 bereitgestellt werden.

Im Beschluss des Verwaltungsgerichts Düsseldorf vom 19.12.02 gegen den Widerspruch seitens eines der Access-Provider heißt es zum Filterpilot-Projekt:

Der Abschlussbericht zum Filterpilotprojekt kommt zu dem Resumee:

• Das beschriebene Verfahren ist prinzipiell geeignet, den Zugriff auf Webseiten hinreichend wirkungsvoll zu behindern. Seine Handhabung ist zufriedenstellend, wobei im Test noch keine komfortable Adminstrations-Schnittstelle vorlag.
• Die Router-Technik zum Umlenken eines Teils der Internet-Requests von den ISPs auf die Filtermaschine ist funktionsfähig und jederzeit einsetzbar. Der Einwand, dass auf den ISP-Routern eine zu große Belastung mit der Verwaltung von "Ausnahme"-Adressen entstehen könnte, konnte nicht ausgeräumt werden, dürfte aber mit fortschreitender Router-Technik unerheblich sein.
• Kritischen URLs wurden erfolgreich erkannt. Einige Restprobleme in der Webwasher-Software bzw. in deren Konfiguration sind so leicht behebbar, dass auf deren Nacharbeit verzichtet wurde.
• Als ebenfalls temporäres Problem blieb die Frage, ob der "vorschnelle" Aufbau einer Verbindung bei einer gesperrten Adresse verhindert werden kann bzw. wie dies zu verhindern ist. Dadurch könnte der gesperrte Server bemerken, dass eine Sperre errichtet wurde bzw. zu der Vermutung kommen, dass er zum Objekt eines DoD-Angriffs geworden ist.
• Das Problem der transparenten Weiterleitung von unkritischen Requests konnte erfolgreich gelöst werden.
• Für die Skalierbarkeit haben wir in der Testumgebung keine ernsthaften Grenzen feststellen können. Tatsächlich waren die größten Skalierbarkeitsgrenzen in der Leistungsfähigkeit der Klienten-Test-Rechner zu erkennen. Eventuell auftretenden Problemen könnte durch moderaten Mehrfacheinsatz der Filtersystems ­ z.B. für unterschiedliche Auftragsgeber aus dem Kreis der ISPs ­ begegnet werden.
• Die Umgehungsmöglichkeiten für einen solchen Dienst bestehen selbstverständlich weiterhin; eher sind hier neue Möglichkeiten entstanden: einerseits durch Einsatz neuer Protokolle (Peer-to-Peer), andererseits durch Ausweichen der Anbieter auf eigene Server, auf denen sie nun tatsächlich mit Verschlüsselungsverfahren arbeiten, was aber auch durch generelle Sperre des Rechners beantwortet werden könnte (weil in diesem Fall dort keine frei zu haltenden Informationen liegen).
• Bezüglich der bekannten Verfahren (1. Manipulation des Domain-Name Service ; 2. Sperrung von IP-Adressen in Routern; 3. Sperrung von URL's in Routern, 4. Verwendung von Zwangsproxies) bestehen unter den angenommenen Voraussetzungen moderaten Anzahl von umzuleitenden IP-Adressen (einige Hundert) und einer moderate Anzahl von zu sperrenden URL's (einige Tausend) deutliche Vorteile des neuen Verfahrens.

Im Jahr 2008 - 2009 startete die Neuauflage dieser Pläne mit dem Unterschied, dass der Angriff über Deutschland hinaus auf die europäische und internationale Ebene erweitert wurde. Siehe u. a. Streifzug durch die Welt der Zensur und Überwachung, Die Expertenbefragung zur Zensur- und Filter-Infrastruktur am "Tag danach" und EU-Mafia macht Ernst mit Kontrolle, Regulierung und Überwachung des Internets.