Technika · 2026. november 7. · 5 perc olvasási idő
Reverse DNS ellenőrzése: a PTR-bejegyzés lekérdezése és beállítása
Így ellenőrzi egy IP-cím reverse DNS bejegyzését dig, host és nslookup segítségével, hogyan állíttatja be a szolgáltatónál, és mit várnak el a levelezőszerverek.
Aki levelezőszervert üzemeltet, előbb-utóbb találkozik a „no reverse DNS” vagy „PTR missing” hibaüzenettel. Ez a szervercím reverse DNS bejegyzését jelenti. Ez a cikk megmutatja, hogyan kérdezheti le, mit kell teljesítenie a levelezőszervereknél, és hogyan állíttathatja be. Hogy egy gépnévből hogyan következtethet egy cégre, azt viszont a PTR-rekord: hogyan lesz egy gépnévből cég írja le.
Mi a reverse DNS
A normál DNS egy nevet fordít címmé. A reverse DNS az ellenkezőjét teszi: egy IP-címhez nevet ad. Erre való a PTR-bejegyzés. A lekérdezés egy különleges domainen keresztül fut. IPv4-nél ez az in-addr.arpa, IPv6-nál az ip6.arpa. A címet közben megfordítják. A 192.0.2.10-ből 10.2.0.192.in-addr.arpa lesz. IPv6-nál az egyes hexadecimális jegyeket fordítják meg, ahogy az RFC 3596 leírja.
A PTR-bejegyzés lekérdezése
A parancsok a példában a 193.0.6.139 címet kérdezik le, a RIPE NCC címét. Cserélje le a sajátjára.
| Eszköz | Parancs | Jó tudni |
|---|---|---|
| dig (macOS, Linux) | dig -x 193.0.6.139 +short | A címet maga fordítja meg. +short nélkül az állapotot is látja. |
| host (macOS, Linux) | host 193.0.6.139 | A legrövidebb kimenet: „domain name pointer …” |
| nslookup (minden rendszer) | nslookup 193.0.6.139 | Windowson is megvan. |
Ha nem jön válasz, nincs bejegyzés (NXDOMAIN állapot), vagy az illetékes névszerver nem válaszol (SERVFAIL, időtúllépés). IPv6-ra ugyanez az írásmód működik, például dig -x 2001:db8::25 +short egy dokumentációs tartományból való címmel. Akinek nincs konzolja, a DNS-eszközoldalak online lekérdezését használja. A frissen módosított bejegyzések a gyorsítótárazás (TTL) miatt gyakran csak egy idő után érnek el mindenhová.
Miért kell a levelezőszervereknek
A fogadó levelezőszerverek szívesen ellenőrzik, rendben be van-e állítva a feladó. Ennek az ellenőrzésnek egy része a reverse DNS. Az alapgondolatot a szaknyelv forward-confirmed reverse DNS-nek nevezi:
- A feladó címéhez lekérdezik a PTR-bejegyzést. Eredmény: egy gépnév.
- Ehhez a gépnévhez lekérdezik az A-bejegyzést (IPv6-nál AAAA).
- Ha a cím megegyezik az eredetivel, a lánc bezárult.
A Google a feladóktól kifejezetten érvényes előre és visszafelé irányuló bejegyzéseket kér. A feladókra vonatkozó irányelvekben az áll, hogy a feladó címének egyeznie kell a PTR-bejegyzésben megnevezett gépnév címével. Az RFC 1912 is a 2.1. szakaszban azt javasolja, hogy a PTR- és az A-bejegyzések illeszkedjenek, és a PTR-bejegyzés ne mutasson CNAME-re. Hogy egy másik fogadó szigorúan ellenőriz-e, az a saját dokumentációjában áll. Számítson rá, hogy egy hiányzó vagy nem illeszkedő bejegyzés elutasított vagy a spam mappába került levelekhez vezet.
Beállíttatás
A PTR-bejegyzést nem a saját domainkezelésében állítja be. A címblokkhoz tartozó zónában van. Ezt az kezeli, akihez a blokk ki van osztva. Ez általában a szolgáltatója vagy a tárhelyszolgáltatója.
- Válassza ki a gépnevet, amellyel a levelezőszerverének fel kell lépnie, például
mail.beispiel-firma.example. - Hozza létre a saját DNS-zónájában az A-bejegyzést: a
mail.beispiel-firma.examplea192.0.2.10-re mutat. - A szolgáltató ügyfélportálján írja be a reverse DNS bejegyzést a
192.0.2.10-hez. Sok tárhelyszolgáltatónál ez egy mező az IP-címnél. Másképp elég egy megkeresés az ügyfélszolgálatnak a címmel és a kívánt névvel. - A
dig -x-szel, majd adig mail.beispiel-firma.example +short-tal ellenőrizze, hogy a két irány illeszkedik-e. - Győződjön meg róla, hogy a név a levelezőszerver köszöntéséhez (HELO/EHLO) is illik.
Ha saját címblokkja van, a nyilvántartás továbbítja a zónát az Ön névszervereinek. A /24-nél kisebb blokkoknál az RFC 2317 írja le az eljárást. Ilyenkor először a szolgáltatójánál kérdezzen rá.
Két buktató gyakori. Ha a szervernek több címe van, mindegyiknek saját bejegyzés kell. És dinamikus címekkel, amilyenek a magáncsatlakozásoknak vannak, általában nem kap szabadon választott nevet. Aki onnan küld levelet, jobban teszi, ha relay szolgáltatást használ.
Ha az ellenőrzés elbukik
| Megfigyelés | Lehetséges ok |
|---|---|
| Nincs bejegyzés | A szolgáltató nem állított be semmit, a bejegyzés hiányzik ehhez a címhez |
| A bejegyzés a szolgáltató gyűjtőnevére mutat | Saját nevet soha nem kértek |
| A név nem ugyanarra a címre oldódik fel | Az A-bejegyzés hiányzik, vagy régi címre mutat |
| Csak az IPv4 működik | IPv6-ra hiányzik a bejegyzés, a Google ezt jelzi a dokumentációjában |
| A változás nem látható | Gyorsítótár, várja meg, vagy kérdezze közvetlenül a szolgáltató névszerverét |
A reverse DNS nem helyettesíti a levelezés hitelesítését. Az SPF, a DKIM és a DMARC külön témák. De megfelelő PTR-bejegyzés nélkül egy levelezőszerver gyorsan a fogadók radarja alatt marad.
Mit nem bizonyít a reverse DNS
A bejegyzés önkéntes, és a hálózatüzemeltető gondozza. Nem mondja meg, ki használ egy címet. Ezért támpontként használható, nem bizonyítékként, ha tudni akarja, kié egy IP-cím. Ehhez a hálózati nyilvántartás a megbízhatóbb forrás. A két út együttműködését a Reverse IP Lookup egyszerűen elmagyarázva magyarázza.
Gyakori kérdések
Kell minden IP-címhez PTR-bejegyzés? Nem, önkéntes. A levelet küldő szervereknél azonban a gyakorlatban kötelező, mert a fogadók ellenőrzik.
Módosíthatom magam a PTR-bejegyzést? Csak ha Ön kezeli a cím reverse zónáját. A szolgáltatója vagy tárhelyszolgáltatója címei esetén ő állítja be a bejegyzést, többnyire az ügyfélportálon át vagy kérésre.
Mi a különbség a reverse DNS és a Whois között? A reverse DNS gépnevet ad, és a hálózatüzemeltető állítja be. A Whois vagy az RDAP a címtartomány tulajdonosát nevezi meg. Mindkettő más adatbázis, más céllal.
