"Propageerumine": miks mõni näeb muudatust kohe, teine mitte

Moodul 6: Aeg, vahemälu ja ülekanne · Lugemisaeg: 8 minutit

Õpieesmärk: Pärast seda tundi oskad sa selgitada, miks DNS-muudatus pole kõikjal korraga nähtav, hinnata, kui kaua see aega võtab, ja lahendada probleemi, kui ainult sina näed veel vana seisu.

Põhimõisted: "propageerumine", vahemälu, negatiivne vahemälu (NXDOMAIN), SOA miinimum, delegatsiooni TTL, nimeserveri muutmine, vahemälu tühjendamine

Üks sõna, mis tekitab segadust

Oled kirje ära muutnud. Su kolleeg näeb juba uut veebisaiti, sina näed veel vana. Internetist võib siis lugeda: "oota veidi, DNS peab veel levima." Sõna propageerumine jätab mulje, nagu veereks su muudatus lainena üle interneti, serverilt serverile.

Nii see ei toimi. Su muudatus on kohe sinu domeeni autoriteetsetes nimeserverites olemas (või mõne minuti jooksul, kui su DNS-teenusepakkuja sünkroonib mitu nimeserverit). Midagi ei saadeta laiali. See, mida sa näed, on vahemälude aegumine: iga resolver annab vana vastuse, kuni tema vahemälus olev TTL saab otsa (tund 6.1). Kuna iga resolver alustas lugemist eri hetkel, näeb mõni muudatust varem kui teine.

"Propageerumine" tähendabki tegelikult seda: ootamist, kuni kõik vahemälud on tühjaks jooksnud. See arusaam aitab sind, sest nüüd tead täpselt, mida sa ootad ja kui kaua see maksimaalselt kestab.

Kui kaua see aega võtab?

See sõltub sellest, mida sa muudad.

Olemasolevad kirjed

Siin on asi lihtne: vana TTL on maksimum. Kui kirjel oli TTL 3600, näeb igaüks uut vastust hiljemalt tund aega pärast muudatust. Kui keegi näeb enam kui tunni pärast ikka veel vana, siis on probleem mujal (vt allpool).

Uued kirjed ja negatiivne vahemälu

Uus kirje töötab enamasti kohe, välja arvatud juhul, kui keegi küsis nime juba siis, kui see veel ei eksisteerinud. Resolver sai siis vastuseks NXDOMAIN ("seda nime ei ole olemas") või "see nimi on olemas, aga sellel ei ole seda tüüpi kirjet." Ka see "ei" jääb meelde. Seda nimetatakse negatiivseks vahemäluks.

Kui kaua "ei" meeles peetakse, ei ole kirjas kirjes, mida pole olemas. See tuleb tsooni SOA-kirjest: vastavalt RFC 2308-le on see väiksem kahest arvust, SOA-kirje enda TTL-ist ja SOA-kirje viimasest väljast ("miinimum"). Näide:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; serienummer
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Siin peetakse "ei" meeles maksimaalselt 300 sekundit (väiksem kahest, 3600 ja 300). Mõne tsooni puhul on see tund aega või rohkem.

Seepärast kuldreegel: ära ava uut alamdomeeni oma brauseris enne, kui oled selle loonud. Su arvuti ja resolver jätavad siis meelde, et seda ei ole olemas, ja just sina pead sellepärast ootama.

Nimeserverite muutmine

Nimeserveri vahetuse puhul ootad sa midagi muud: NS-kirjeid oma laiendi registri juures. Need kirjed ütlevad resolveritele, kus asuvad su domeeni nimeserverid (tund 2.1), ja ka neid peetakse meeles. Iga register valib selleks oma TTL-i. Mõõdetuna 2026. aasta novembris:

Lisaks juhtub, et register ei avalda su muudatust alati kohe, ja ka vana teenusepakkuja nimeserverid vastavad vahepeal sageli endiselt vana tsooniga. Arvesta seepärast nimeserveri vahetusel paari tunniga, .com puhul kuni kahe päevaga. Veendu seega, et mõlemal teenusepakkujal on vahetuse ajal samad, õiged kirjed (tund 6.3).

Kas näed ainult sina veel vana?

Kas mõni internetipõhine kontrollija näeb juba uut vastust peaaegu kõigi resolverite juures, aga sina mitte? Siis on vana vastus sinu lähedal vahemälus. Käi need sammud läbi, kiiremast põhjalikumani:

1. Privaatne aken või teine brauser. Su brauser jätab meelde DNS-vastuseid ja lehti.
2. Telefon 4G või 5G kaudu, WiFi väljas. Siis kasutad oma mobiilioperaatori resolverit, mitte koduvõrgu oma.

3. Arvuti vahemälu tühjendamine.

   • Windows (käsurida): ipconfig /flushdns
   • macOS (terminal): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux koos systemd-resolved teenusega: resolvectl flush-caches
4. Ruuteri taaskäivitamine. Paljud ruuterid toimivad väikese resolverina, millel on oma vahemälu.
5. Hosts-faili kontrollimine. Oled sa varem testinud uut serverit, pannes aadressi hosts-faili (C:\Windows\System32\drivers\etc\hosts või /etc/hosts)? See rida läheb DNS-ist ette. Eemalda see. Seda unustatakse sageli.
6. Vaata otse allikast. Küsi kirje päringuga autoriteetselt nimeserverilt (dig A example.com @ns1.hosting.example). Kui ka seal on veel vana vastus, siis ei ole muudatus õigesti salvestatud või tegid selle valesse kohta.

Kas ootamisajast hoolimata ikka mitte midagi?

Kui TTL on juba ammu möödas ja ka internetipõhised tööriistad näitavad vana vastust, ei ole ootamisest kasu. Siis on tegu millegi muuga. Kolm kõige levinumat põhjust:

• Muudetud vales kohas. Su domeen kasutab teise teenusepakkuja (näiteks Cloudflare või veebiehitaja) nimeservereid, ja sina muutsid kirjeid oma majutuspakkuja juures. Vaata, millised nimeserverid su domeenil on (tund 2.1) ja tee muudatus seal.
• Kirjaviga või puuduv punkt. mail.example.com ilma punktita muutub paljudes paneelides mail.example.com.example.com'iks (tund 2.2).
• Nimeserverid ei ole omavahel kooskõlas. Domeenil on vähemalt kaks nimeserverit. Kui need omavahel korralikult ei sünkrooni, annab üks uue ja teine vana vastuse. Võrdle SOA-kirje seerianumbrit igas nimeserveris: need peavad olema võrdsed.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

Praktikas: nii näeb see välja paneelis

Kui tahad näha, mida resolverid eri paigus maailmas vastavad, kasuta internetipõhist DNS-kontrollijat, mis küsib riikide kaupa resolverit (näiteks dnschecker.org). Näidispaneelis Minu WebOké kontrollib kaart Domain / Email terviseseisund su domeeni nimeservereid ja kirjeid autoriteetsete nimeserverite juures, ja DNS-diagnostika võrdleb nimeserverite seerianumbreid. Teistel teenusepakkujatel on sageli sarnane kontroll oma paneelis; kui mitte, siis annavad dig ja tunni 8.3 internetipõhised tööriistad sama pildi.

Kokkuvõte

• Midagi ei "levitata": sa ootad, kuni vahemälud aeguvad.
• Muudetud kirje on hiljemalt vana TTL möödudes kõikjal nähtav; uus kirje enamasti kohe, välja arvatud juhul, kui keegi küsis nime juba varem (negatiivne vahemälu, mille määrab SOA-kirje).
• Nimeserveri vahetus sõltub TTL-ist registri juures: .nl puhul tund aega, .com puhul kaks päeva.
• Kas näed ainult sina veel vana? Privaatne aken, 4G, vahemälu tühjendamine, ruuteri taaskäivitamine ja hosts-faili kontroll.
• Kas autoriteetse nimeserveri juures on ikka veel vana? Siis pole ootamisest kasu: otsi viga.

Test

Ülesanne

Ülesanne Z6.2: Delegatsiooni TTL ja negatiivne vahemälu. Kaks küsimust, mõlemale saab vastata dig abil või internetipõhise dig-tööriistaga:

1. Mitu sekundit peavad resolverid .com registri järgi meeles google.com nimeservereid? Küsi seda .com-serverilt: dig NS google.com @a.gtld-servers.net ja vaata TTL-i AUTHORITY-osas.
2. Mitu sekundit peab resolver meeles, et nimi sidn.nl all ei ole olemas? Küsi sidn.nl SOA-kirjet serverilt ns1.sidn.nl ja rakenda selle tunni reeglit (väiksem SOA TTL-ist ja SOA miinimumist).

Loe edasi

Nende artiklite sammud käivad WebOké paneelide kohta; teistes paneelides toimib see sarnaselt.

• Kui kaua kestab nameserveri või DNS-i muudatus ja mida teha, kui sa seda ei näe?
• Veebileht või e-post ei tööta pärast kolimist või DNS-muudatust: kontrolli oma domeeni
• DirectAdmin juhend 5.11: Millal hakkab muudatus kehtima? Ooteaeg ja TTL
• Alamdomeeni loomine ja mida teha, kui see ei tööta
• Kuidas testida oma domeeni enne, kui see on üle kantud? (localhost)
• WebOké juhend 5.17: Domeeni ja e-posti tervis: kontrollimine ja parandamine