DNS-terminológiák, -összetevők és -fogalmak áttekintése

DNS (Domain Name System) az internetet hajtó egyik legfontosabb összetevő. A DNS működésének megfelelő megértése segíthet a weboldal-konfigurációs problémák diagnosztizálásában, és szélesítheti a megértését arról, hogy mi történik a színfalak mögött.

Ebben az útmutatóban a DNS néhány alapvető koncepciójáról fogunk beszélni, hogy szilárd alapot biztosítsunk Önnek a DNS-konfiguráció kezelése során. Ez az útmutató abban is segíteni fog, hogy beállítsa saját domain nevét vagy DNS-szerverét.

Kezdjük el!

Domain terminológiák

Először is tisztáznunk kell azokat a kifejezéseket, amelyeket használni fogunk. Néhányuk már ismerős lehet más kontextusokból. Azonban a domain nevekről és a DNS-ről beszélve sok olyan specifikus kifejezés létezik, amelyekről a számítástechnika más területein nem sokat esik szó.

• Domain Name System

A tartománynév-rendszer (röviden DNS) egy olyan működő hálózati rendszer, amely az ember által is könnyen olvasható domain neveket egyedi IP-címekre fordítja le.

• Domain név

A domain név az internetes erőforráshoz társított, ember által olvasható névre utal. Például a “cloudsigma.com” egy domain név. Egyesek vitathatják, hogy csak a “cloudsigma” rész a domain név, de általában az egészre utal.

A “cloudsigma.com” URL a CloudSigma tulajdonában lévő szerverekhez kapcsolódik. Amikor beírja az URL-t a webböngészőbe, az kommunikál a DNS-sel, hogy csatlakozzon a célszerver IP-címéhez.

• IP-cím

Az IP-cím a hálózathoz csatlakozó eszköz hálózati címeként szolgál. Minden IP-címnek egyedinek kell lennie a hálózaton belül. A weboldalak kontextusában a hálózat leggyakrabban a teljes internet.

Kétféle IP-cím létezik:

• • IPv4: Ez az IP-cím leggyakoribb formája. Négy számból álló csoportként írják le, amelyek mindegyike legfeljebb 3 számjegyet tartalmazhat. A csoportokat pont választja el egymástól. Az IPv4 tartománya a következő értéktől: 0.0.0.0 a következőig: 255.255.255.255.

  • IPv6: Ez egy modernebb szabvány, amelyet a következő probléma megoldására fejlesztettek ki: IPv4-címek elfogyása. Az IPv4 legfeljebb 232 egyedi címet támogat, míg az IPv6 legfeljebb 2128 címet. Az IPv6-címeket hexadecimális számjegyekkel írják le. Legfeljebb 32 számjegyet tartalmazhatnak, 8 szakaszra osztva (szakaszonként 4 számjegy). Az egyes szakaszokat kettőspont (:) választja el egymástól.

Legfelső szintű tartomány

A legfelső szintű tartomány (röviden TLD) a domain legáltalánosabb része. A jobb szélső részre utal (ponttal elválasztva). Néhány a gyakori legfelső szintű tartományok közül:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

A domain nevek tekintetében ezek a tartományok a hierarchia tetején állnak. Az ICANN (Internet Corporation for Assigned Names and Numbers) engedélyt adhat bizonyos feleknek a legfelső szintű tartományok feletti ellenőrzésre. Az engedély birtokában ezek a felek domain neveket oszthatnak ki a TLD alatt (általában egy domain-regisztrátoron keresztül).

• Hosztok

A domainen belül a tulajdonos egyedi hosztokat határozhat meg, amelyek a domainen keresztül elérhető különálló gépekre/szolgáltatásokra utalnak. Például elterjedt gyakorlat, hogy a webszervereket a csupasz domainen keresztül teszik elérhetővé ( example.com) és a “hoszt” definíció “www  ( www.example.com).

Lehetséges további hosztok használata is az általános domain alatt, például API-hozzáférés az “api” hoszton keresztül ( api.example.com), FTP-hozzáférés az “ftp” vagy “files” hoszton keresztül ( ftp.example.com vagy files.example.com).

Vegye figyelembe, hogy a domain nevek tetszőlegesek lehetnek, feltéve, hogy egyediek a domainen belül.

• Al-domain

Az aldomain a hosztokhoz kapcsolódó fogalom. A DNS hierarchikusan működik. Egy TLD alatt számos domain helyezkedhet el. Például: “ example.com”, “ cloudsigma.com”, stb. mind a “com” TLD alá tartoznak. Ebből a szempontból az aldomain egy olyan domainre való hivatkozás, amely a céldomain része. Így elmondhatjuk, hogy az “example.com” a “com” aldomainje. Általában az “example” részt SLD-nek (második szintű domainnek) nevezik.

Hasonlóképpen, egy domain vezérelheti az összes alatta található “aldomaint”. Általában erre utalnak az “aldomain” kifejezéssel. Például a(z) “ history.example.com” a következő domain aldomainje: “ example.com”.

A legfőbb különbség a gépnév (hostname) és az aldomain között az, hogy a gépnév egy számítógépet/erőforrást határoz meg, míg az aldomain kiterjeszti a szülődomaint. Amikor aldomainekről vagy gépnevekről beszélünk, ezt a domain legbaloldalibb részének megtekintésével ellenőrizhetjük, mivel az a legspecifikusabb. Így működik a DNS: a legspecifikusabbtól (legbaloldalibb rész) a legkevésbé specifikusig (a jobb szélső oldal).

• Teljesen minősített domain név

A teljesen minősített domain név (röviden FQDN) egy abszolút domain névre utal. A DNS-rendszerben a domainek megadhatók egymáshoz képest is. Ez némi kétértelműséghez vezethet. Az FQDN azonban egy abszolút név, amely a domainnév-rendszer abszolút gyökerére utal.

Ez azt jelenti, hogy az FQDN meghatározza az összes szülődomaint, beleértve a TLD-t is. Megfelelő példa lenne a(z) “ mail.google.com”. Bizonyos esetekben előfordulhat, hogy az FQDN nem ponttal végződik, de kötelezően tartalmaznia kell egy záró pontot (ezt az ICANN szabványok írják elő).

• Névszerver

A névszerver egy dedikált számítógép a domain nevek IP-címekre történő lefordítására. A névszerverek viselik a DNS-rendszer terhelésének nagy részét. Mivel a domain-fordítási kérelmek teljes száma túl magas ahhoz, hogy egyetlen szerver kezelje, a kéréseket gyakran más névszerverekre irányítják át a terhelés kiegyenlítése érdekében.

Egy névszerver lehet “hiteles” (authoritative), ami azt jelenti, hogy csak a felügyelete alá tartozó domainekre vonatkozó lekérdezésekre ad választ. Az ilyen szerverek továbbíthatják a kérést más névszervereknek, vagy kiszolgálhatják más névszerverek adatainak gyorsítótárazott másolatát.

• Zónafájl

A zónafájl egy szöveges fájl, amely a domain nevek és az IP-címek közötti megfeleltetéseket tartalmazza. Ez szolgál a DNS-rendszer adatbázisaként. Ez az a katalógus, amelyet a DNS használ annak a meghatározására, hogy melyik IP-címmel lépjen kapcsolatba, amikor egy adott domain névre vonatkozó felhasználói kérést teljesít.

Általában a névszerverek tárolják a zónafájlokat, és meghatározzák az egyetlen domain alatt elérhető erőforrásokat. Emellett információt is tartalmazhat arról, hogy hová kell fordulni ezekért az információkért.

• Rekordok

Egy zónafájl számos rekordból áll. Itt a rekord egy erőforrás és egy név közötti egyedi megfeleltetésként van meghatározva. A rekordok lehetnek egy IP-címhez rendelt domain név, egy adott domain alatt elérhető erőforrások, vagy hivatkozások az információk beszerzésének helyére.

A DNS működés közben

Eddig megismerkedtünk néhány, a DNS-sel kapcsolatos gyakori kifejezéssel. De hogyan is működik valójában a rendszer? Magas szinten a rendszer nagyon egyszerűnek tűnhet. Mindazonáltal a részletekbe való mélyebb betekintés feltárja valódi összetettségét. Összességében a DNS-rendszer kulcsfontosságú az internet széles körű elterjedéséhez.

• Gyökérszerverek

A DNS alapvetően hierarchikus rendszerben működik. A rendszer tetején a “gyökérszerverek” találhatók. Ezek a szerverek különböző szervezetek ellenőrzése alatt állnak. Ezen szerverek felügyeleti jogát az ICANN (Internet Corporation for Assigned Names and Numbers) delegálja.

Jelenleg körülbelül 13 gyökérszerver üzemel. A terhelés miatt azonban mindegyik szerver tükrözve van. Fontos megjegyezni, hogy az összes tükörszerver ugyanazon az IP-címen osztozik, mint a gyökérszerver. Amikor kérés érkezik a gyökérszerverhez, a kérést a szerver legközelebbi tükréhez irányítják át.

Mik a gyökérszerverek feladatai? Információt szolgáltatnak a legfelső szintű domainekről. Amikor egy alacsonyabb szintű névszerver nem tud feloldani egy kérést, az a domain gyökérszerveréhez lesz átirányítva.

A gyökérszerver azonban valójában nem ismeri a tartomány helyét. Csak átirányítja a kérést ahhoz a szerverhez, amely a kifejezetten kért legfelső szintű tartományt kezeli. Például, ha a kérés a következőre irányul: “ blog.cloudsigma.com”, a gyökérszerver rekordjai között ez nem fog szerepelni. Keresni fog a zónafájljaiban, de nem talál hozzá rekordot. Ehelyett felismeri a “com” TLD-t, és átirányítja a kérő entitást a “com” címeket kezelő névszerverhez.

• TLD szerverek

Az előző példánkat folytatva, a kérő entitás most elküldi a kérést az IP-címre (amelyet a gyökérszerver adott meg). A “ blog.cloudsigma.com” esetében a “com” névszerver keresni fog a zónafájljaiban lévő rekordok között.

Nem lesz a kérésnek megfelelő rekord. Találni fog viszont egy olyan rekordot, amely felsorolja a “ cloudsigma.com”.

• Tartományszintű névszerver

Most a kérő entitás rendelkezik annak a névszervernek az IP-címével, amely ténylegesen tárolja a “ blog.cloudsigma.com” információit. Most egy új kérést küld a szervernek, kérve a “www.cloudsigma.com” feloldását.

Ugyanúgy, mint korábban, a névszerver ellenőrzi a zónafájljait, és megkeresi a “ cloudsigma.com” tartományhoz kapcsolódót. Ebben a fájlban található egy bejegyzés a “www” gazdagéphez. Ez a rekord leírja, hol található a gazdagép. A végső választ ezután továbbítja a kérő entitásnak.

• Feloldó névszerver

A példában említettünk egy kérő entitást. Mi ez? A legtöbb esetben a kérő egy “feloldó névszerver” lesz. Ez egy olyan szerver, amely úgy van konfigurálva, hogy kérdéseket tegyen fel más szervereknek. Közvetítő szerverként működik a felhasználók számára. A sebesség növelése érdekében gyorsítótárazza az eredményeket.

A legtöbb felhasználó rendszerén általában be van állítva néhány feloldó névszerver. Általában a feloldó névszervereket az internetszolgáltató (ISP) vagy más szervezetek biztosítják. Például a Google nyilvános feloldó DNS-szervereket kínál a lekérdezésekhez. Ezt manuálisan is beállíthatja a rendszerében.

Amikor beír egy URL-t a webböngészőbe, az megkeresi az erőforrás helyét. Először a keresés helyben történik. Ez magában foglalja a “hosts” fájlt (és néhány más helyet). Ha nem található, akkor a kérés a feloldó névszerverhez kerül. A kérés beérkezése után a feloldó névszerver a gyorsítótárában keresi a választ. Ha nem találja, akkor végigmegy a korábban említett lépéseken.

A feloldó névszerverek leegyszerűsítik a lekérdezési folyamatot a végfelhasználó számára. Az ügyfélnek csak a feloldó névszerverektől kell megkérdeznie az erőforrás helyét. A névszerver utánajár, és visszaküldi a végső választ.

• Zónafájlok

Már beszéltünk a “zónafájlok” és “rekordok” fogalmáról. Nos, hogyan működnek?

A zónafájlok a névszerverek adatbázisaként működnek, tárolva az általuk ismert tartományok információit. Minden olyan tartomány, amelyet egy névszerver ismer, a zónafájljában lesz tárolva. A névszerverhez érkező kérések többségét azonban nem a zónafájl oldja fel. Ha a szerver konfigurációja a rekurzív lekérdezések kezelésére szolgál (például feloldó névszerverek), akkor visszaküldi a választ. Ellenkező esetben átirányítja a kérő felet egy másik helyre, ahol tovább kereshet.

Minél több zónafájlt tárol egy névszerver, annál hitelesebbek lesznek a válaszai. A zónafájlok egy DNS-“zónát” írnak le (a teljes DNS-névrendszer egy részhalmazát). Általában egy zónafájl csak egyetlen tartomány konfigurációs adatait tartalmazza. Számos rekordot tartalmazhat, amelyek meghatározzák a kérdéses tartomány erőforrásainak helyét.

A $ORIGIN paramétere megegyezik a zóna legmagasabb szintű hitelességével. Például a “ cloudsigma.com” zónafájljának az $ORIGIN paramétere “ cloudsigma.com”. A paraméter értéke a zónafájl elején vagy a DNS-szerver konfigurációjában is tárolható. A paraméter mindenképpen azt írja le, hogy a fájl melyik zónára nézve hiteles.

A $TTL paraméter beállítja az általa szolgáltatott eredmény “élettartam” (time to live) információját. Ez egy olyan időzítőként írható le, amelyet a gyorsítótárazó szerver használhat a gyorsítótárazott válaszok érvényességének nyomon követésére. Ha a TTL érték lejár, a válasz már nem érvényes, és elvetésre kerül.

• Rekordtípusok

A zónafájlok számos rekordból állnak. Különböző típusú rekordok léteznek. A következőkben áttekintjük a leggyakoribb (és kötelező) rekordtípusokat:

SOA-rekordok

A Start of Authority (röviden SOA) rekord minden zónafájlban kötelező. Ennek kell lennie az első valódi rekordnak a fájlban. Azonban az olyan bejegyzések, mint a(z) $ORIGIN vagy $TTL megengedettek, hogy előtte szerepeljenek.

A SOA-rekord az egyik összetettebb rekordtípus. A szerkezete valahogy így néz ki:

Bontsuk le részekre:

• • example.com: Ez a rész határozza meg a zóna gyökerét. Ebben a példában a zónafájl a következő domainhez tartozik: “ example.com”. Néha az érték helyettesíthető a következővel: @ (egy helyőrző, amely a következő értékét helyettesíti: $ORIGIN).

  • IN SOA: Az “IN” kifejezés az “internet”-et jelenti. Sok rekordban megtalálható. A “SOA” kifejezés azt jelzi, hogy ez egy SOA-rekord.

  • ns1.example.com: Ez az érték tartalmazza a(z) “ example.com” domain elsődleges névszerverét. A névszerverek lehetnek elsődlegesek vagy másodlagosak. Ha dinamikus DNS-sel lett konfigurálva, akkor kell lennie egy “elsődleges” szervernek. Ha nem lett dinamikus DNS konfigurálva, akkor ez lesz az egyik elsődleges névszerver.

  • admin.example.com: Ide kerül a zóna adminisztrátorának e-mail címe. Vegye figyelembe, hogy a @ le van cserélve a következőre: . itt. Ha az eredeti e-mail cím tartalmaz pontot, akkor az le lesz cserélve a következőre: \. Például a “ my.domain@example.com” a következővé válna: “ my\domain.example.com”.

  • 12083: Ez a zónafájl sorozatszáma. Minden alkalommal, amikor a zónafájlt szerkesztik, a számot frissíteni kell, hogy a fájl megfelelően terjedjen el. A másodlagos szerverek ezt a sorozatszámot használják annak nyomon követésére, hogy a saját zónafájljaik naprakészek-e.

  • 3h: Ez a zóna frissítési intervallumát jelenti. A másodlagos szerverek ennyi időt várnak, mielőtt ellenőriznék a zónafájl frissítéseit.

  • 30m: Ez az érték a zóna újrapróbálási intervallumát jelenti. Ha egy másodlagos szervernek nem sikerül kapcsolódnia az elsődleges szerverhez a frissítési időszak lejárta után, ennyi időt vár, mielőtt újra lekérdezné az elsődlegest.

  • 3w: Ez az érték a lejárati időszakot jelenti. Ha egy másodlagos szervernek ennyi ideig nem sikerül kapcsolódnia az elsődleges szerverhez, akkor nem fog többé “hiteles” (authoritative) válaszokat adni.

  • 1h: Ez az érték azt az időtartamot jelenti, ameddig a névszerver gyorsítótárazza a névhibát, ha az nem található a zónafájljában.

A- és AAAA-rekordok

Ezek a rekordok kapcsolatot teremtenek egy gazdagép (host) és egy IP-cím között. Itt az “A” rekord a gazdagép IPv4-es, az AAAA pedig az IPv6-os leképezését jelöli.

Ez az A- és AAAA-rekordok alapvető szerkezete:

A SOA-rekord példájában a névszervert így neveztük: “ ns1.exampel.com”. A névszerver a következő domain alá tartozik: “ example.com”. Így nézne ki az A-rekordja:

Vegye figyelembe, hogy nem kellett megadnunk a teljes nevet. Csupán a gépnévvel (az FQDN nélkül) a DNS-szerver ki tudja tölteni a többit a következő értékkel: $ORIGIN. Azonban továbbra is használhatjuk az FQDN-t:

Így határozhatja meg a webszervert “www”-ként:

A bázisdomainhez való hozzárendelést is meg kell adnunk. A bejegyzés így nézne ki:

Alternatív megoldásként használhatjuk a @ szimbólumot a bázisdomain jelölésére (a teljes neve helyett):

Jó gyakorlat egy helyettesítő karakteres (wildcard) bejegyzést is megadni, amely lehetővé teszi a domain alá tartozó, de explicit módon nem definiált nevek feloldását:

Ugyanez a struktúra vonatkozik az AAAA rekordokra is. Az egyetlen különbség az IPv6-címekben van.

CNAME rekordok

A CNAME rekordok a szerver kanonikus nevének (amelyet egy A vagy AAAA rekord határoz meg) álnveként (alias) szolgálnak. Tekintse meg a következő példát:

Itt a “server1”-et használtuk álnévként a “www” név meghatározásához. Vegye figyelembe, hogy az ilyen rövidítések teljesítménybeli költségekkel járnak, mivel a szervernek további lekérdezéseket kell futtatnia a végső válasz megszerzéséhez. Az álnév-rétegek számától függően ez könnyen jelentős teljesítménycsökkenést okozhat. Van azonban egy konkrét eset, amely előnyös a CNAME álnév használatával, például egy erőforrás biztosítása a jelenlegi zónán kívül.

MX rekordok

Az MX rekordok határozzák meg a domain levelezőszervereit. Segítenek abban, hogy az e-mailek helyesen érkezzenek meg a szerverre. Más rekordokkal ellentétben az MX rekordok nem rendelnek hozzá egy gépet valamihez, mivel a teljes zónára vonatkoznak. Ezért az MX rekordok valahogy így néznek ki:

Vegye figyelembe, hogy a bejegyzés elején nincs gépnév. Azt is észreveheti, hogy van egy további érték a sorban. Ez a prioritási szám, amely segít eldönteni, hogy melyik szerverre küldje a levelet (ha több levelezőszerver van megadva). Minél alacsonyabb a szám, annál magasabb a prioritás.

Az MX rekordnak egy A vagy AAAA rekord által meghatározott gépre kell mutatnia (nem CNAME-re). Ezt szem előtt tartva, ha két levelezőszerver van konfigurálva, akkor a rekordok így néznének ki:

Ebben a példában a prioritási szám alapján a “mail1” az előnyben részesített szerver a “mail2”-vel szemben. A kódot tovább rövidíthetjük a teljes domain név elhagyásával:

NS rekordok

Ezek a rekordok határozzák meg az adott zóna névszervereit. Most a nyilvánvaló kérdés az, hogy ha a zónafájl a névszerveren belül található, miért van szükség önmagára való hivatkozásra? A kérdésre az egyik válasz a DNS-rendszer többszörös gyorsítótárazási mechanizmusa. A zónafájl valójában egy gyorsítótárazott másolat is lehet más szervereken.

Az MX rekordokhoz hasonlóan az NS rekordok is a teljes zónára vonatkoznak. Így alapértelmezés szerint nincs konkrét gépük. Az NS rekord bejegyzések valahogy így fognak kinézni:

Ajánlott két névszervert megadni arra az esetre, ha az egyik szerver nem működne megfelelően. Ráadásul a legtöbb DNS-szerver elutasítja a zónafájlt, ha az csak egyetlen névszervert tartalmaz.

A gépek hozzárendelését is meg kell adnia A vagy AAAA rekordokkal:

PTR rekordok

A PTR rekordok a klasszikus A vagy AAAA rekordok ellentétei. Ezeket a rekordokat egy IP-címhez társított név meghatározására használják. Ezek a rekordok egyedi tulajdonsággal rendelkeznek, mivel a .arpa gyökérnél kezdődnek, és az IP-cím tulajdonosát képviselik. Az RIR-ek (Regional Internet Registries) osztják ki az IP-címeket a szervezeteknek és szolgáltatóknak. Az RIR-ek közé tartozik az APNIC, az AFRINIC, a LACNIC, a RIPE NCC és az ARIN.

Például egy PTR rekord a 111.222.333.444 esetében valahogy így nézne ki:

A következő PTR rekord példában nézzük meg a Google IPv6 DNS szerverét 2001:4860:4860::8888:

A dig eszközt használhatjuk a -x flaggel egy IP-cím fordított DNS nevének lekérdezésére. Például nézzük meg a következő IP-cím fordított DNS-ét: 8.8.4.4:

Az internetes szerverek PTR rekordokat használnak a domain nevek nyomon követésére a naplóbejegyzésekben, a megalapozott spamkezelési döntések meghozatalára, valamint a többi eszközről szóló, könnyen olvasható információk megjelenítésére.

A gyakran használt e-mail szerverek lekérdezik annak az IP-címnek a PTR rekordját, amelyről az e-mailt küldték. Ha a PTR rekord üres, akkor nagy a valószínűsége annak, hogy az e-mail spam (ezért elutasításra kerül). Vegye figyelembe, hogy az FQDN és a PTR rekord domain neve közötti egyezés nem feltétlenül elvárás. A fontos tényező az, hogy egy érvényes PTR rekord társítva van-e a megfelelő és egyező előremutató A rekorddal.

Általában az interneten lévő hálózati útválasztók (routerek) a fizikai helyüknek megfelelő PTR rekordokkal rendelkeznek. Például az “NYC” vagy a “CHI” érvényes hivatkozások a New Yorkban és Chicagóban található routerekre. Ez a technika hasznos traceroute vagy MTR futtatásakor, valamint a csomagok által bejárt útvonal áttekintésekor.

CAA rekordok

Ezek a rekordok határozzák meg azokat a CA-kat (tanúsítványkiosztókat), amelyek SSL/TLS tanúsítványt bocsáthatnak ki az Ön domainjéhez. 2017. szeptember 8. óta minden CA köteles ellenőrizni a CAA rekordokat a tanúsítvány kibocsátása előtt. Ha nem létezik CAA rekord, akkor bármelyik CA kibocsáthat tanúsítványt. Ellenkező esetben csak a meghatározott CA-k jogosultak tanúsítványok kibocsátására. A CAA rekordok alkalmazhatók egyedi hosztokra vagy egy teljes domainre is.

Íme egy példa egy CAA rekordra:

A bejegyzés CAA-specifikus része a 0 issue "letsencrypt.org". Ez a rész három összetevőből áll:

• Flagek: Ez egy egész szám, amely jelzi, hogyan kell a CA-nak kezelnie azokat a tageket, amelyeket nem ért meg. Ha a flag értéke 0, akkor a rekord figyelmen kívül marad. Ha az érték 1, akkor a CA-nak meg kell tagadnia a tanúsítvány kibocsátását.
• Tagek: Ezek a CAA rekord célját jelölő karakterláncok. Jelenleg az érvényes értékek a következők: issue (engedélyezi egy CA számára, hogy tanúsítványokat bocsásson ki egy adott domainhez), issuewild (helyettesítő karakteres tanúsítványokat engedélyez), és iodef (meghatároz egy URL-t, ahol a CA-k jelenthetik az irányelvsértéseket).
• Értékek: Ezek a rekord tagjéhez társított karakterláncok. Ha a tag issue vagy issuewild, az érték általában azon CA domainje lesz, amelynek engedélyt ad. Ha a tag iodef, akkor egy kapcsolatfelvételi űrlap URL-je vagy egy mailto: link lesz az e-mailes visszajelzéshez.

A dig eszközzel lekérhetjük a CAA rekordokat:

A CAA rekordokkal kapcsolatos részletesebb információkért tekintse meg az RFC 6844.

Záró gondolatok

Ez az útmutató különféle DNS-sel kapcsolatos terminológiákat ismertet. Azt is leírja, hogyan kapcsolódnak össze az egyes összetevők. Ezzel az alapos áttekintéssel a birtokában jól kell értenie a DNS-rendszer működését. Bár az alapgondolat egyszerű és könnyen érthető, a részletek nagyon gyorsan bonyolulttá válnak. A tapasztalatlan adminisztrátorok számára nehéz lehet alkalmazni ezeket a koncepciókat és stratégiákat.

Ön a CloudSigma ügyfele? Akkor tekintse meg a a CloudSigma infrastruktúrájához tartozó reverz DNS/PTR rekordok kezelését és frissítését.

Kellemes számítástechnikát!