Überprüfungsmethoden

Vier Prüfungen haben bei den kostenlosen Tools das größte Gewicht: Forward-confirmed reverse DNS, Crawler-Verifizierung, RDAP-Präfixabgleich und Blacklist-Abfragen. Für jede dieser Prüfungen gibt es eine Abkürzung, die im Testbetrieb korrekt erscheint, im Produktionsbetrieb jedoch falsche Ergebnisse liefert. Auf dieser Seite wird beschrieben, wie die Tools stattdessen vorgehen, und zwar so detailliert, dass sich die Fehler reproduzieren lassen.

Forward-confirmed reverse DNS

A PTR Record allein beweist noch nichts. Wer auch immer einen Adressblock kontrolliert, entscheidet, welchen Namen dieser trägt, und nichts hindert daran, dass dieser Name mail.yourbank.com. Die Prüfung, die Aussagewert hat, ist die Vorwärtsbestätigung: Lösen Sie den PTR-Namen zurück auf und prüfen Sie, ob die ursprüngliche Adresse unter den Ergebnissen ist.

Vergleichen Sie den gesamten Adresssatz, nicht nur den ersten Eintrag

Ein häufiger Fehler besteht darin, den Vergleich mit dem ersten zurückgegebenen A-Eintrag durchzuführen. Adressen hinter einem Round-Robin-Namen führen sofort zu einem Fehler:

8.8.8.8  ->  PTR dns.google
             ->  A     8.8.8.8, 8.8.4.4
             ->  AAAA  2001:4860:4860::8888, 2001:4860:4860::8844

8.8.4.4  ->  PTR dns.google
             ->  same four addresses

Ein Tool, das bei der ersten Antwort Halt macht, erstellt Reports 8.8.4.4 als unbestätigt, da das DNS zuerst 8.8.8.8 zuerst zurück. Etwa jede zweite Abfrage an einen Round-Robin-Namen führt auf diese Weise zu einem falschen Ergebnis. Sowohl der A- als auch der AAAA-Satz müssen aufgelöst und durchsucht werden.

Vergleichen Sie Adressen in binärer Form

Der zweite Fehler besteht darin, Adressen als Zeichenfolgen zu vergleichen. 2001:db8::1 und 2001:0db8:0000:0000:0000:0000:0000:0001 sind dieselbe Adresse und weisen keine gemeinsamen Zeichen auf; ::ffff:192.0.2.1 und 192.0.2.1 sind dieselbe Adresse in zwei Familien. Beide Vergleiche gehören in die gepackte Form, die inet_pton() zurückgibt, niemals auf die Textform.

Was ein Fehlschlag bedeutet

Probieren Sie es über Reverse DNS aus.

Überprüfung eines Crawlers

Ein User-Agent-Header ist Freitext, den jeder Client senden kann; aus diesem Grund veröffentlicht jeder große Betreiber eine Verifizierungsmethode. Zwei Jahrzehnte lang war diese Methode Forward-confirmed reverse DNS. Dies trifft mittlerweile auf die Hälfte der Crawler, die es wert sind, überprüft zu werden, nicht mehr zu.

Die Trennlinie verläuft zwischen klassischen Suchmaschinen und der Generation der KI-Crawler. Die neueren Betreiber dokumentieren JSON-Dateien mit Adressbereichen und beziehen PTR-Namen nicht in ihre Methode ein, sodass eine Adresse innerhalb des von OpenAI für GPTBot veröffentlichten Bereichs überhaupt keinen Reverse-Eintrag aufweist. Ein Verifizierer, der nur die DNS-Methode kennt, markiert jede dieser Adressen als unbestätigt, was dem Befund entspricht, den er auch bei einer Fälschung abgibt.

Drei Urteile werden daher voneinander unterschieden:

• Bestätigt. Der Name gehört zu einem bekannten Crawler, und die für diesen Betreiber geltende Methode stimmt überein.
• Nicht bestätigt. Es gibt keinen PTR Record, die Vorwärtsprüfung ist fehlgeschlagen oder der User-Agent gibt einen Crawler an, den die Beweislage nicht stützt. In diesem Fall sind Maßnahmen erforderlich.
• Nicht zuordenbar. Alles lässt sich einwandfrei auflösen, aber die Adresse gehört keinem Crawler, den dieses Tool kennt. Das normale Ergebnis für einen gewöhnlichen Besucher.

Probieren Sie es unter „Bot-Überprüfung“ aus.

Ermittlung der zuständigen Registry über RDAP

Eine Abuse-Meldung, die an den falschen Block gesendet wird, ist gleichbedeutend mit keiner Meldung. Eine einzelne Adresse befindet sich in der Regel innerhalb der Zuteilung eines Hosting-Anbieters, die wiederum innerhalb der Zuteilung eines Transit-Anbieters liegt, die zu einer regionalen Registry gehört. Nur der innerste Betreiber kann den Rechner aus dem Netzwerk entfernen.

Die Bootstrap-Datei, kein Redirector

Es gibt kein zentrales Verzeichnis des Adressraums. Die IANA veröffentlicht eine Bootstrap-Datei, die jedes zugewiesene Präfix der dafür zuständigen Registry zuordnet, und diese ist weitaus kleiner, als die meisten Schätzungen vermuten lassen: Gemessen am 20.09.2026 ipv4.json betrug die Größe 5.629 Byte und ipv6.json 1.476 Byte. Eine zwischengespeicherte Kopie pro Tag steht jedem Besucher zur Verfügung, sodass die Abfrage direkt mit der Registry kommuniziert, anstatt jede Anfrage über einen öffentlichen Redirector weiterzuleiten.

Längstes Präfix, nicht die erste Übereinstimmung

Präfixe überschneiden sich. Ein kleiner Bereich innerhalb einer alten, großen Zuteilung gehört häufig zu einer anderen Registry als sein übergeordneter Bereich, sodass das erste übereinstimmende Präfix regelmäßig das falsche ist. Die Übereinstimmung muss das längste Präfix sein.

Der Ansprechpartner mit der „Abuse“-Rolle

Eine RDAP-Antwort enthält mehrere Kontaktentitäten, wobei die erste in der Regel administrativer und nicht operativer Natur ist. Die vom Tool zurückgegebene Adresse stammt von der Entität, die die abuse Rolle innehat. Wenn ein Netzwerk keine veröffentlicht, wird dies im Ergebnis angegeben, anstatt auf einen nicht in Zusammenhang stehenden Kontakt zurückzugreifen: Die Registry und der Inhaber des Blocks sind dann die nächsten Anlaufstellen.

Probieren Sie dies bei „Abuse-Kontakt“ aus, und lesen Sie den Abschnitt „IP Delisting“ für die umgekehrte Richtung.

Abfragen zur Blacklist

Das Abfrageformat

Eine DNSBL wird abgefragt, indem die Adresse umgekehrt und die Zone angehängt wird. Bei IPv4 sind dies die Oktette in umgekehrter Reihenfolge; bei IPv6 legt RFC 5782 das Nibble-Format fest, wobei jede Hexadezimalziffer separat und in umgekehrter Reihenfolge angegeben wird:

192.0.2.1        ->  1.2.0.192.<zone>
2001:db8::1      ->  1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
                     0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.<zone>

Nicht jede Liste liefert Antworten für IPv6

Neun der zwölf kuratierten Listen veröffentlichen eine IPv6-Zone; drei tun dies nicht. Die Abfrage einer reinen IPv4-Zone nach einer IPv6-Adresse liefert „NXDOMAIN“ zurück, was von einem einwandfreien Ergebnis nicht zu unterscheiden ist. Diese drei Listen werden daher für IPv6 überhaupt nicht abgefragt und als nicht zutreffend gemeldet, sodass eine leere Antwort niemals als „bestanden“ ausgewiesen wird.

Welche Listen antworten, wird überprüft und nicht einfach angenommen: Jede Zone in der Sammlung antwortet auf den RFC 5782- Testeintrag des Resolvers dieses Servers. Listen, die strukturell nicht von einem gemeinsam genutzten Resolver abgefragt werden können, werden ausgeschlossen, darunter Spamhaus ZEN, das einem öffentlichen Resolver einen Sperrcode anstelle eines Ergebnisses übermittelt.

Auswertung des Rückgabecodes

Ein Treffer wird durch einen A-Eintrag in 127.0.0.0/8, und der genaue Wert enthält den Grund. Ein Bereich stellt überhaupt keine Auflistung dar: Codes in 127.255.255.0/24 sind reserviert für Abfragefehler, einen blockierten öffentlichen Resolver, eine überschrittene Rate Limit oder eine fehlerhafte Abfrage. Werden diese als Treffer interpretiert, wird aus einem Infrastrukturproblem eine falsche Anschuldigung.

Probieren Sie es beim DNSBL Blacklist Check aus. Unsere eigene Zone ist unter „DNSBL-/RBL Zone“ dokumentiert.

Sicheres Abrufen einer Seite

Die Header-Prüfung ist das einzige Tool, das eine vom Besucher angegebene URL abruft, was sie zu einer Anfälligkeitsfläche für Server-Side Request Forgery macht. Der Abruf ist dementsprechend eingeschränkt:

• Nur http und https, ausschließlich die Ports 80 und 443.
• Der Hostname wird aufgelöst, und jede zurückgegebene Adresse wird in beiden Adressfamilien anhand der Bereiche „privat“, „Loopback“, „Link-Local“, „CGNAT“ und „Multicast“ überprüft.
• Vier Notationen enthalten eine IPv4-Adresse innerhalb einer IPv6-Adresse, und alle vier werden vor der Bereichsprüfung und nicht erst danach „entpackt“: v4-mapped, v4-compatible, NAT64 und 6to4. Ein Filter, der lediglich die textuelle Form prüft, lässt diese durch, da 2002:7f00:1:: und 127.0.0.1 sich, obwohl sie denselben Host bezeichnen, überhaupt nicht ähnlich sehen.
• Weiterleitungen werden manuell verfolgt, höchstens dreimal, wobei die vollständige Prüfung bei jedem Hop wiederholt wird.
• Es gilt ein festes Timeout, und es werden nur die ersten paar Kilobyte des Hauptteils gelesen.
• Die Anfrage verwendet GET anstelle von HEAD, da eine Reihe von Servern auf HEAD mit einem anderen Header-Satz antwortet.

Probieren Sie es bei Security Headers aus. Wie die Ergebnisse in eine Zahl umgewandelt werden, wird unter „Tool-Bewertung“ beschrieben.

Zuletzt aktualisiert: 20. September 2026 · Betreut vom ReportedIP-Team