8. modul · 8.4
Gyakori hibák
8. modul: Biztonság és hibaelhárítás · Olvasási idő: 10 perc
Tanulási cél: E lecke után felismeri a tíz leggyakrabban elkövetett DNS-hibát a tünetük alapján, és tudja, hogyan oldja meg őket.
Kulcsfogalmak: pont a végén, kettőzött domainnév, módosítás rossz helyen, két SPF-rekord, CNAME a csupasz domainen, elfeledett AAAA, MX cím nélkül, proxy e-mailhez, régi DS átvitel után, cache
Hogyan használja ezt a leckét
Az alábbi hibák nem tankönyvből származnak, hanem azokból a kérdésekből, amelyeket a tárhelyszolgáltatók hetente kapnak. Hibánként láthatja: mit tapasztal a felhasználó, hogyan mutatható ki egy kérdéssel, és mi a megoldás. Egy probléma esetén mindig ugyanazzal a két kérdéssel kezdjen: milyen névszerverei vannak a domainnek (dig +short NS example.com) és mit ad vissza az autoritatív névszerver (dig @<nameserver> <naam> <type>). Ezzel az esetek felét máris megoldja.
1. A pont elfelejtése a végén
Tünet: egy CNAME, MX vagy NS nem működik; egy szolgáltatás azt jelzi, hogy "a rekord nem található".
Kimutatás: dig +short CNAME shop.example.com ezt adja vissza: shops.platform.example.example.com.
Ok: egy zónában a pont nélküli név relatív: a vezérlőpult a saját domainjét illeszti a végére (2.2. lecke).
Megoldás: írja a célnevet teljes névként, ponttal a végén (shops.platform.example.). Egyes vezérlőpultok maguk teszik ki a pontot; mentés után ellenőrizze, mi szerepel valójában.
2. A domainnév kettőzése a névben
Tünet: egy ellenőrzés vagy DKIM-vizsgálat egy szolgáltatásnál nem sikerül, miközben a rekord "ott van".
Kimutatás: dig +short TXT k2._domainkey.example.com semmit nem ad vissza, de dig +short TXT k2._domainkey.example.com.example.com igen.
Ok: a szolgáltatás a teljes nevet adja meg (k2._domainkey.example.com), és a vezérlőpult még egyszer hozzáfűzi a domaint.
Megoldás: a névmezőbe csak a domain előtti részt írja be: k2._domainkey. A vezérlőpult a mező alatt általában megmutatja a teljes nevet: ezt ellenőrizze.
3. Módosítás a rossz helyen
Tünet: módosít egy rekordot, de semmi nem változik, még egy nap után sem.
Kimutatás: dig +short NS example.com más fél névszervereit adja vissza, mint ahol a módosítást végezte (például egy weboldalkészítőét vagy a Cloudflare-ét).
Ok: csak a névszervereket birtokló fél határozza meg a DNS-t (2.1. lecke). A máshol lévő rekordok hatástalanok.
Megoldás: módosítsa a rekordot a névszervereket birtokló félnél, vagy állítsa vissza a névszervereket. Valós példa: valaki a weboldal miatt egy weboldalkészítő platform névszervereire állította a domaint, de a mail A-rekordja ott nem létezett. Ennek következménye: a küldés működött, a fogadás nem, mert az MX a mail.example.com névre mutatott, amely már nem létezett.
4. Két SPF-rekord
Tünet: a levelek gyakrabban kerülnek a spamba vagy kerülnek elutasításra, amióta egy új szolgáltatást kapcsolt be.
Kimutatás: dig +short TXT example.com két olyan sort ad vissza, amely v=spf1-gyel kezdődik.
Ok: az új szolgáltatás azt mondta: "adja hozzá ezt az SPF-rekordot", és ezt szó szerint meg is tették. Két SPF-rekorddal az SPF érvénytelen (permerror, RFC 7208), ami rosszabb, mint ha egyáltalán nem lenne SPF.
Megoldás: egyesítse őket egyetlen rekordba: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Ügyeljen a tíz lekérdezéses korlátra (4.3. lecke).
5. CNAME a csupasz domainen
Tünet: a vezérlőpult elutasítja a rekordot, vagy mentés után megszűnik a levelezés.
Kimutatás: a szolgáltatás azt kéri: "hozzon létre egy CNAME-et a @ számára".
Ok: egy CNAME nem állhat más rekordok mellett, a csupasz domainen pedig mindig van SOA- és NS-rekord (gyakran MX és TXT is). Lásd a 3.2. leckét.
Megoldás: a @ esetén a szolgáltatás által megadott A-rekordot (és esetleg AAAA-t) használja, a CNAME-et pedig csak a www vagy egy aldomain esetén. Egyes DNS-szolgáltatóknál erre az esetre ALIAS vagy "CNAME flattening" funkció áll rendelkezésre.
6. Az AAAA elfelejtése átvitel esetén
Tünet: átvitel után a látogatók egy része (gyakran mobilon) még mindig a régi oldalt látja, vagy tanúsítványhibát kap.
Kimutatás: dig +short A example.com az új címet adja vissza, dig +short AAAA example.com viszont még mindig a régi szerver címét.
Ok: az IPv6-ot használó eszközök előnyben részesítik az AAAA-t. Csak az A-rekordot módosították.
Megoldás: módosítsa az AAAA-t is, vagy törölje, ha az új szervernek nincs IPv6-címe. Valós példa: egy webáruházplatform bekapcsolásakor az új A-rekord mellett a régi AAAA-t is el kellett távolítani, különben a bolt a látogatók egy része számára elérhetetlen maradt.
7. Egy MX, amely semmire sem mutat
Tünet: nem érkeznek levelek; a feladók hibaüzenetet kapnak vissza.
Kimutatás: dig +short MX example.com ezt adja vissza: 10 mail.example.com., de a dig +short A mail.example.com semmit (NXDOMAIN).
Ok: az MX egy névre mutat, és annak a névnek A- vagy AAAA-rekordja kell hogy legyen. Gyakran a mail A-rekordja egy névszerver-átvitel során eltűnt. Az MX nem mutathat IP-címre vagy CNAME-re sem (RFC 2181).
Megoldás: hozzon létre egy A-rekordot a levelezőszerver nevéhez, vagy irányítsa az MX-et olyan névre, amelynek van címe.
8. A levelezés máshol van, de a régi szerver azt hiszi, neki kell kézbesítenie
Tünet: a kívülről érkező levelek rendben megérkeznek az új szolgáltatóhoz, de a saját weboldaláról (kapcsolatfelvételi űrlap, webáruház) küldött levelek soha nem érkeznek meg. Néha 550 Unknown user hibát kap.
Kimutatás: az MX az új szolgáltatóra mutat, de a webszerveren még be van kapcsolva a helyi levélkézbesítés.
Ok: ez nem DNS-hiba, de úgy néz ki, mintha az lenne. Egy webszerver, amely azt hiszi, hogy nála vannak a postafiókok, nem veszi figyelembe az MX-et.
Megoldás: kapcsolja ki a tárhely vezérlőpultján a helyi kézbesítést (DirectAdminban: a "Használja ezt a szervert az e-mailjeim kezelésére" jelölőnégyzet). Más vezérlőpultokon hasonló beállítás található, gyakran "Remote mail exchanger" vagy "külső e-mail" néven.
9. Proxy bekapcsolva levelezéshez
Tünet: egy proxyfunkcióval rendelkező DNS-szolgáltatónál (például a Cloudflare narancssárga felhőjénél) a weboldal működik, de a levelezőprogram nem tud kapcsolódni, vagy az oldal tanúsítványa nem újul meg.
Kimutatás: dig +short A mail.example.com a proxy címét adja vissza a levelezőszerver címe helyett.
Ok: egy webproxy csak a webes forgalmat továbbítja, a levelezést nem.
Megoldás: kapcsolja ki a proxyt (szürke felhő, "DNS only") a mail és minden olyan név esetén, amelyet a levelezőprogramja használ. Tanúsítványok esetén: kapcsolja ki ideiglenesen a proxyt, amíg a tanúsítvány el nem készül, vagy használja a proxynál a megfelelő SSL-beállítást.
10. Régi DS átvitel után
Tünet: egy névszerver-átvitel után a domain a világ egy része számára elérhetetlen; mások semmit nem észlelnek.
Kimutatás: a dig example.com @1.1.1.1 SERVFAIL-t ad, a dig +cd example.com @1.1.1.1 viszont választ ad. A DNSViz (https://dnsviz.net/, 8.1. lecke) pirosra színezi a DS-t, és alatta szürke, szaggatott vonalú kulcsot rajzol, amely már nincs a zónájában. A Zonemaster és a Verisign DNSSEC Debugger ugyanezt jelzi szövegesen.
Ok: a nyilvántartónál még a régi szolgáltató DS-je szerepel (8.1. lecke). Csak a validáló resolverek hibáznak, ezért nem mindenki veszi észre.
Megoldás: frissíttesse a DS-t az új szolgáltató kulcsával, vagy távolítsa el, majd kapcsolja be újra a DNSSEC-et.
És a "hiba", ami nem hiba: a cache
Nagyon gyakran minden rendben van, mégis a régi választ látja. Erről ismeri fel: a dig @<nameserver> az új választ adja, egy online ellenőrző eszköz más országokban szintén, csak az Ön számítógépe nem. Megoldás: privát ablak, telefon 4G/5G-n keresztül, vagy a cache ürítése (8.2. lecke). Egy elfelejtett sor a számítógép hosts-fájljában (egy korábbi, átvitel előtti tesztből) szintén ezt a képet adja: távolítsa el azt a sort.
Egy rokon buktató: egy új nevet már azelőtt lekérdezni, hogy létrehozta volna. A resolver ilyenkor megjegyzi, hogy "nem létezik" (negatív cache), és tovább tart, amíg az új név működni kezd (6.2. lecke).
A gyakorlatban: így néz ki egy vezérlőpulton
Sok vezérlőpult megelőzi e hibák egy részét. A Fiókom például figyelmeztet, ha hiányzik a pont a végén, és a névmező alatt megmutatja a teljes nevet; a DirectAdmin elutasítja az érvénytelen rekordokat egy "Error Writing Records" üzenettel. A Cloudflare és más szolgáltatók hasonló figyelmeztetésekkel rendelkeznek. Nagyobb módosítások előtt készítsen biztonsági mentést vagy exportot a zónájáról, így mindig visszatérhet.
Összefoglalás
- Mindig ezzel kezdje: milyen névszerverek vannak, és mit mond az autoritatív névszerver.
- A legtöbb hiba a névben rejlik (pont, kettőzött domainnév) vagy a helyben (rossz fél).
- Egy SPF-rekord, nincs CNAME a @ esetén, az AAAA-t is vigye át, az MX olyan névre mutasson, amelynek van címe.
- Az átvitel utáni SERVFAIL általában egy régi DS-t jelent.
- Ha csak Ön látja a régi választ, az a cache-e vagy a hosts-fájlja miatt van.
Kvíz
Feladat
Feladat Z8.4: Hibák felismerése. Öt rövid esetet kap a dig kimenetével együtt (a tanfolyami környezetben). Válassza ki esetenként, melyik a tíz hiba közül. Ezután egy valódi nyomozás: derítse ki dig vagy egy online eszköz segítségével, melyik rekord hibás a dnssec-failed.org esetében (állapot és mit ad vissza a +cd), valamint hogy a wikipedia.org pontosan egy SPF-rekorddal rendelkezik-e.
További olvasnivaló
Ezek a cikkek a WebOké vezérlőpultjaiban leírt megoldásokat tartalmazzák; más szolgáltatóknál a gombok más néven szerepelhetnek.
- A weboldal vagy az e-mail nem működik egy átköltözés vagy DNS-módosítás után: ellenőrizze a doménjét
- A névszerver vagy DNS módosítása mennyi ideig tart, és mi a teendő, ha az nem látható?
- DirectAdmin útmutató 18.7: A domainem még nem működik egy átköltöztetés vagy módosítás után
- DirectAdmin útmutató 18.9: Nem érkezik több e-mailem
- DirectAdmin útmutató 5.4: A CNAME-rekordok és a záró pont
- PHP-ből nem sikerül levelet küldeni, az MX-rekordok máshová mutatnak
- Saját vagy külső (például Cloudflare) névszerverek használata a domainhez