Kako TTL utiče na promenu DNS podešavanja i zašto se promene ne vide odmah

Zamislite da ste prebacili sajt na novi server. Promenili ste IP adresu u DNS podešavanjima, sačuvali izmene i očekujete da domen odmah počne da otvara sajt sa nove lokacije.

Na vašem računaru sve radi kako treba. Kolega, međutim, i dalje vidi staru verziju sajta. Kada domen otvorite preko mobilnog interneta, dobijate grešku, dok alat za proveru DNS-a na jednom mestu prikazuje novu IP adresu, a na drugom staru.

Prva pomisao može da bude da promena nije pravilno sačuvana. U većini slučajeva zapis je, međutim, već promenjen, ali različiti uređaji i DNS resolveri još ne koriste isti podatak. Neki su već preuzeli novu vrednost, dok drugi u svom kešu i dalje čuvaju staru. Koliko dugo će stari odgovor ostati u upotrebi zavisi pre svega od TTL vrednosti koja je bila podešena pre nego što ste napravili promenu.

Šta se dešava kada unesete domen u browser

Kada u browser unesete naziv domena, računar najpre mora da sazna na kojoj IP adresi se nalazi server tog sajta. Taj podatak dobija preko DNS sistema. Uređaj najčešće ne šalje upit direktno autoritativnom DNS serveru domena. Umesto toga, obraća se DNS resolveru koji može da pripada vašem internet provajderu, kompanijskoj mreži ili nekom javnom servisu, kao što su Google Public DNS ili Cloudflare DNS.

Ukoliko resolver već ima sačuvan odgovor, vratiće ga iz svog keša. Tek kada tog odgovora nema ili kada mu istekne vreme važenja, resolver ponovo traži podatak od autoritativnog DNS servera. Na taj način svaki zahtev ne mora ponovo da prolazi kroz ceo DNS sistem. Sajtovi se brže otvaraju, autoritativni serveri dobijaju manje upita, a DNS infrastruktura radi efikasnije. Keširanje, međutim, ima i drugu stranu. Kada promenite DNS zapis, prethodni odgovor ne nestaje istog trenutka iz svih keševa.

TTL određuje koliko dugo DNS odgovor može da se čuva

TTL je skraćenica od Time to Live. Vrednost se izražava u sekundama i govori DNS resolveru koliko dugo može da koristi sačuvan odgovor pre nego što mora ponovo da ga zatraži. Ako A zapis domena ima TTL od 300 sekundi, resolver može da ga čuva pet minuta. TTL od 3.600 sekundi znači jedan sat, dok vrednost od 86.400 sekundi odgovara periodu od 24 sata.

To, međutim, ne znači da će svaki korisnik čekati tačno onoliko koliko piše u TTL-u. Resolver koji ranije nije tražio podatke za taj domen neće imati staru vrednost u kešu i može odmah da dobije novu IP adresu, dok resolver koji je stari odgovor sačuvao neposredno pre promene može da ga koristi gotovo do isteka celog TTL perioda. Zbog toga jedan korisnik može odmah da vidi novu verziju sajta, dok drugi još neko vreme završava na starom serveru.

TTL, dakle, ne određuje trenutak u kojem promena postaje aktivna na autoritativnom DNS serveru. On određuje koliko dugo drugi DNS serveri mogu da koriste podatak koji su ranije sačuvali. Cloudflare dokumentacija o TTL-u upravo zbog toga ovu vrednost povezuje sa vremenom koje je potrebno da promena DNS zapisa postane vidljiva korisnicima.

DNS propagacija nije jedno centralno ažuriranje

Kada kažemo da je promena DNS-a još u propagaciji, može da zvuči kao da novi podatak putuje od jednog servera do drugog dok ne stigne do celog interneta. U praksi se uglavnom ne dešava tako. Autoritativni DNS server već može da ima novi zapis, dok veliki broj resolvera u svom kešu i dalje čuva prethodni odgovor. Svaki od njih će novu vrednost zatražiti tek kada odgovor koji već ima prestane da važi.

Zamislite da je više ljudi zapisalo adresu iste firme u svoje imenike. Ukoliko firma promeni adresu u zvaničnom registru, podatak se neće automatski promeniti u svakom imeniku. Neko će novu adresu proveriti odmah, dok će neko drugi to uraditi tek kada mu sledeći put bude potrebna. Na sličan način rade i DNS resolveri. Pošto nisu svi prethodni odgovor dobili u istom trenutku, ni njihov TTL ne ističe istovremeno. Zbog toga različiti korisnici neko vreme mogu da dobijaju različite rezultate, iako je DNS podešen ispravno.

Važan je TTL koji je važio pre promene

Jedna od najčešćih grešaka jeste da TTL smanjite tek nakon što promenite DNS zapis. Recimo da A zapis trenutno pokazuje na stari server i da ima TTL od 86.400 sekundi, odnosno 24 sata. Ako je neki resolver taj odgovor sačuvao nekoliko minuta pre nego što ste promenili IP adresu, zajedno sa njim je dobio i informaciju da može da ga koristi naredna 24 sata.

Ukoliko nakon promene TTL smanjite na 300 sekundi, taj resolver za novu vrednost još ne zna. Nastaviće da koristi stari odgovor sve dok ne istekne TTL koji je dobio prilikom prethodnog upita. Tek tada će ponovo zatražiti DNS zapis i dobiti novu IP adresu zajedno sa kraćim TTL-om.

Zbog toga smanjivanje TTL-a ima smisla samo ako ga uradite unapred. Ukoliko je trenutni TTL 24 sata, smanjite ga najmanje toliko vremena pre planirane migracije. Na taj način resolveri će imati dovoljno vremena da preuzmu novu, kraću vrednost. Tek nakon toga promenite IP adresu. Resolveri koji su u međuvremenu dobili TTL od 300 sekundi tada će stari odgovor moći da čuvaju najviše nekoliko minuta. AWS u svojoj dokumentaciji takođe naglašava da naknadno smanjivanje TTL-a ne menja vreme važenja odgovora koji se već nalaze u kešu.

Kraći TTL ne znači da je uvek bolji

Kratak TTL je veoma koristan kada planirate promenu. Omogućava da korisnici brže dobiju novu IP adresu, ali i da se u slučaju problema lakše vratite na prethodnu konfiguraciju. To ipak ne znači da bi svaki DNS zapis trebalo trajno da ima TTL od svega nekoliko minuta.

Što je TTL kraći, resolveri češće moraju ponovo da traže podatke od autoritativnih DNS servera. Time se povećava broj DNS upita i smanjuje korist od keširanja. Kod servisa koji naplaćuju DNS upite to može da utiče i na troškove.

Duži TTL ima više smisla za zapise koji se retko menjaju. Podatak duže ostaje u kešu, upiti se brže rešavaju, a sistem manje zavisi od toga da autoritativni server u svakom trenutku bude dostupan. Problem nastaje tek kada takav zapis morate da promenite, jer stara vrednost može duže da ostane u upotrebi.

Tokom migracije često se koristi TTL od 300 sekundi. Vrednost od 3.600 sekundi može da bude sasvim razumna za zapise koji se povremeno menjaju, dok se TTL od 12 ili 24 sata češće koristi za stabilne zapise. To nisu univerzalna pravila. Odgovarajuća vrednost zavisi od toga koliko često menjate zapis, koliko brzo morate da reagujete ako dođe do problema i koliko vam je važno da smanjite broj DNS upita.

Kada se migracija završi i potvrdite da sve radi kako treba, TTL možete da vratite na uobičajenu vrednost.

Promena A zapisa i promena nameservera na domenu nisu isto

Kada sajt prebacujete na novi server, možete da promenite samo A zapis domena ili kompletne nameservere. Ukoliko menjate A zapis, autoritativni DNS sistem ostaje isti. Menja se samo IP adresa na koju domen pokazuje. U tom slučaju vreme tokom kojeg će deo korisnika i dalje dobijati stari odgovor pre svega zavisi od TTL-a tog zapisa.

Kod promene nameservera situacija je nešto drugačija. Tada menjate mesto na kojem se nalazi autoritativna DNS zona domena. Resolveri moraju da saznaju da domen više ne koristi stare već nove nameservere, a i taj podatak može da bude sačuvan u kešu. Zbog toga promena nameservera može da traje duže od promene jednog A ili CNAME zapisa.

AWS navodi da, zbog načina na koji se NS podaci keširaju, može da bude potrebno između 24 i 48 sati da promena postane vidljiva svim resolverima.

To ne znači da domen tokom tog perioda mora da prestane da radi. Ukoliko se na starim i novim nameserverima nalazi ista DNS zona, korisnik će dobiti isti odgovor bez obzira na to koji sistem njegov resolver trenutno koristi.

Problem može da nastane ako pre promene nameservera ne prenesete sve DNS zapise. Sajt će možda pravilno pokazivati na novi server, dok će MX zapisi za email, TXT zapisi za SPF, DKIM i DMARC ili neki servisni poddomen ostati na starim nameserverima. Na prvi pogled će izgledati da domen radi, ali email ili neki drugi povezani servis može da prestane da funkcioniše. Zato novu DNS zonu treba kompletno pripremiti pre nego što promenite nameservere domena.

Različiti DNS zapisi mogu da naprave različite probleme

TTL postoji kod različitih vrsta DNS zapisa, ali posledice njihove promene nisu iste. Kod A i AAAA zapisa promena utiče na adresu servera na kojem se nalazi sajt ili neki drugi servis. Ukoliko deo resolvera ima staru, a deo novu vrednost, korisnici mogu privremeno da završavaju na različitim serverima.

Posebno obratite pažnju ako domen istovremeno ima A zapis za IPv4 i AAAA zapis za IPv6. Ukoliko promenite samo A zapis, korisnici čija mreža daje prednost IPv6 vezi mogu i dalje da budu poslati na server koji je naveden u starom AAAA zapisu.

Kod MX zapisa promena određuje na koje servere treba da stiže email. Tokom prelaznog perioda neki pošiljaoci mogu da koriste staru, a neki novu konfiguraciju. Zbog toga stari email server ne bi trebalo odmah da isključite, naročito ako postoji mogućnost da još prima poruke za domen.

CNAME zapis povezuje jedan naziv domena sa drugim. Pošto resolver prati tu vezu, u procesu mogu da učestvuju zapisi sa različitim TTL vrednostima. Zbog toga promena jednog dela tog lanca ne mora kod svih korisnika da postane vidljiva u isto vreme.

TXT zapisi se često koriste za potvrdu vlasništva nad domenom i podešavanje zaštite emaila. Pored DNS keširanja, servis koji proverava TXT zapis može da ima i sopstveni raspored provere. Zato pravilno dodat zapis ne mora istog trenutka da se pojavi kao potvrđen u administraciji tog servisa.

I zapis koji ranije nije postojao može da bude keširan

Kada govorimo o TTL-u, najčešće mislimo na postojeći DNS zapis čija se vrednost menja. DNS, međutim, može da sačuva i informaciju da određeni zapis ne postoji.

Recimo da pokušate da otvorite staging.mojdomen.rs pre nego što ste napravili DNS zapis za taj poddomen. Resolver može da dobije odgovor da takav naziv ne postoji, odnosno NXDOMAIN, i da taj odgovor sačuva u takozvanom negativnom kešu.

Ukoliko nekoliko minuta kasnije napravite zapis, isti resolver još neko vreme može da vraća informaciju da domen ne postoji. TTL novog zapisa u tom trenutku nije presudan, jer resolver još nije ni zatražio novu vrednost. Čeka da istekne negativni odgovor koji već ima u svom kešu.

Koliko dugo takav odgovor može da se čuva određuju podaci iz SOA zapisa DNS zone. Zbog toga se dešava da novi poddomen preko jedne mreže odmah proradi, dok preko druge još neko vreme vraća grešku.

Kako da pripremite promenu DNS-a

Ukoliko unapred znate da ćete sajt prebaciti na drugi server, pripremu DNS-a treba da počnete pre same migracije. Prvo proverite trenutne TTL vrednosti. Ako su visoke, smanjite ih 24 do 48 sati pre planirane promene ili najmanje jedan puni period trenutnog TTL-a unapred.

Vrednost od 300 sekundi često je dovoljno kratka za samu migraciju. Ipak, nemojte očekivati da ona odmah počne da važi za resolvere koji već imaju sačuvan stari odgovor. Cloudflare preporučuje da se TTL smanji unapred, a ne neposredno prilikom prelaska.

Pre promene proverite i novu DNS zonu. Nije dovoljno da prekopirate samo zapis za glavni domen. Proverite:

• A i AAAA zapise za domen i poddomene
• CNAME zapise
• MX zapise za email
• TXT zapise za SPF, DKIM, DMARC i verifikaciju domena
• SRV zapise, ukoliko ih koriste email, telefonija ili neki drugi servis
• sve poddomene koje koriste aplikacije, API-ji ili interne usluge

Novi server takođe treba da bude potpuno spreman pre nego što DNS usmerite na njega. To znači da sajt i baza treba da budu preneti, SSL sertifikat podešen, aplikacija testirana, a server spreman da prihvata zahteve za odgovarajući domen.

Kada promenite DNS zapis, nemojte odmah da isključite stari server. Deo posetilaca još neko vreme može da dolazi na staru adresu, sve dok odgovori sačuvani u DNS keševima ne isteknu.

Kod sajtova na kojima se podaci menjaju u realnom vremenu situacija je nešto složenija. Ukoliko stari i novi server koriste različite baze podataka, deo korisnika može da radi na jednoj, a deo na drugoj verziji aplikacije. Zbog toga migracija webshopa, foruma ili poslovne aplikacije zahteva plan za sinhronizaciju podataka ili kratko kontrolisano održavanje, a ne samo promenu DNS zapisa.

Kako da proverite koji odgovor DNS trenutno vraća

To što se sajt otvara ne mora da znači da browser već koristi novu IP adresu. Stari i novi server mogu da prikazuju isti ili veoma sličan sadržaj. CDN može da vraća keširanu stranicu, dok lokalni hosts fajl može potpuno da zaobiđe javni DNS.

DNS odgovor možete da proverite alatima kao što su dig i nslookup.

Na primer:

dig mojdomen.rs A

dig @8.8.8.8 mojdomen.rs A

dig @1.1.1.1 mojdomen.rs A

Prva komanda koristi DNS resolver koji je podešen na vašem uređaju. Druga šalje upit Google Public DNS-u, dok treća proverava odgovor preko Cloudflare resolvera.

Ukoliko dobijete različite IP adrese, to ne znači automatski da je neki od servisa pogrešio. Moguće je da jedan resolver još koristi stari odgovor, dok je kod drugog TTL već istekao i nova vrednost je preuzeta.

Ako želite da proverite šta DNS zona trenutno zaista objavljuje, pošaljite upit direktno autoritativnom nameserveru domena. Na taj način zaobilazite keš rekurzivnih resolvera i proveravate trenutno stanje zapisa.

Online DNS checker takođe može da bude koristan jer prikazuje rezultate sa više različitih lokacija. Ipak, takav alat ne pokazuje stanje kod svakog internet provajdera i svakog resolvera na svetu. Prikazuje samo odgovore koje su u tom trenutku dobili serveri koji učestvuju u proveri.

Brisanje keša rešava samo jedan deo problema

Ukoliko vaš računar i dalje dobija staru IP adresu, možete da ispraznite lokalni DNS keš i ponovo pokrenete browser. To može da pomogne ako se stari odgovor nalazi na samom uređaju.

Neće, međutim, pomoći ako ga i dalje čuva DNS resolver vašeg internet provajdera. Kada uređaj ponovo pošalje upit, resolver može ponovo da vrati isti podatak iz svog keša.

Promena DNS servera na uređaju može da dovede do drugačijeg rezultata, jer se tada obraćate drugom resolveru. To ipak ne ubrzava propagaciju promene na ostatku interneta. Menja samo servis od kojeg vaš uređaj dobija DNS odgovor.

Google ima alat za osvežavanje svog javnog DNS keša, ali on ne utiče na Cloudflare, resolver vašeg provajdera ili interne DNS servere neke kompanije. Svaki od tih sistema ima sopstveni keš.

Važno je i da razlikujete DNS keš od keša sadržaja sajta. Čak i kada domen već pokazuje na novu IP adresu, browser, proxy ili CDN mogu da prikazuju staru verziju stranice. U tom slučaju brisanje browser keša može da pomogne, ali ne zato što ste promenili DNS, već zato što ste uklonili ranije sačuvan sadržaj sajta.

Najčešće greške tokom promene DNS-a

Jedna od najčešćih grešaka jeste da se TTL smanji u istom trenutku kada se promeni IP adresa. Resolveri koji već imaju sačuvanu staru vrednost ne znaju da ste TTL naknadno smanjili. Zbog toga mogu da koriste prethodni odgovor sve do isteka perioda koji su dobili ranije.

Problem može da nastane i ukoliko tokom migracije DNS zapis menjate više puta. Jedan resolver tada može da čuva prvu adresu, drugi privremenu, a treći poslednju postavljenu vrednost. Što više promena napravite pre nego što prethodni TTL periodi isteknu, teže ćete utvrditi na koji server korisnici u tom trenutku dolaze.

Još jedna česta greška je prerano gašenje starog servera. Čak i kada većina provera prikazuje novu IP adresu, deo korisnika još može da koristi stari odgovor. Ukoliko stari server više nije dostupan, oni će dobijati grešku sve dok se njihov DNS keš ne osveži.

Kod promene nameservera posebno obratite pažnju na to da kompletna DNS zona bude preneta. Sajt može da nastavi da radi, a da istovremeno prestanu da funkcionišu email, poddomeni ili servisi za potvrdu vlasništva nad domenom.

Proverite i da li zapis menjate u DNS zoni koju domen zaista koristi. Dešava se da korisnik izmeni zapis u panelu hosting naloga, dok su autoritativni nameserveri domena zapravo podešeni na drugi DNS servis. Promena tada jeste sačuvana, ali internet taj zapis uopšte ne koristi.

Kada čekanje više nije dovoljno

Ukoliko je prošao ceo period starog TTL-a, a domen i dalje pokazuje na pogrešnu adresu, problem verovatno nije samo u DNS propagaciji.

Tada proverite:

• da li su na domenu podešeni odgovarajući nameserveri
• da li je zapis promenjen u autoritativnoj DNS zoni
• da li postoji stari AAAA zapis
• da li glavni domen i www koriste različite zapise
• da li CNAME vodi do drugog zapisa koji još nije promenjen
• da li DNSSEC podešavanja odgovaraju trenutnom DNS provajderu
• da li lokalni hosts fajl preusmerava domen
• da li proxy ili CDN prikazuje sadržaj sa druge lokacije
• da li browser prikazuje ranije keširanu stranicu

DNS propagacija se često koristi kao objašnjenje za svaki problem koji se pojavi nakon promene DNS-a. Ipak, čekanje neće popraviti zapis unet u pogrešnu zonu, pogrešnu IP adresu, neusklađen DNSSEC ili zaboravljen AAAA zapis.

Zato najpre proverite šta objavljuju autoritativni nameserveri. Ukoliko je tamo podatak pogrešan, nema mnogo smisla da čekate da keševi isteknu. Kada se to dogodi, resolveri će samo preuzeti isti pogrešan odgovor.

Zaključak

Promena DNS zapisa traje svega nekoliko sekundi, ali to ne znači da će svi korisnici odmah dobiti novi odgovor. Prethodna IP adresa može još neko vreme da ostane sačuvana kod internet provajdera, javnih DNS resolvera, u lokalnoj mreži ili na samom uređaju. Koliko dugo će se koristiti zavisi pre svega od TTL vrednosti koja je važila pre promene.

Zbog toga TTL treba da smanjite unapred, a ne tek kada migracija počne. Ako je prethodna vrednost bila visoka, potrebno je da sačekate da ona istekne pre nego što promenite IP adresu.

Pre same promene pripremite novi server i proverite kompletnu DNS zonu. Stari server nemojte odmah da isključujete, jer deo korisnika još neko vreme može da dolazi na prethodnu adresu. Kod promene nameservera posebno proverite MX, TXT, CNAME, SRV i zapise svih poddomena kako zajedno sa sajtom ne biste prekinuli rad emaila ili nekog drugog servisa.

Ukoliko je stari TTL već istekao, a domen i dalje pokazuje na pogrešnu adresu, dalje čekanje verovatno neće rešiti problem. Tada proverite autoritativne nameservere, A i AAAA zapise, DNSSEC, CDN i samu konfiguraciju servera.

Dobro isplanirana DNS promena zato nije samo unošenje nove IP adrese. Potrebno je da unapred podesite TTL, pripremite novi server i DNS zonu i ostavite dovoljno vremena da se stari podaci povuku iz keševa. Ako sve to uradite pre migracije, znatno je manja mogućnost da deo korisnika vidi novi sajt, dok drugi i dalje pokušavaju da pristupe starom serveru.