Ugrás a tartalomra

Technika · 2026. november 7. · 6 perc olvasási idő

PTR-rekord: hogyan lesz egy gépnévből cég

A PTR-bejegyzés egy IP-címhez gépnevet rendel. Így olvassa le, ismeri fel a gyűjtőneveket, és jut el a domaintől a céghez.

Egy gépnév, például mail.beispiel-firma.example, a fordított keresésen át egy cégnevet tartalmazó kartonlappá válik
Ábra: Whovisit · Ábra megtekintése nagyban

Aki tudni akarja, kié egy IP-cím, az többnyire a hálózati jegyzékbe néz, az európai címeknél tehát a RIPE adatbázisába. Van egy második út, amelyet gyakran figyelmen kívül hagynak: a fordított keresés a DNS-ben. Ilyenkor nem azt kérdezi: „Kié a hálózat?”, hanem azt: „Hogy hívják a gépet ezen a cím mögött?”. Ha a névben egy cég domainje áll, használható támpontja van.

Ez a cikk elmagyarázza, mi az a PTR-rekord (PTR-bejegyzés), ki állítja be, miről ismeri fel a használható bejegyzéseket az értéktelenektől, és hol ütközik határokba a módszer. A hálózati jegyzékes utat a Reverse IP Lookup egyszerűen elmagyarázva írja le.

Mi az a PTR-bejegyzés

A DNS két irányt ismer. Normál esetben egy nevet kérdez, és címet kap (A- vagy AAAA-bejegyzés). A PTR-bejegyzés (angolul pointer record) az ellenirány: egy címhez nevet ad.

Technikailag a címet ehhez megfordítják, és egy különleges végződéssel látják el. A 203.0.113.25-ből a 25.113.0.203.in-addr.arpa lekérdezés lesz. IPv6-nál a végződés ip6.arpa. A címet közben karakterről karakterre megfordítják. A válasz egy gépnév, például mail.beispiel-firma.example.

Fontos: a PTR-bejegyzés önkéntes. Vannak bejegyzés nélküli címek. A bejegyzésnek nem kell egyeznie az előre irányuló bejegyzéssel. Támpont, nem bizonyíték.

Ki állítja be

A PTR-bejegyzést az gondozza, aki a címblokkot kezeli:

  • A szolgáltatók az ügyfélcsatlakozásokhoz többnyire automatikusan generált gyűjtőneveket állítanak be.
  • A saját címblokkal rendelkező cégek maguk gondozzák a bejegyzéseket, és gyakran a saját domainjüket írják be.
  • Az üzleti csatlakozások egyes szolgáltatóknál kívánságra az ügyfél domainjét tartalmazó bejegyzést kapnak. Ez főleg levelezőszervereknél történik, mert sok fogadó elutasítja a megfelelő gépnév nélküli címekről érkező leveleket.

Ebből következik: a saját domainnel rendelkező bejegyzés jele annak, hogy valaki tudatosan foglalkozott a címmel. Az automatikusan generált név csak a szolgáltatóról mond valamit.

Minták felismerése: gyűjtőnév vagy saját domain

A gépnév két részből áll: az elülső részből (mail, pool-1-2-3-4) és a regisztrálható domainből a végén (beispiel-firma.example). A domain elárulja az üzemeltetőt, az elülső rész pedig azt, hogy a nevet kézzel vagy automatikusan adták.

A gyűjtőnév tipikus jelei, amely nem árul el céget:

  • a név a cím részeit tartalmazza: 203-0-113-25.provider.example vagy 25.113.0.203.provider.example
  • olyan szavak, mint dyn, dynamic, dial, pool, dsl, adsl, cable, cust, customer, mobile, lte, static, nat, cgn, client
  • olyan domain, amely felismerhetően egy szolgáltatóhoz, tárhelyszolgáltatóhoz vagy számítóközponthoz tartozik

A használható név tipikus jelei:

  • beszédes elülső rész, például mail, gw, fw, vpn, proxy vagy smtp
  • nincsenek címrészek a névben
  • olyan domain, amely felismerhetően egy vállalkozáshoz tartozik, nem a szolgáltatóhoz
Gépnév (kitalált példa)Értékelés
dyn-203-0-113-25.dsl.provider.exampleA szolgáltató gyűjtőneve, nem mond semmit az előfizető kilétéről
pool-25.cust.provider.exampleGyűjtőnév, ügyfélcsatlakozás
mail.beispiel-firma.exampleSaját domain, jelölt a cégekhez rendeléshez
vpn.beispiel-firma.exampleSaját domain, jelölt a cégekhez rendeléshez
ec2-203-0-113-25.compute.cloud.exampleSzámítóközpont, a tárhelyszolgáltató egyik ügyfele, nem maga a tárhelyszolgáltató

A táblázat egy csapdát is mutat: ha a domain a szolgáltatótól vagy a tárhelyszolgáltatótól származik, a név nem visz előre, még ha szépnek látszik is. Egy használható kiértékeléshez ezért ismert szolgáltatói és tárhelyszolgáltatói domainek listája kell, amelyeket kizárnak.

A domaintől a céghez

A domain még nem cég. A cég felé a szokásos út a domain mögötti weboldalon át vezet:

  1. A regisztrálható domain meghatározása. A mail.beispiel-firma.example-ből beispiel-firma.example lesz. A co.uk jellegű végződéseknél három rész számít.
  2. Az impresszum megnyitása. Németországban, Ausztriában és Svájcban az üzletszerű weboldalaknak meg kell nevezniük az üzemeltetőt, többnyire jogi formával (GmbH, AG, KG és így tovább).
  3. A jogi név kiolvasása, és annak ellenőrzése, hogy jogi személyhez tartozik-e, nem magánszemélyhez.

A szövegkeresésnek vannak határai. Az impresszumok nem egységes felépítésűek, egyes oldalak a tartalmat csak szkripttel töltik be utólag. Néha az impresszumban egy ügynökség vagy egy anyakoncern áll. Az automatikus hozzárendelés ezért javaslat marad, amelyet kétség esetén ember ellenőriz. Alternatívaként a cégadatbázisok egy domainhez megadják a cégnevet, ez sem teljes soha.

Kipróbálás saját kezűleg

Nincs szüksége különleges szoftverre. macOS-en és Linuxon van dig, Windowson nslookup. A példák a 203.0.113.25 címet használják, amely a dokumentációs tartományból való (RFC 5737). Senkié, ezért nincs valódi bejegyzése. Saját kísérleteihez írja be a saját csatlakozásának vagy szerverének címét.

# Fordított keresés, csak a válasz
dig -x 203.0.113.25 +short

# Részletesen, a megfordított lekérdezéssel
dig -x 203.0.113.25

# Windows, macOS és Linux
nslookup 203.0.113.25

Így olvassa a kimenetet:

  • A +short esetén a válaszban csak a gépnév áll, például mail.beispiel-firma.example. (a végén a pont szándékos). Ha semmi nem jön vissza, nincs bejegyzés.
  • +short nélkül a dig a QUESTION szakaszban a megfordított lekérdezést mutatja in-addr.arpa végződéssel. Az ANSWER szakaszban áll a PTR és a névvel ellátott sor.
  • Az NXDOMAIN állapot azt jelenti: ehhez a címhez nincs bejegyzés. A SERVFAIL vagy egy időtúllépés azt jelenti: az illetékes névszerver nem válaszol.
  • Az nslookup a name = sort mutatja a gépnévvel, vagy azt az üzenetet, hogy a nevet nem találta.

Ellenpróbaként kérdezze le a nevet előre (dig beispiel-firma.example +short). Ha a név ismét ugyanarra a címre mutat, a bejegyzés hihetőbb. Ha az oda- és a visszairány nem egyezik, óvatosság indokolt.

A módszer határai

  • Elavult bejegyzések. A címek gazdát cserélnek, a bejegyzések megmaradnak. Egy név, amely évekkel ezelőtt helyes volt, ma már egy másik céghez vagy semmilyenhez sem vezethet.
  • Szolgáltatók levelezőszerverei. Sok cég egy tárhelyszolgáltatón vagy marketingeszközön át küld leveleket. A gépnév ilyenkor a szolgáltatóra mutat, nem a cégre.
  • Közösen használt címek. Egy cégnevű cím mögött egy irodaház vagy coworking tér több bérlője is ülhet. A név ilyenkor a bérbeadóé.
  • Időkorlátok. A DNS-lekérdezések elakadhatnak. Aki a háttérben értékeli ki őket, annak rövid idő után fel kell adnia, és nem szabad kierőszakolnia a választ.
  • Home office és mobilhálózat. Itt szinte mindig csak gyűjtőnevek vannak. Hogy ez miért van így, azt a Home office, VPN és mobilhálózat: kiket nem lát írja le.

Hogy a PTR, a hálózati jegyzék és a kiértékelés együtt hogyan ad látogatóazonosítást, azt a Hogyan működik a cégfelismerés? A technika 6 lépésben áttekintés mutatja. Ott az is áll, miért ingadoznak erősen a találatok a célcsoporttól függően.

Példa a gyakorlatból: a Whovisit a fordított keresést csak szolgáltatói hálózatokból származó címeknél használja, eldobja a gyűjtőneveket és az ismert szolgáltatói domaineket, legfeljebb két másodpercet vár a válaszra, és csak a domain és a cég közötti hozzárendelést jegyzi meg, soha az IP-címet. Hogy milyen látogatóosztályok vannak és mit jelentenek, azt a súgó írja le Látogatóosztályok: cég, internetszolgáltató, számítóközpont címen.

Röviden összefoglalva

A PTR-bejegyzés önkéntes támpont egy cím mögötti gépnévre. Akkor lesz értékes, ha a név saját cégdomaint tartalmaz, és nem mutat szolgáltatói mintákat. A domaintől a céghez általában az impresszum vezet. Minden hozzárendelés hibaaránnyal terhelt feltevés marad. Nincs bejegyzés jobb, mint egy hibás.

Tovább olvasom