Modulis 6 · 6.2
"Propagācija": kāpēc viens to jau redz, bet otrs vēl ne
Modulis 6: Laiks, kešatmiņa un domēna pārsūtīšana · Lasīšanas laiks: 8 minūtes
Mērķis: Pēc šīs nodarbības Jūs varēsiet izskaidrot, kāpēc DNS izmaiņas nav visur redzamas vienlaikus, novērtēt, cik ilgi tas aizņem laiku, un atrisināt problēmu, ja tikai Jūs vēl redzat veco situāciju.
Pamatjēdzieni: "propagācija", kešatmiņa, negatīvā kešatmiņa (NXDOMAIN), SOA minimums, delegācijas TTL, vārdu servera maiņa, kešatmiņas tīrīšana
Pārpratums vienā vārdā
Jūs izmainījāt ierakstu. Jūsu kolēģis jau redz jauno vietni, bet Jūs joprojām veco. Internetā par to lasāms: "pagaidiet, DNS vēl jāpropagē." Vārds propagācija (izplatīšanās) rada iespaidu, ka Jūsu izmaiņas kā vilnis izplatās pa internetu, no servera uz serveri.
Tā tas nestrādā. Jūsu izmaiņas uzreiz ir redzamas Jūsu domēna autoritatīvajos vārdu serveros (vai dažu minūšu laikā, ja Jūsu DNS pakalpojuma sniedzējs sinhronizē vairākus vārdu serverus). Nekas netiek izsūtīts. Tas, ko Jūs redzat, ir kešatmiņas derīguma termiņa beigas: katrs rezolveris sniedz veco atbildi, līdz tā kešatmiņā esošais TTL beidzas (nodarbība 6.1). Tā kā katrs rezolveris sāka skaitīt citā brīdī, viens izmaiņas redz ātrāk nekā otrs.
Tātad "propagācija" patiesībā nozīmē: gaidīt, līdz visas kešatmiņas ir iztukšojušās. Šī izpratne Jums palīdzēs, jo tagad Jūs precīzi zināt, ko gaidāt un cik ilgi tas maksimāli var ilgt.
Cik ilgi tas ilgst?
Tas ir atkarīgs no tā, ko Jūs maināt.
| Ko Jūs mainiet | Ko Jūs gaidiet? | Parasti |
|---|---|---|
| Esošs ieraksts (A, MX, TXT ...) | Vecā ieraksta TTL | TTL robežās, bieži vien stundas laikā |
| Jauns ieraksts, kura iepriekš nebija | Nekas, ja vien kāds jau iepriekš nav pieprasījis šo nosaukumu (negatīvā kešatmiņa) | Uzreiz līdz dažas minūtes |
| Jūsu domēna vārdu serveri | NS ierakstu TTL pie reģistra | Dažas stundas līdz divas dienas |
Esoši ieraksti
Šeit viss ir vienkārši: vecais TTL ir maksimums. Ja ierakstam bija TTL 3600, tad visi jauno atbildi redzēs vēlākais vienu stundu pēc Jūsu izmaiņas. Ja kāds pēc vairāk nekā stundas joprojām redz veco, problēma ir kaut kur citur (skatīt tālāk).
Jauni ieraksti un negatīvā kešatmiņa
Jauns ieraksts parasti darbojas uzreiz, izņemot gadījumu, kad kāds šo nosaukumu jau pieprasīja, kad tas vēl nepastāvēja. Rezolveris tad saņēma atbildi NXDOMAIN ("šis nosaukums nepastāv") vai "šis nosaukums pastāv, bet tam nav šāda tipa ieraksta". Arī šis "nē" tiek atcerēts. To sauc par negatīvo kešatmiņu.
Cik ilgi "nē" tiek saglabāts, nav norādīts ierakstā, kas nepastāv. Tas izriet no zonas SOA ieraksta: saskaņā ar RFC 2308 tas ir mazākais no diviem skaitļiem, SOA ieraksta paša TTL un SOA ieraksta pēdējā lauka ("minimums"). Piemērs:
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2026110701 ; sērijas numurs
14400 ; atjaunošana (refresh)
3600 ; atkārtots mēģinājums (retry)
1209600 ; derīguma beigas (expire)
300 ) ; minimumsŠeit "nē" tiek atcerēts maksimāli 300 sekundes (mazākais no 3600 un 300). Dažās zonās tā var būt stunda vai vairāk.
Tāpēc zelta likums: neatveriet jaunu apakšdomēnu savā pārlūkā, pirms neesat to izveidojis. Jūsu dators un Jūsu rezolveris tad atcerēsies, ka tas nepastāv, un Jūs būsiet vienīgais, kam būs jāgaida.
Vārdu serveru maiņa
Mainot vārdu serverus, Jūs gaidāt kaut ko citu: NS ierakstus pie Jūsu paplašinājuma reģistra. Šie ieraksti rezolveriem norāda, kur atrodas Jūsu domēna vārdu serveri (nodarbība 2.1), un arī tie tiek atcerēti. Katrs reģistrs izvēlas šim nolūkam savu TTL. Mērīts 2026. gada novembrī:
| Paplašinājums | NS ierakstu TTL pie reģistra |
|---|---|
| .nl | 3600 sekundes (1 stunda) |
| .org | 3600 sekundes (1 stunda) |
| .com | 172800 sekundes (2 dienas) |
Papildus tam reģistrs dažkārt Jūsu izmaiņas uzreiz nepublicē, un Jūsu iepriekšējā pakalpojuma sniedzēja vārdu serveri šajā laikā bieži vien joprojām atbild ar veco zonu. Tāpēc, mainot vārdu serverus, rēķinieties ar dažām stundām, bet .com gadījumā ar maksimāli divām dienām. Pārliecinieties, ka abiem pakalpojuma sniedzējiem maiņas laikā ir vienādi, pareizi ieraksti (nodarbība 6.3).
Vai tikai Jūs vien joprojām redzat veco?
Vai tiešsaistes pārbaudes rīks jau gandrīz visiem rezolveriem rāda jauno atbildi, bet Jums ne? Tad vecā atbilde atrodas kaut kur Jūsu tuvumā. Izejiet cauri šiem soļiem, no ātrākā uz rūpīgāko:
- Privātais logs vai cits pārlūks. Jūsu pārlūks saglabā DNS atbildes un lapas.
- Tālrunis izmantojot 4G vai 5G, ar izslēgtu wifi. Tad izmantojat sava mobilā operatora rezolveri, nevis mājas tīkla rezolveri.
Datora kešatmiņas tīrīšana.
- Windows (Command Prompt):
ipconfig /flushdns - macOS (Terminal):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux ar systemd-resolved:
resolvectl flush-caches
- Windows (Command Prompt):
- Maršrutētāja restartēšana. Daudzi maršrutētāji darbojas kā nelieli rezolveri ar savu kešatmiņu.
- Hosts faila pārbaude. Vai iepriekš testējāt jaunu serveri, ievietojot adresi hosts failā (
C:\Windows\System32\drivers\etc\hostsvai/etc/hosts)? Šī rinda ir prioritārāka par DNS. Izdzēsiet to. Tas bieži tiek aizmirsts. - Pārbaude tieši pie avota. Pieprasiet ierakstu no autoritatīvā vārdu servera (
dig A example.com @ns1.hosting.example). Ja arī tur ir redzama vecā atbilde, tad izmaiņas nav pareizi saglabātas vai esat tās veikuši nepareizā vietā.
Vai pēc gaidīšanas laika joprojām nekas?
Ja TTL jau sen ir beidzies un arī tiešsaistes rīki rāda veco atbildi, gaidīšanai vairs nav jēgas. Tad notiek kaut kas cits. Trīs biežākie cēloņi:
- Izmainīts nepareizā vietā. Jūsu domēns izmanto cita pakalpojuma sniedzēja vārdu serverus (piemēram, Cloudflare vai vietņu veidotāja), bet Jūs mainījāt ierakstus pie sava hostinga pakalpojuma sniedzēja. Pārbaudiet, kādi vārdu serveri ir Jūsu domēnam (nodarbība 2.1), un veiciet izmaiņas tur.
- Drukas kļūda vai trūkstošs punkts.
mail.example.combez punkta daudzos vadības paneļos kļūst parmail.example.com.example.com(nodarbība 2.2). - Vārdu serveri savā starpā nav vienisprātis. Domēnam ir vismaz divi vārdu serveri. Ja tie pareizi nesinhronizējas, viens sniedz jauno, bet otrs veco atbildi. Salīdziniet SOA sērijas numuru katrā vārdu serverī: tam jābūt vienādam.
dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.examplePraksē: kā tas izskatās vadības panelī
Ja vēlaties redzēt, ko atbild rezolveri dažādās pasaules vietās, izmantojiet tiešsaistes DNS pārbaudes rīku, kas pieprasa rezolveri katrā valstī (piemēram, dnschecker.org). Piemēra panelī Mans WebOké kartiņa Domain / Email pārbauda Jūsu domēna vārdu serverus un ierakstus pie autoritatīvajiem vārdu serveriem, un DNS diagnostika salīdzina vārdu serveru sērijas numurus. Citiem pakalpojumu sniedzējiem bieži ir līdzīga pārbaude savā panelī; ja ne, tad dig un tiešsaistes rīki no nodarbības 8.3 sniegs to pašu ainu.
Kopsavilkums
- Nekas netiek "izplatīts": Jūs gaidāt, līdz kešatmiņas zaudē derīgumu.
- Izmainīts ieraksts vēlākais ir redzams visur pēc vecā TTL; jauns ieraksts parasti ir redzams uzreiz, izņemot gadījumu, kad kāds nosaukumu jau iepriekš pieprasīja (negatīvā kešatmiņa, ko nosaka SOA ieraksts).
- Vārdu serveru maiņa ir atkarīga no TTL pie reģistra: .nl gadījumā stunda, .com gadījumā divas dienas.
- Vai tikai Jūs vien redzat veco? Privātais logs, 4G, kešatmiņas tīrīšana, maršrutētāja restartēšana un hosts faila pārbaude.
- Joprojām vecais autoritatīvajā vārdu serverī? Tad gaidīšanai nav jēgas: meklējiet kļūdu.
Tests
Uzdevums
Uzdevums Z6.2: Delegācijas TTL un negatīvā kešatmiņa. Divi jautājumi, uz abiem atbilde atrodama ar dig vai tiešsaistes dig rīku:
- Cik sekundes rezolveri saskaņā ar .com reģistru atceras
google.comvārdu serverus? Pieprasiet to .com serverī:dig NS google.com @a.gtld-servers.netun apskatiet TTL AUTHORITY sadaļā. - Cik sekundes rezolveris atceras, ka nosaukums zem
sidn.nl(SIDN ir Nīderlandes .nl domēna reģistrs) nepastāv? Pieprasietsidn.nlSOA ierakstu nons1.sidn.nlun piemērojiet šajā nodarbībā izklāstīto likumu (mazākais no SOA TTL un SOA minimuma).
Papildu lasāmviela
Šajos rakstos aprakstītie soļi attiecas uz WebOké vadības paneļiem; citos paneļos tas darbojas līdzīgi.
- Cik ilgi ilgst nameserver vai DNS izmaiņas un kas jādara, ja Jūs tās nesaskatāt?
- Vietne vai e-pasts nedarbojas pēc pārvietošanas vai DNS izmaiņām: pārbaudiet savu domēnu
- DirectAdmin rokasgrāmata 5.11: Kad izmaiņas sāk darboties? Gaidīšanas laiks un TTL
- Apakšdomēna izveide un kas darāms, ja tas nedarbojas
- Kā pārbaudīt domēnu, pirms tas ir pārnests? (localhost)
- WebOké rokasgrāmata 5.17: Domēna un e-pasta veselība: pārbaude un novēršana
