Omgekeerde IP-opzoeking (PTR-records)

Omgekeerde DNS beantwoordt de tegenovergestelde vraag van een gewone opzoeking: welke naam heeft de eigenaar aan dit adres gekoppeld? De pagina bouwt de omgekeerde naam zelf — a.b.c.d.in-addr.arpa voor IPv4, de nibble-vorm onder ip6.arpa voor IPv6 — vraagt het PTR-record op, en toont welke resolver heeft geantwoord, welke responscode er was, de CNAME-keten als die er was, en de TTL. De tweede modus loopt de adressen naast het adres dat u heeft ingevoerd langs, binnen hetzelfde blok, één adres tegelijk, omdat hostingproviders hun machines meestal met een zichtbaar patroon benoemen. Alles hier is openbare, passieve informatie: geen scanning, geen woordenboekaanvallen, geen WHOIS.
Gereed. Er is nog geen query verstuurd.
Voer een adres in en start de omgekeerde opzoeking.
De richting van de vraag. Een gewone opzoeking gaat van een naam naar een adres via A- en AAAA-records, en de eigenaar van de site beheert die. Een omgekeerde opzoeking gaat van een adres naar een naam via PTR-records, en de eigenaar van het netwerk beheert die, niet de eigenaar van de website. Dat ene verschil verklaart het grootste deel van wat hier vreemd lijkt: een naam onder het patroon van een hoster, zoals srv12.hoster.example, zegt wie de machine beheert, en zegt niets over welke website erop staat.

Geen PTR-antwoord is een normaal resultaat. Niemand is verplicht een omgekeerde naam aan te maken, en de meeste adresblokken doen dat nooit. Een leeg antwoord betekent dat de eigenaar het leeg heeft gelaten of dat het antwoord is verwijderd, niet dat het adres ongebruikt is of iets verkeerd doet. Het loopt ook door de gewone cache, dus een onlangs toegevoegde naam kan even duren voordat die overal zichtbaar is.

Waarom de buren interessant zijn. Adresblokken worden in reeksen uitgegeven, en het kleinste bereik dat een klant meestal heeft, is een /24 — 256 adressen. Hosters benoemen die adressen volgens een schema, dus als u een handvol namen rond één adres leest, toont dat vaak het patroon en de provider achter het hele blok. Deze pagina vraagt eerst naar de adressen die het dichtst bij het uwe liggen, binnen dezelfde /24, en gaat nooit op zoek naar namen die geen adressen zijn.

Wat het niet betekent. Een omgekeerde naam is geen websitenaam: de naam in het antwoord kan bij een router, een mailrelay of een loadbalancer horen en niet bij een site. Eén adres kan honderden ongerelateerde sites bedienen, en één grote site kan over tientallen adressen verspreid zijn, dus een gedeelde naam is een aanwijzing over hosting, nooit bewijs dat twee dingen verband houden. Behandel de buren als een naampatroon, niet als een lijst met eigenaren.

Kosten, en waarom de buurlijst traag is. Elk adres in de lijst is een apart verzoek aan dezelfde resolver-limiet die de andere pagina's gebruiken, en de lijst loopt één adres tegelijk met een pauze tussen de items om binnen wat openbare resolvers accepteren te blijven. Een volledige lijst duurt dus even, en u kunt annuleren: de resterende adressen vallen weg zonder dat er iets blijft draaien.

Wat deze pagina niet doet. Geen woordenboekaanvallen, geen blokscans, geen poortverkenning en geen opzoeking van registratiegegevens. Als een adres geen omgekeerde naam heeft en u wilt weten van wie het netwerk is, dan is de eerlijke volgende stap de IP-opzoeking, die de netwerk- en locatievelden leest die openbare diensten wel publiceren, en de subnetcalculator, die de blokgrenzen van dat adres toont zonder iets ergens heen te sturen.

Openbare bronnen die u zelf kunt lezen. Het gezaghebbende register van wie een adresbereik bezit, wordt bijgehouden door de regionale registers: de IANA IPv4-adresruimte en de IANA IPv6-unicasttoewijzingen tonen welk register elk blok heeft ontvangen, en elk register publiceert vervolgens zijn eigen delegatiegegevens. Deze pagina vraagt die bestanden bewust niet op: het zijn een ander, zwaarder soort verzoek, en ze met de hand lezen via de links hierboven is de eerlijke manier om “van wie is dit netwerk” te beantwoorden.