Najčastejšie chyby

Modul 8: Bezpečnosť a riešenie problémov · Čas čítania: 10 min

Cieľ lekcie: Po tejto lekcii rozpoznáte desať najčastejších DNS chýb podľa ich príznaku a budete vedieť, ako ich vyriešiť.

Kľúčové pojmy: bodka na konci, zdvojená doména, úprava na nesprávnom mieste, dva SPF záznamy, CNAME na holej doméne, zabudnutý AAAA, MX bez adresy, proxy pre mail, stará DS po prevode domény, cache

Ako používať túto lekciu

Chyby uvedené nižšie nepochádzajú z učebnice, ale z otázok, ktoré hostingové spoločnosti dostávajú každý týždeň. Pri každej chybe si ukážeme: čo si používateľ všimne, ako to overíte jedným dotazom a aké je riešenie. Pri probléme vždy začínajte rovnakými dvoma otázkami: aké menné servery má doména (dig +short NS example.com) a čo vracia autoritatívny menný server (dig @<nameserver> <naam> <type>). Tým vyriešite polovicu prípadov.

1. Zabudnutá bodka na konci

Príznak: CNAME, MX alebo NS nefunguje; služba hlási "record not found".
Overenie: dig +short CNAME shop.example.com vráti shops.platform.example.example.com.
Príčina: v zóne je názov bez bodky na konci relatívny: panel k nemu pripojí vašu vlastnú doménu (lekcia 2.2).
Riešenie: zapíšte cieľový názov ako úplný s bodkou (shops.platform.example.). Niektoré panely bodku dopĺňajú samy; po uložení skontrolujte, čo tam naozaj je.

2. Doména zdvojená v názve

Príznak: overenie alebo kontrola DKIM pri nejakej službe zlyhá, hoci záznam "tam je".
Overenie: dig +short TXT k2._domainkey.example.com nevráti nič, ale dig +short TXT k2._domainkey.example.com.example.com áno.
Príčina: služba zadáva úplný názov (k2._domainkey.example.com) a váš panel k nemu ešte raz pripojí doménu.
Riešenie: do poľa pre názov vyplňte iba časť pred vašou doménou: k2._domainkey. Panel zvyčajne pod poľom zobrazuje úplný názov: skontrolujte ho.

3. Úprava na nesprávnom mieste

Príznak: upravíte záznam, no nič sa nezmení, ani po dni.
Overenie: dig +short NS example.com vráti menné servery inej spoločnosti, než u ktorej ste úpravu robili (napríklad tvorcu webu alebo Cloudflare).
Príčina: DNS určuje iba spoločnosť, ktorej menné servery sú nastavené (lekcia 2.1). Záznamy na inom mieste nemajú žiadny účinok.
Riešenie: upravte záznam u spoločnosti, ktorej menné servery sú aktívne, alebo vráťte menné servery späť. Reálny príklad: niekto nastavil menné servery na platformu na tvorbu webu kvôli webstránke, ale A záznam pre mail tam chýbal. Výsledok: odosielanie fungovalo, prijímanie nie, lebo MX ukazoval na mail.example.com a tento názov už neexistoval.

4. Dva SPF záznamy

Príznak: pošta čoraz častejšie končí v spame alebo je odmietnutá, odkedy ste pripojili novú službu.
Overenie: dig +short TXT example.com vráti dva riadky začínajúce na v=spf1.
Príčina: nová služba uviedla "pridajte tento SPF záznam" a to sa urobilo doslovne. Pri dvoch SPF záznamoch je SPF neplatný (permerror, RFC 7208), čo je horšie než žiadny SPF.
Riešenie: spojte ich do jedného záznamu: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Dbajte na hranicu desiatich vyhľadávaní (lekcia 4.3).

5. CNAME na holej doméne

Príznak: panel záznam odmietne, alebo po uložení prestane fungovať vaša pošta.
Overenie: služba žiada "vytvorte CNAME pre @".
Príčina: CNAME nesmie existovať popri iných záznamoch a na holej doméne sú vždy záznamy SOA a NS (a často aj MX a TXT). Pozrite lekciu 3.2.
Riešenie: na @ použite A záznam (prípadne AAAA) podľa zadania služby a CNAME použite iba pre www alebo subdoménu. Niektorí DNS poskytovatelia majú pre tento prípad ALIAS alebo "CNAME flattening".

6. Zabudnutý AAAA pri prevode

Príznak: po prevode časť návštevníkov (často mobilných) stále vidí starú stránku alebo chybu certifikátu.
Overenie: dig +short A example.com vráti novú adresu, dig +short AAAA example.com ešte adresu starého servera.
Príčina: zariadenia s IPv6 uprednostňujú AAAA. Upravený bol iba A záznam.
Riešenie: upravte aj AAAA, alebo ho odstráňte, ak nový server nemá IPv6. Reálny príklad: pri napojení platformy pre internetový obchod bolo potrebné popri novom A zázname odstrániť aj starý AAAA, inak zostal obchod pre časť návštevníkov nedostupný.

7. MX, ktorý ukazuje do prázdna

Príznak: neprijímate žiadnu poštu; odosielatelia dostávajú chybové hlásenie.
Overenie: dig +short MX example.com vráti 10 mail.example.com., ale dig +short A mail.example.com nevráti nič (NXDOMAIN).
Príčina: MX ukazuje na názov a ten názov musí mať záznam A alebo AAAA. Často A záznam pre mail zanikol pri prevode menných serverov. MX nesmie ukazovať ani na IP adresu, ani na CNAME (RFC 2181).
Riešenie: vytvorte A záznam pre názov mailového servera, alebo nasmerujte MX na názov, ktorý adresu má.

8. Pošta inde, ale starý server si myslí, že ju má doručiť on

Príznak: pošta zvonku dochádza správne vášmu novému poskytovateľovi, ale pošta z vlastnej webstránky (kontaktný formulár, internetový obchod) nikdy nedôjde. Niekedy dostanete 550 Unknown user.
Overenie: MX ukazuje na nového poskytovateľa, ale na webovom serveri je stále zapnuté lokálne doručovanie pošty.
Príčina: toto nie je DNS chyba, ale vyzerá tak. Webový server, ktorý si myslí, že sám spravuje mailové schránky, sa na MX nepozerá.
Riešenie: v paneli hostingu vypnite lokálne doručovanie (v DirectAdmin: políčko "Use this server to handle my e-mails"). Iné panely majú podobné nastavenie, často nazvané "Remote mail exchanger" alebo "externý e-mail".

9. Zapnutá proxy pre mail

Príznak: u DNS poskytovateľa s funkciou proxy (napríklad oranžový obláčik v Cloudflare) web funguje, ale mailový program sa nedokáže pripojiť, alebo sa neobnoví certifikát stránky.
Overenie: dig +short A mail.example.com vráti adresu proxy namiesto vášho mailového servera.
Príčina: webová proxy presmeruje iba webovú prevádzku, nie poštu.
Riešenie: vypnite proxy (šedý obláčik, "DNS only") pre mail a všetky názvy, ktoré váš mailový program používa. Pre certifikáty: dočasne vypnite proxy, kým certifikát nebude vydaný, alebo použite správny režim SSL pri proxy.

10. Stará DS po prevode

Príznak: po prevode menných serverov je vaša doména pre časť sveta nedostupná; iným ľuďom to nerobí problém.
Overenie: dig example.com @1.1.1.1 vráti SERVFAIL, dig +cd example.com @1.1.1.1 odpoveď dá. DNSViz (https://dnsviz.net/, lekcia 8.1) zafarbí DS načerveno a pod ňou zobrazí sivý, bodkovaný kľúč, ktorý už nie je vo vašej zóne. Zonemaster a Verisign DNSSEC Debugger hlásia to isté slovne.
Príčina: v registri je stále DS od pôvodnej spoločnosti (lekcia 8.1). Zlyhávajú iba validujúce resolvery, preto si to nevšimnú všetci.
Riešenie: nechajte DS aktualizovať na kľúč novej spoločnosti, alebo ho odstráňte a potom DNSSEC znova zapnite.

A "chyba", ktorá nie je chybou: cache

Veľmi často je všetko v poriadku, no vy stále vidíte starú odpoveď. Spoznáte to takto: dig @<nameserver> vráti novú odpoveď, online kontrolný nástroj v iných krajinách tiež, iba váš počítač nie. Riešenie: súkromné okno, telefón cez 4G/5G, alebo vyčistenie cache (lekcia 8.2). Rovnaký obraz spôsobí aj zabudnutý riadok v súbore hosts na vašom počítači (z predchádzajúceho testu pred prevodom): tento riadok odstráňte.

Súvisiaca pasca: vyžiadanie nového názvu ešte predtým, než ho vytvoríte. Resolver si potom zapamätá "neexistuje" (negatívna cache) a nový názov bude fungovať až s oneskorením (lekcia 6.2).

V praxi: ako to vyzerá v paneli

Mnohé panely časti týchto chýb predchádzajú. Môj WebOké napríklad upozorní, ak chýba bodka na konci, a pod poľom pre názov zobrazí úplný názov; DirectAdmin odmietne neplatné záznamy s hlásením "Error Writing Records". Cloudflare a iní poskytovatelia majú podobné upozornenia. Pred väčšími zmenami si vytvorte zálohu alebo export zóny, aby ste sa vždy mohli vrátiť späť.

Zhrnutie

• Vždy začnite s: aké menné servery a čo hovorí autoritatívny menný server.
• Väčšina chýb je v názve (bodka, zdvojená doména) alebo v mieste (nesprávna spoločnosť).
• Jeden SPF záznam, žiadny CNAME na @, AAAA prevádzať spolu s A, MX na názov s adresou.
• SERVFAIL po prevode je väčšinou stará DS.
• Ak starú odpoveď vidíte iba vy, je to vaša cache alebo súbor hosts.

Kvíz

Úloha

Úloha Z8.4: Rozpoznávanie chýb. Dostanete päť krátkych prípadov spolu s výstupom dig (v prostredí kurzu). Pri každom prípade vyberte, o ktorú z desiatich chýb ide. Potom nasleduje skutočné pátranie: pomocou dig alebo online nástroja zistite, ktorý záznam je chybný pre dnssec-failed.org (stav a čo ukáže +cd), a či má wikipedia.org presne jeden SPF záznam.

$ dig +short MX example.com
10 mail.example.com.
$ dig A mail.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

$ dig +short TXT example.com
"v=spf1 mx include:_spf.hosting.example ~all"
"v=spf1 include:spf.service.example ~all"

$ dig +short CNAME shop.example.com
shops.platform.example.example.com.

$ dig example.com A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
$ dig +cd +short example.com A @1.1.1.1
192.0.2.10

$ dig +short A example.com
198.51.100.10
$ dig +short AAAA example.com
2001:db8::10    (adresa starého servera)

Ďalšie čítanie

Tieto články popisujú riešenia v paneloch WebOké; u iných poskytovateľov sa tlačidlá volajú inak.

• Webová stránka alebo e-mail nefunguje po presune alebo zmene DNS: skontrolujte svoju doménu
• Ako dlho trvá zmena nameserveru alebo DNS a čo robiť, ak ju nevidíte?
• Návod na DirectAdmin 18.7: Moja doména ešte nefunguje po prevode alebo zmene
• Návod na DirectAdmin 18.9: Neprijímam už žiadne e-maily
• Návod na DirectAdmin 5.4: CNAME záznamy a bodka na konci
• Odosielanie e-mailov cez PHP nefunguje, záznamy MX smerujú inam
• Použiť vlastné alebo externé nameservery (napríklad Cloudflare) pre váš domén