Omvendt IP-opslag (PTR-poster)

Omvendt DNS besvarer det modsatte spørgsmål af et almindeligt opslag: givet en adresse, hvilket navn pegede dens ejer tilbage på den? Siden bygger selv det omvendte navn — a.b.c.d.in-addr.arpa for IPv4, nibble-formen under ip6.arpa for IPv6 — spørger efter PTR-posten og viser, hvilken resolver der svarede, hvad svarkoden var, CNAME-kæden hvis der var en, og TTL'en. Den anden tilstand gennemgår adresserne ved siden af den, der blev indtastet, inden for samme blok, én adresse ad gangen, fordi hosting-udbydere har en tendens til at navngive deres maskiner i et synligt mønster. Alt her er offentlig, passiv information: ingen scanning, ingen ordbogsbrute-force, ingen WHOIS.
Adresse at slå op
Resultat
Klar. Ingen forespørgsel er sendt endnu.
Indtast en adresse, og kør derefter det omvendte opslag.
Hvad et omvendt opslag kan og ikke kan fortælle
Forespørgslens retning. Et almindeligt opslag går fra et navn til en adresse via A- og AAAA-poster, og webstedsejeren styrer det. Et omvendt opslag går fra en adresse til et navn via PTR-poster, og netværksejeren styrer det, ikke webstedsejeren. Den ene forskel forklarer det meste af det, der ser mærkeligt ud her: et navn under en hostings mønster, såsom srv12.hoster.example, siger, hvem der driver maskinen, men intet om, hvilket websted der ligger på den.

Intet PTR-svar er et normalt resultat. Ingen er forpligtet til at oprette et omvendt navn, og de fleste adresseblokke gør aldrig det. Et tomt svar betyder, at ejeren lod det stå tomt, eller at svaret blev fjernet — ikke at adressen er ubrugt eller gør noget forkert. Det går også gennem den normale cache, så et nyligt tilføjet navn kan tage et stykke tid om at dukke op alle steder.

Hvorfor naboerne er interessante. Adresseblokke uddeles i intervaller, og det mindste interval en kunde normalt har, er et /24 — 256 adresser. Hosting-udbydere navngiver disse adresser efter et skema, så læsning af en håndfuld navne omkring én adresse viser ofte mønstret og udbyderen bag hele blokken. Denne side spørger først om de adresser, der ligger nærmest den, inden for samme /24, og den leder aldrig efter navne, der ikke er adresser.

Hvad det ikke betyder. Et omvendt navn er ikke et websitenavn: navnet i svaret kan tilhøre en router, en mail-relæ eller en load balancer frem for et hvilket som helst websted. Én adresse kan betjene hundreder af ikke-relaterede websteder, og ét stort websted kan fordele sig over dusinvis af adresser, så et delt navn er et fingerpeg om hosting, aldrig bevis for, at to ting hænger sammen. Behandl naboerne som et navngivningsmønster, ikke som en liste over ejere.

Omkostning, og hvorfor naboListen er langsom. Hver adresse på listen er en separat forespørgsel mod den samme resolver-kvote, som de andre sider bruger, og listen kører én adresse ad gangen med en pause mellem punkterne for at holde sig inden for, hvad offentlige resolvere accepterer. En fuld liste tager derfor noget tid, og den kan annulleres: de resterende adresser droppes uden at efterlade noget kørende.

Hvad denne side ikke gør. Ingen ordbogsbrute-force, ingen områdescanning, ingen portprobing og ingen opslag i registreringsdata. Hvis en adresse ikke har et omvendt navn, og man vil vide, hvilket netværk den hører til, er det ærlige næste skridt siden IP-opslag, der læser de netværks- og lokationsfelter, som offentlige tjenester faktisk offentliggør, og Subnetregneren, der viser blokgrænserne for den adresse uden at sende noget nogen steder hen.

Offentlige kilder, man selv kan læse. Den autoritative registrering af, hvem der ejer et adresseinterval, føres af de regionale registre: filerne IANA IPv4 address space og IANA IPv6 unicast assignments viser, hvilket register der fik hver blok, og hvert register offentliggør derefter sine egne delegeringsposter. Denne side forespørger bevidst ikke disse filer: de er en anden, tungere slags forespørgsel, og den ærlige måde at besvare “hvis netværk er dette” på er at læse dem manuelt via linkene ovenfor.