Modulis 8 · 8.4
Biežāk pieļautās kļūdas
Modulis 8: Drošība un problēmu risināšana · Lasīšanas laiks: 10 minūtes
Mācību mērķis: Pēc šīs nodarbības Jūs atpazīsiet desmit biežāk pieļautās DNS kļūdas pēc to simptomiem un zināsiet, kā tās novērst.
Pamatjēdzieni: punkts beigās, divkārša domēna nosaukumā, izmaiņas nepareizā vietā, divi SPF ieraksti, CNAME uz pamata domēnu, aizmirsts AAAA, MX bez adreses, starpniekserveris (proxy) pasta priekšā, vecs DS pēc pārsūtīšanas, kešatmiņa
Kā izmantot šo nodarbību
Zemāk minētās kļūdas nav ņemtas no mācību grāmatas, bet gan no jautājumiem, ko hostinga uzņēmumi saņem katru nedēļu. Pie katras kļūdas redzēsiet: ko pamana lietotājs, kā to pierādīt ar vienu jautājumu, un kāds ir risinājums. Saskaroties ar problēmu, vienmēr sāciet ar tiem pašiem diviem jautājumiem: kādi vārdu serveri ir domēnam (dig +short NS example.com) un ko atbild autoritatīvais vārdu serveris (dig @<nameserver> <naam> <type>). Ar to Jūs atrisināsiet jau pusi gadījumu.
1. Aizmirsts punkts beigās
Simptoms: CNAME, MX vai NS ieraksts nedarbojas; pakalpojums paziņo "ieraksts nav atrasts".
Pierādīšana: dig +short CNAME shop.example.com atdod shops.platform.example.example.com.
Cēlonis: zonā nosaukums bez punkta beigās ir relatīvs: panelis pievieno aiz tā Jūsu paša domēnu (2.2. nodarbība).
Risinājums: rakstiet mērķa nosaukumu kā pilnu nosaukumu ar punktu (shops.platform.example.). Daži paneļi pievieno punktu paši; pēc saglabāšanas pārbaudiet, kas tiešām ir ierakstīts.
2. Domēna nosaukums divkārt nosaukumā
Simptoms: verifikācija vai DKIM pārbaude pie kāda pakalpojuma neizdodas, lai gan ieraksts "it kā ir ievietots".
Pierādīšana: dig +short TXT k2._domainkey.example.com neatdod neko, bet dig +short TXT k2._domainkey.example.com.example.com gan.
Cēlonis: pakalpojums norāda pilnu nosaukumu (k2._domainkey.example.com), un Jūsu panelis vēlreiz pievieno domēnu aiz tā.
Risinājums: nosaukuma laukā ievadiet tikai to daļu, kas ir pirms Jūsu domēna: k2._domainkey. Panelis parasti zem lauka parāda pilno nosaukumu: pārbaudiet to.
3. Izmaiņas nepareizā vietā
Simptoms: Jūs maināt ierakstu, bet nekas nemainās, pat pēc dienas.
Pierādīšana: dig +short NS example.com atdod cita uzņēmuma vārdu serverus nekā tos, kuros Jūs veicāt izmaiņas (piemēram, vietnes konstruktora vai Cloudflare).
Cēlonis: DNS nosaka tikai tas uzņēmums, kura vārdu serveri ir norādīti (2.1. nodarbība). Ieraksti citur neko neietekmē.
Risinājums: mainiet ierakstu pie tā uzņēmuma, kuram pieder vārdu serveri, vai atjaunojiet iepriekšējos vārdu serverus. Reāls piemērs: kāds iestatīja vārdu serverus uz vietnes konstruktora platformu vietnei, bet A ieraksts domēnam mail tur nebija izveidots. Rezultāts: pasta sūtīšana strādāja, saņemšana nē, jo MX norādīja uz mail.example.com, un šāds nosaukums vairs neeksistēja.
4. Divi SPF ieraksti
Simptoms: pasts biežāk nonāk surogātpastā vai tiek noraidīts kopš pievienots jauns pakalpojums.
Pierādīšana: dig +short TXT example.com atdod divas rindas, kas sākas ar v=spf1.
Cēlonis: jaunais pakalpojums teica "pievienojiet šo SPF ierakstu", un tas tika izdarīts burtiski. Ar diviem SPF ierakstiem SPF kļūst nederīgs (permerror, RFC 7208), kas ir sliktāk nekā vispār nebūt SPF ierakstam.
Risinājums: apvienojiet tos vienā ierakstā: v=spf1 a mx include:_spf.hosting.example include:spf.service.example ~all. Ievērojiet desmit uzmeklēšanas pieprasījumu robežu (4.3. nodarbība).
5. CNAME uz pamata domēnu
Simptoms: panelis noraida ierakstu, vai pēc saglabāšanas pasts vairs nedarbojas.
Pierādīšana: pakalpojums pieprasa "izveidojiet CNAME priekš @".
Cēlonis: CNAME nedrīkst atrasties kopā ar citiem ierakstiem, un pamata domēnā vienmēr ir SOA un NS ieraksti (bieži arī MX un TXT). Skatiet 3.2. nodarbību.
Risinājums: uz @ izmantojiet A ierakstu (un, ja nepieciešams, AAAA) ko norāda pakalpojums, un CNAME izmantojiet tikai domēnam www vai apakšdomēnam. Dažiem DNS pakalpojumu sniedzējiem šim gadījumam ir ALIAS vai "CNAME flattening" funkcija.
6. Aizmirsts AAAA pārsūtīšanas laikā
Simptoms: pēc pārsūtīšanas daļa apmeklētāju (bieži mobilajās ierīcēs) joprojām redz veco vietni, vai arī parādās sertifikāta kļūda.
Pierādīšana: dig +short A example.com atdod jauno adresi, bet dig +short AAAA example.com joprojām vecā servera adresi.
Cēlonis: ierīces ar IPv6 dod priekšroku AAAA ierakstam. Mainīts ir tikai A ieraksts.
Risinājums: atjauniniet arī AAAA ierakstu, vai dzēsiet to, ja jaunajam serverim nav IPv6. Reāls piemērs: pieslēdzot interneta veikala platformu, līdzās jaunajam A ierakstam bija jānoņem arī vecais AAAA ieraksts, citādi veikals daļai apmeklētāju palika nesasniedzams.
7. MX, kas norāda uz neko
Simptoms: Jūs nesaņemat pastu; sūtītāji saņem kļūdas paziņojumu.
Pierādīšana: dig +short MX example.com atdod 10 mail.example.com., bet dig +short A mail.example.com neatdod neko (NXDOMAIN).
Cēlonis: MX norāda uz kādu nosaukumu, un tam nosaukumam jābūt A vai AAAA ierakstam. Bieži A ieraksts priekš mail ir pazudis vārdu serveru pārsūtīšanas laikā. MX arī nedrīkst norādīt uz IP adresi vai uz CNAME (RFC 2181).
Risinājums: izveidojiet A ierakstu pasta servera nosaukumam, vai pavirziet MX uz nosaukumu, kuram ir adrese.
8. Pasts citur, bet vecais serveris domā, ka tam jāpiegādā pasts
Simptoms: pasts no ārpuses nokļūst pie Jūsu jaunā pakalpojumu sniedzēja pareizi, bet pasts no Jūsu vietnes (kontaktforma, interneta veikals) nekad nepienāk. Dažreiz saņemat 550 Unknown user.
Pierādīšana: MX norāda uz jauno pakalpojumu sniedzēju, bet tīmekļa serverī joprojām ir ieslēgta vietējā pasta piegāde.
Cēlonis: tā nav DNS kļūda, taču tā izskatās tāpat. Tīmekļa serveris, kas domā, ka tam pašam pieder pastkastes, neskatās uz MX ierakstu.
Risinājums: hostinga panelī izslēdziet vietējo piegādi (DirectAdmin: izslēdziet izvēles rūtiņu "Izmantot šo serveri manu e-pastu apstrādei"). Citiem paneļiem ir līdzīgs iestatījums, bieži "Remote mail exchanger" vai "e-pasts ārēji".
9. Starpniekserveris (proxy) ieslēgts pastam
Simptoms: pie DNS pakalpojumu sniedzēja ar starpniekservera funkciju (piemēram, oranžais mākonis pie Cloudflare) vietne darbojas, bet pasta programma nevar izveidot savienojumu, vai vietnes sertifikāts netiek atjaunots.
Pierādīšana: dig +short A mail.example.com atdod starpniekservera adresi, nevis Jūsu pasta servera adresi.
Cēlonis: tīmekļa starpniekserveris pārsūta tikai tīmekļa trafiku, nevis pastu.
Risinājums: izslēdziet starpniekserveri (pelēkais mākonis, "DNS only") domēnam mail un visiem nosaukumiem, ko izmanto Jūsu pasta programma. Sertifikātiem: uz laiku izslēdziet starpniekserveri, līdz sertifikāts ir izsniegts, vai izmantojiet pareizo SSL režīmu starpniekserverim.
10. Vecs DS pēc pārsūtīšanas
Simptoms: pēc vārdu serveru pārsūtīšanas Jūsu domēns daļai pasaules nav sasniedzams; citiem lietotājiem nav nekādu problēmu.
Pierādīšana: dig example.com @1.1.1.1 atdod SERVFAIL, bet dig +cd example.com @1.1.1.1 gan dod atbildi. DNSViz (https://dnsviz.net/, 8.1. nodarbība) iekrāso DS ierakstu sarkanā krāsā un zem tā parāda pelēku, punktotu atslēgu, kuras Jūsu zonā vairs nav. Zonemaster un Verisign DNSSEC Debugger ziņo par to pašu vārdiski.
Cēlonis: reģistrā joprojām ir vecā uzņēmuma DS ieraksts (8.1. nodarbība). Kļūdu uzrāda tikai validējošie rezolveri, tāpēc ne visi to pamana.
Risinājums: atjauniniet DS ar jaunā uzņēmuma atslēgu, vai noņemiet to un pēc tam no jauna ieslēdziet DNSSEC.
Un "kļūda", kas nav kļūda: kešatmiņa
Ļoti bieži viss ir kārtībā, bet Jūs tomēr redzat veco atbildi. To atpazīstat pēc tā, ka: dig @<nameserver> atdod jauno atbildi, tāpat arī tiešsaistes pārbaudes rīks citās valstīs, bet tikai Jūsu dators nē. Risinājums: privātais logs, tālrunis caur 4G/5G, vai kešatmiņas notīrīšana (8.2. nodarbība). Arī aizmirsta rinda datora hosts failā (no iepriekšējā testa pirms pārsūtīšanas) rada šādu ainu: izdzēsiet šo rindu.
Līdzīga kļūda: jauna nosaukuma pieprasīšana pirms tas vēl izveidots. Rezolveris tad atceras "neeksistē" (negatīvā kešatmiņa), un paiet ilgāks laiks, līdz jaunais nosaukums sāk darboties (6.2. nodarbība).
Praksē: kā tas izskatās panelī
Daudzi paneļi novērš daļu no šīm kļūdām. Mans WebOké, piemēram, brīdina, ja trūkst punkta beigās, un zem nosaukuma lauka parāda pilno nosaukumu; DirectAdmin noraida nederīgus ierakstus ar paziņojumu "Error Writing Records". Cloudflare un citiem pakalpojumu sniedzējiem ir līdzīgi brīdinājumi. Pirms lielākām izmaiņām izveidojiet savas zonas dublējumu vai eksportu, lai vienmēr varētu atgriezties atpakaļ.
Kopsavilkums
- Vienmēr sāciet ar: kādi ir vārdu serveri, un ko saka autoritatīvais vārdu serveris.
- Lielākā daļa kļūdu ir nosaukumā (punkts, divkāršs domēns) vai vietā (nepareizs uzņēmums).
- Viens SPF ieraksts, nevis CNAME uz @, AAAA pārceļot kopā ar A, MX uz nosaukumu ar adresi.
- SERVFAIL pēc pārsūtīšanas parasti nozīmē vecu DS ierakstu.
- Ja tikai Jūs redzat veco atbildi, vaina ir Jūsu kešatmiņā vai hosts failā.
Tests
Uzdevums
Uzdevums Z8.4: Kļūdu atpazīšana. Jūs saņemsiet piecus īsus gadījumus ar dig izvadi klāt (kursa vidē). Izvēlieties katram gadījumam, kura no desmit kļūdām tā ir. Pēc tam īsta izmeklēšana: ar dig vai tiešsaistes rīku noskaidrojiet, kurš ieraksts domēnam dnssec-failed.org ir nepareizs (statuss un ko atdod +cd), un vai wikipedia.org ir tieši viens SPF ieraksts.
Lasīt tālāk
Šie raksti apraksta risinājumus WebOké paneļos; citiem pakalpojumu sniedzējiem pogas var saukties citādi.
- Vietne vai e-pasts nedarbojas pēc pārvietošanas vai DNS izmaiņām: pārbaudiet savu domēnu
- Cik ilgi ilgst nameserver vai DNS izmaiņas un kas jādara, ja Jūs tās nesaskatāt?
- DirectAdmin rokasgrāmata 18.7: Mans domēns vēl nedarbojas pēc pārneses vai izmaiņām
- DirectAdmin rokasgrāmata 18.9: Es vairs nesaņemu e-pastu
- DirectAdmin rokasgrāmata 5.4: CNAME ieraksti un punkts beigās
- E-pastu nevar nosūtīt ar PHP, MX ieraksti norāda uz citu serveri
- Izmantot savus vai ārējus nameserverus (piemēram, Cloudflare) Jūsu domēnam