Egyetlen lekérdezésben olvassa be a domain összes fontos DNS-rekordját: A, AAAA, MX, TXT, CNAME, NS, SOA és CAA, TTL-lel együtt. Az SPF, DKIM és DMARC bejegyzéseket inline elemzi, és érvényességi badge-dzsel jeleníti meg. A lookup a KernelHost frankfurti FRA01-es csomópontjáról fut.
Melyik domaint ellenőrizzük?
Hogyan működik a DNS?
A Domain Name System (DNS) az internet telefonkönyve. Amikor a böngészője megnyitja a tools.kernelhost.com-ot, a domaint először IP-címmé fordítja. A DNS nem egyetlen szerver, hanem hierarchikus lánc: gyökérszerverek (.), TLD-szerverek (.com, .de, .at), végül a domain autoritatív névszervere. A resolver bejárja ezt a láncot, és helyben cache-eli az eredményt.
Egy DNS-lekérdezés kérdésből és válaszból áll: milyen X típusú rekordok léteznek az Y domainhez? A válasz egy vagy több rekordot, valamint TTL-t (time to live) tartalmaz, amely megmondja a resolvernek, mennyi ideig tarthatja cache-ben az adatot. A DNS-változások ezért nem azonnal láthatók világszerte, hanem a cache-hierarchia mentén terjednek.
Eszközünk UDP/TCP-lookupot indít a frankfurti FRA01-es konténer rendszer-resolverén keresztül. Nincs követés, nincs naplózás a lekérdezett domainről, és nincs harmadik feles API. A válasz általában néhány ezredmásodperc alatt érkezik, mert a frankfurti csomópont közvetlenül a DE-CIX-hez kapcsolódik.
Milyen rekordtípusok léteznek?
Minden DNS-rekordtípusnak megvan a maga konkrét feladata. Eszközünk a nyolc leggyakoribb típust mutatja, amelyekre egy domain üzemeltetéséhez valóban szüksége van.
A: Egy domaint IPv4-címhez rendel. Egy domainnek több A rekordja is lehet (round-robin DNS, terheléselosztás).
AAAA: Egy domaint IPv6-címhez rendel. Modern webes felállásokhoz kötelező, a Google pozitívan értékeli az IPv6-csatlakozást.
MX: Mail exchanger. Melyik szerver fogadja az ehhez a domainhez érkező leveleket. Prioritást hordoz (kisebb szám előnyösebb) failoverhez.
TXT: Szabad szöveg. A gyakorlatban szinte kizárólag SPF-hez, DKIM-hez, DMARC-hoz, domain-igazoláshoz (Google, Microsoft) és _acme-challenge-hez (Let's Encrypt) használják.
CNAME: Másik domain aliasa. A www.kernelhost.com lehet CNAME, amely a kernelhost.com-ra mutat. CNAME nem engedélyezett magán az apex domainen.
NS: Mely névszerverek autoritatívak ehhez a domainhez. Az NS rekordokat a domain regisztrációjakor állítják be, és meghatározzák, hol kezelik az összes többi rekordot.
SOA: Start Of Authority. Az elsődleges névszervert, az admin email-t és a refresh/retry/expire/minimum TTL értékeket határozza meg zónaátvitelekhez.
CAA: Certificate Authority Authorization. Mely CA-k bocsáthatnak ki TLS-tanúsítványt ehhez a domainhez. Védelem az illetéktelen tanúsítványkibocsátás ellen.
MX vs SPF vs DKIM vs DMARC: email-beállítás magyarázata
A teljes email-beállítás négy DNS-komponensből áll. Ha bármelyik hiányzik, a levél vagy meg sem érkezik, vagy a spam mappában landol.
MX (fogadás): Megmondja a világnak, melyik szerver fogadja a domain bejövő levelét. MX nélkül senki sem írhat önnek. Az MX jellemzően egy hosztnévre mutat, mint mx.kernelhost.com, amelyet aztán A/AAAA-n keresztül oldanak fel.
SPF (feladó hitelesítése): v=spf1-gyel kezdődő TXT rekord, amely megadja, mely IP-k küldhetnek jogosan levelet a domainjéből. A végén lévő -all kötelező (különben bárki hamisíthatja a domainjét).
DKIM (kriptográfiai aláírás): Minden kimenő levelet privát kulccsal aláírnak, a publikus kulcs DNS-ben van a selector._domainkey.az-ön-domainje.com alatt TXT v=DKIM1 formában. A fogadók ellenőrzik az aláírást, és észlelik a manipulációt.
DMARC (szabály + jelentés): TXT a _dmarc.az-ön-domainje.com alatt v=DMARC1; p=reject; rua=mailto:dmarc@... formában. A DMARC kombinálja az SPF-et és DKIM-et, megmondja a fogadónak, mit tegyen a sikertelen levelekkel, és jelentéseket szolgáltat.
Eszközünk inline elemzi az SPF-et, DKIM-et és DMARC-ot, és zöld, sárga vagy piros badge-dzsel azonnal megmutatja, hogy a beállítás tiszta-e, vagy például hiányzik a -all, a DKIM-kulcs túl rövid, vagy a DMARC csak monitoring módban fut.
TTL és DNS-cache
A TTL (time to live) másodpercben mondja meg a resolvernek, mennyi ideig tarthat cache-ben egy DNS-rekordot. TTL=3600 esetén a resolver csak egy óra múlva kérdezi újra az autoritatív szervert. Ez sávszélességet takarít meg, de a DNS-változások nem lesznek azonnal láthatók.
A megfelelő TTL attól függ, mit szeretne. Stabil éles üzem: magas TTL (1 óra és 1 nap között). Közelgő szervercsere: csökkentse a TTL-t 60-300 másodpercre napokkal előtte, költöztessen, majd emelje vissza.
Rövid TTL (60-300s): Gyors változások, de nagyobb terhelés az autoritatív szerveren és valamivel nagyobb lookup-késleltetés.
Hosszú TTL (3600-86400s): Kisebb terhelés, gyorsabb cache-válaszok, de a változások órákig vagy napokig tartanak, mire világszerte láthatóvá válnak.
Migrációkhoz: Csökkentse a TTL-t 60-300 másodpercre legalább 24 órával a költözés előtt, hogy minden resolver-cache éppen a cutover előtt járjon le.
Mi a DNSSEC, és szükségem van rá?
A DNSSEC (DNS Security Extensions) kriptográfiailag aláírja a DNS-rekordokat, hogy a resolver ellenőrizhesse, manipulálták-e a választ útközben. DNSSEC nélkül egy rosszindulatú internetszolgáltató vagy publikus WiFi-resolver hamis IP-ket adhat vissza (DNS-hamisítás).
A DNSSEC két kulcsot használ: a ZSK (zone signing key) aláírja a rekordokat, a KSK (key signing key) aláírja a ZSK-t. A KSK hash-ét DS rekordként a regisztrátornál teszik közzé, lezárva a bizalmi láncot a gyökérig.
Szüksége van rá? Bankoknak, közszolgáltatásoknak, levelezőszolgáltatóknak és bárkinek, aki SMIMEA-, TLSA- vagy OPENPGPKEY-rekordokat (DANE) használ: igen. Egy átlagos webáruháznál a DNSSEC nice-to-have, ami semmibe sem kerül, ha a szolgáltató támogatja. A KernelHost DNS alapból támogatja a DNSSEC-et.
Gyakori hibakeresési esetek
Mire van valójában szüksége erre az eszközre a hétköznapokban:
A levél nem érkezik meg: Ellenőrizze az MX rekordokat, majd az SPF-et, DKIM-et, DMARC-ot. Ha bármelyik a négyből hibás, a levél spambe kerül, vagy a fogadó elutasítja.
A domain rossz IP-re mutat: Ellenőrizze az A és AAAA rekordokat. Szervercsere során sokszor csak az A rekordokat frissítik, és a régi AAAA rekordok megmaradnak.
Az aldomain nem válaszol: Ellenőrizze a CNAME-et vagy a közvetlen A rekordot az aldomainen. Gyakori hiba: az aldomaint létrehozták a hosting-panelben, de a DNS még a semmibe mutat.
DNS-propagáció ellenőrzése: Egy változtatás után végezzen több lookupot időben szétszórva. Amint a TTL lejárt, minden resolvernek látnia kellene az új rekordokat.
A Lets Encrypt elutasítja a tanúsítványt: Ellenőrizze a CAA rekordokat. Ha csak egy másik CA-t listáznak, és a Lets Encrypt hiányzik, a Lets Encrypt elutasítja a kibocsátást.
DNS a KernelHostnál
A KernelHost webtárhely teljes managed DNS-t tartalmaz: minden rekordot a vezérlőpanelünkből kezelünk, a DNSSEC alapból bekapcsolva, és a frankfurti és bécsi földrajzilag redundáns anycast-névszerverek világszerte gyors válaszokat biztosítanak.
Aki csak DNS-hostingot szeretne webtárhely nélkül, használhatja domain-szolgáltatási csomagjainkat. A domain-regisztráció, transzfer és DNS-kezelés minden KernelHost hosting-csomag része. Komplexebb felállásokhoz (split horizon, geo DNS, magas TTL-pontosság) egy VPS plusz saját autoritatív szerver opció, és ezt az eszközt bármikor használhatja diagnosztikára.
Gyakori kérdések
Milyen rekordtípusokat kérdez le?
A, AAAA, MX, TXT, CNAME, NS, SOA és CAA. Ez a nyolc leggyakoribb típus, amelyre egy domain üzemeltetéséhez valóban szüksége van. Speciális rekordok, mint SRV, PTR, DS, DNSKEY vagy TLSA a Check-Host eszköz DNS módjában érhetők el dig-gel.
Automatikusan megtalálja a DKIM-szelektorokat?
Nem. A DKIM rekordok a <selector>._domainkey.<domain> alatt találhatók, és a szelektor tetszőleges (google, k1, default és így tovább). A szelektor ismerete nélkül a DKIM bejegyzések nem listázhatók. Ha ismeri a szelektort, adja meg közvetlenül, pl. google._domainkey.kernelhost.com domainként, és az eszköz parserrel mutatja a TXT bejegyzést.
Automatikusan ellenőrzi a DMARC-ot?
Igen. A DMARC mindig a _dmarc.<domain> alatt található, és automatikusan a fő domainnel párhuzamosan kérdezzük le. A bejegyzés a TXT blokkban DMARC badge-dzsel és a szabály (none / quarantine / reject), pct, aspf, adkim és rua magyarázatával jelenik meg.
Mit jelent a 'nincs MX rekord'?
Ez a domain nem fogad emailt. Ha levelet küld, mondjuk, az info@ez-a-domain.com címre, az visszapattan. Az MX a levélfogadás kötelező feltétele, MX nélkül nem fogadhat levelet a domainhez, akkor sem, ha van A rekord.
Milyen TTL-értékek értelmesek?
Éles üzemben 3600 másodperc (1 óra) és 86400 másodperc (1 nap) között. Változtatások előtt csökkentse 60-300 másodpercre legalább 24 órával előbb, hogy a cache rövid legyen, és a változás gyorsan láthatóvá váljon világszerte. Utána emelje vissza.
Tárolják a bevitt adatokat?
Nem. Nincs naplózás a lekérdezett domainekről, nincsenek követő sütik, és nincs harmadik feles API. A lookup helyben fut a konténerben dns_get_record()-on keresztül. Nem látunk lekérdezési előzményeket, és nem is tudjuk azokat naplókból visszaállítani.
Miért nem látok DNSSEC rekordokat?
Az eszköz nyolc szabványos rekordtípust mutat. A DNSSEC-specifikus rekordok (DS, DNSKEY, RRSIG, NSEC) a Check-Host eszköz DNS módjában érhetők el (dig +dnssec). Itt a fókusz azokon a rekordokon van, amelyeket minden domaintulajdonos rendszerint maga kezel, nem az érvényesítési láncon.
Használhatom az eszközt aldomainekhez?
Igen. Egyszerűen adja meg az aldomaint (pl. www.kernelhost.com vagy mail.kernelhost.com). Aldomaineken gyakoriak a CNAME rekordok, az A/AAAA-t a CNAME-en keresztül oldja fel a resolver, és egy válaszba kombinálja.
Az összes KernelHost termék
Többre van szükséged, mint eszközökre? Nézd meg kereskedelmi tárhely-kínálatunkat.