Modul 8 · 8.4
Pogosto narejene napake
Modul 8: Varnost in odpravljanje težav · Čas branja: 10 minut
Cilj lekcije: Po tej lekciji boste prepoznali deset najpogostejših DNS napak po njihovih simptomih in vedeli, kako jih odpraviti.
Ključni pojmi: pika na koncu, podvojeno ime domene, spreminjanje na napačnem mestu, dva SPF zapisa, CNAME na goli domeni, pozabljen AAAA, MX brez naslova, proxy za pošto, stari DS po prenosu, predpomnilnik
Kako uporabljati to lekcijo
Spodnje napake ne izvirajo iz učbenika, temveč iz vprašanj, ki jih ponudniki gostovanja prejemajo vsak teden. Pri vsaki napaki je prikazano: kaj uporabnik opazi, kako to dokažete z enim vprašanjem in kakšna je rešitev. Pri težavi vedno začnite z istima dvema vprašanjema: katere imenske strežnike ima domena (dig +short NS example.com) in kaj vrne avtoritativni imenski strežnik (dig @<nameserver> <naam> <type>). S tem rešite že polovico primerov.
1. Pozabljena pika na koncu
Simptom: CNAME, MX ali NS ne deluje; storitev sporoča "zapis ni najden".
Dokazovanje: dig +short CNAME shop.example.com vrne shops.platform.example.example.com.
Vzrok: v coni je ime brez pike na koncu relativno: nadzorna plošča doda Vaše lastno ime domene na konec (lekcija 2.2).
Rešitev: zapišite ciljno ime kot popolno ime s piko (shops.platform.example.). Nekatere nadzorne plošče piko dodajo same; po shranjevanju preverite, kaj je dejansko zapisano.
2. Podvojeno ime domene v imenu
Simptom: preverjanje ali DKIM kontrola pri storitvi ne uspe, čeprav zapis "obstaja".
Dokazovanje: dig +short TXT k2._domainkey.example.com ne vrne nič, medtem ko dig +short TXT k2._domainkey.example.com.example.com vrne rezultat.
Vzrok: storitev navede popolno ime (k2._domainkey.example.com), Vaša nadzorna plošča pa domeno doda še enkrat na konec.
Rešitev: v polje za ime vnesite samo del pred Vašo domeno: k2._domainkey. Nadzorna plošča običajno pod poljem prikaže celotno ime: to preverite.
3. Spreminjanje na napačnem mestu
Simptom: prilagodite zapis, vendar se nič ne spremeni, tudi po enem dnevu ne.
Dokazovanje: dig +short NS example.com vrne imenske strežnike druge stranke kot tiste, pri kateri ste izvedli spremembo (na primer ponudnika spletne strani ali Cloudflare).
Vzrok: samo stranka, pri kateri so imenski strežniki, določa DNS (lekcija 2.1). Zapisi na drugem mestu nimajo nobenega učinka.
Rešitev: spremenite zapis pri stranki, pri kateri so imenski strežniki, ali vrnite imenske strežnike nazaj. Pravi primer: nekdo je imenske strežnike preusmeril na platformo za izdelavo spletnih strani za spletno stran, vendar A zapis za mail tam ni obstajal. Posledica: pošiljanje je delovalo, prejemanje pa ne, saj je MX kazal na mail.example.com, ta naziv pa ni več obstajal.
4. Dva SPF zapisa
Simptom: pošta pogosteje konča v vsiljeni pošti ali je zavrnjena, odkar ste povezali novo storitev.
Dokazovanje: dig +short TXT example.com vrne dve vrstici, ki se začneta z v=spf1.
Vzrok: nova storitev je zahtevala "dodajte ta SPF zapis", kar je bilo dobesedno izvedeno. Z dvema SPF zapisoma je SPF neveljaven (permerror, RFC 7208), kar je slabše kot brez SPF.
Rešitev: združite ju v en zapis: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Pazite na mejo desetih poizvedb (lekcija 4.3).
5. CNAME na goli domeni
Simptom: nadzorna plošča zavrne zapis, ali pa po shranjevanju Vaša pošta preneha delovati.
Dokazovanje: storitev zahteva "ustvarite CNAME za @".
Vzrok: CNAME ne sme obstajati poleg drugih zapisov, na goli domeni pa vedno obstajata SOA in NS zapisa (pogosto tudi MX in TXT). Glejte lekcijo 3.2.
Rešitev: na @ uporabite A zapis (in po potrebi AAAA), ki ga navede storitev, CNAME pa uporabite samo za www ali poddomeno. Nekateri ponudniki DNS imajo za ta primer ALIAS ali "CNAME flattening".
6. Pozabljen AAAA pri prenosu
Simptom: po prenosu del obiskovalcev (pogosto mobilnih) še vedno vidi staro spletno stran ali napako certifikata.
Dokazovanje: dig +short A example.com vrne nov naslov, dig +short AAAA example.com pa še vedno naslov starega strežnika.
Vzrok: naprave z IPv6 prednostno uporabljajo AAAA. Prilagojen je bil samo A zapis.
Rešitev: prilagodite tudi AAAA ali ga odstranite, če nov strežnik nima IPv6. Pravi primer: pri povezovanju platforme za spletno trgovino je bilo poleg novega A zapisa treba odstraniti tudi stari AAAA, sicer je trgovina za del obiskovalcev ostala nedosegljiva.
7. MX, ki kaže v nič
Simptom: ne prejemate pošte; pošiljatelji prejmejo sporočilo o napaki.
Dokazovanje: dig +short MX example.com vrne 10 mail.example.com., vendar dig +short A mail.example.com ne vrne nič (NXDOMAIN).
Vzrok: MX kaže na ime, to ime pa mora imeti A ali AAAA zapis. Pogosto A zapis za mail izgine pri prenosu imenskih strežnikov. MX tudi ne sme kazati na IP naslov ali na CNAME (RFC 2181).
Rešitev: ustvarite A zapis za ime poštnega strežnika ali naj MX kaže na ime, ki ima naslov.
8. Pošta je drugje, star strežnik pa misli, da mora pošto dostaviti sam
Simptom: pošta od zunaj pravilno prispe k novemu ponudniku, pošta z Vaše lastne spletne strani (kontaktni obrazec, spletna trgovina) pa nikoli ne prispe. Včasih prejmete 550 Unknown user.
Dokazovanje: MX kaže na novega ponudnika, na spletnem strežniku pa je lokalna dostava pošte še vedno vklopljena.
Vzrok: to ni DNS napaka, vendar je videti tako. Spletni strežnik, ki misli, da ima sam poštne predale, ne upošteva MX zapisa.
Rešitev: v nadzorni plošči Vašega gostovanja izklopite lokalno dostavo (v DirectAdmin: kljukico "Uporabi ta strežnik za obravnavo moje e-pošte"). Druge nadzorne plošče imajo podobno nastavitev, pogosto poimenovano "Remote mail exchanger" ali "e-pošta zunaj".
9. Vklopljen proxy za pošto
Simptom: pri ponudniku DNS s funkcijo proxy (kot je oranžen oblak pri Cloudflare) spletna stran deluje, Vaš poštni program pa se ne more povezati, ali pa se certifikat spletne strani ne obnovi.
Dokazovanje: dig +short A mail.example.com vrne naslov proxyja namesto Vašega poštnega strežnika.
Vzrok: spletni proxy preusmerja samo spletni promet, ne pošte.
Rešitev: izklopite proxy (sivi oblak, "DNS only") za mail in vsa imena, ki jih uporablja Vaš poštni program. Za certifikate: začasno izklopite proxy, dokler certifikat ni pridobljen, ali uporabite pravilen SSL način pri proxyju.
10. Star DS po prenosu
Simptom: po prenosu imenskih strežnikov je Vaša domena za del sveta nedosegljiva, drugi uporabniki pa nimajo nobenih težav.
Dokazovanje: dig example.com @1.1.1.1 vrne SERVFAIL, dig +cd example.com @1.1.1.1 pa vrne odgovor. DNSViz (https://dnsviz.net/, lekcija 8.1) obarva DS rdeče in pod njim nariše sivo, pikčasto označen ključ, ki ga ni več v Vaši coni. Zonemaster in Verisign DNSSEC Debugger sporočata isto z besedami.
Vzrok: pri registru je še vedno DS stare stranke (lekcija 8.1). Napaka se pokaže samo pri validirajočih razreševalnikih, zato je ne opazijo vsi.
Rešitev: posodobite DS s ključem nove stranke ali ga odstranite in nato ponovno vklopite DNSSEC.
In "napaka", ki to ni: predpomnilnik
Zelo pogosto je vse pravilno nastavljeno, vendar Vi še vedno vidite star odgovor. To prepoznate po tem: dig @<nameserver> vrne nov odgovor, spletno orodje za preverjanje v drugih državah prav tako, samo Vaš računalnik ne. Rešitev: zasebno okno, telefon preko 4G/5G ali počistite predpomnilnik (lekcija 8.2). Tudi pozabljena vrstica v datoteki hosts Vašega računalnika (iz prejšnjega testa pred prenosom) da enak vtis: to vrstico odstranite.
Sorodna past: poizvedovanje po novem imenu, preden ste ga ustvarili. Razreševalnik si tedaj zapomni "ne obstaja" (negativni predpomnilnik), zaradi česar traja dlje, preden novo ime začne delovati (lekcija 6.2).
V praksi: tako je videti v nadzorni plošči
Mnoge nadzorne plošče del teh napak preprečijo. Moj WebOké na primer opozori, če manjka pika na koncu, in pod poljem za ime prikaže celotno ime; DirectAdmin zavrne zapise, ki niso veljavni, s sporočilom "Error Writing Records". Cloudflare in drugi ponudniki imajo podobna opozorila. Pred večjimi spremembami naredite varnostno kopijo ali izvoz svoje cone, tako da se lahko vedno vrnete nazaj.
Povzetek
- Vedno začnite z: kateri imenski strežniki in kaj pravi avtoritativni imenski strežnik.
- Večina napak je v imenu (pika, podvojeno ime domene) ali na mestu (napačna stranka).
- En SPF zapis, brez CNAME na @, AAAA preselite skupaj, MX naj kaže na ime z naslovom.
- SERVFAIL po prenosu je ponavadi star DS.
- Če samo Vi vidite star odgovor, gre za Vaš predpomnilnik ali datoteko hosts.
Kviz
Naloga
Naloga Z8.4: Prepoznavanje napak. Prejmete pet kratkih primerov z izhodom ukaza dig (v okolju tečaja). Za vsak primer izberite, za katero od desetih napak gre. Nato sledi pravo iskanje: z dig ali spletnim orodjem ugotovite, kateri zapis je napačen za dnssec-failed.org (status in kaj vrne +cd), ter ali ima wikipedia.org natanko en SPF zapis.
Za nadaljnje branje
Ti članki opisujejo rešitve v nadzornih ploščah WebOké; pri drugih ponudnikih se gumbi imenujejo drugače.
- Spletna stran ali e-pošta ne deluje po selitvi ali spremembi DNS: preverite svojo domeno
- Koliko časa traja sprememba nameserverja ali DNS-ja, in kaj storiti, če je ne vidite?
- Priročnik DirectAdmin 18.7: Moja domena še ne deluje po prenosu ali spremembi
- Priročnik DirectAdmin 18.9: Ne prejemam več e-pošte
- Priročnik DirectAdmin 5.4: Zapisi CNAME in pika na koncu
- Pošiljanje pošte prek PHP ne deluje, zapisi MX kažejo drugam
- Uporaba lastnih ali zunanjih imenskih strežnikov (nameserver, npr. Cloudflare) za Vašo domeno