i en idealisk värld, DNS skulle vara som en av dem som-sett-på-TV rotisserie ugnar – Ställ in den och glömma det. Internet är dock en dynamiskt föränderlig plats och det som kan vara relevant i ett ögonblick kanske inte är nästa.
för att klara detta utformades DNS med en mekanism för att uppdatera poster och se till att användarna alltid fick det mest relevanta svaret när de begärde det.
grunderna
tid att leva, eller TTL för kort, är den typ av utgångsdatum som sätts på en DNS-post., Den TTL tjänar till att berätta rekursiv server eller lokal resolver hur länge det ska hålla nämnda post i sin cache. Ju längre TTL, ju längre resolver håller den informationen i sin cache. Ju kortare TTL, desto kortare tid resolver innehar denna information i sin cache.
till exempel har vi example.com. – herr talman! Example.com har en a-post vid toppen av zonen för att peka oss till en server. Med en TTL på 3600 sekunder, eller 1 timme, betyder det att som en rekursiv server lär sig om example.com, det kommer att lagra den informationen om A-posten på example.com i en timme., Alla andra som använder samma resolver kommer att få samma svar, och på den auktoritativa sidan kommer det inte att finnas någon fråga till servern om inte TTL löper ut.
bästa praxis
TTLs är inget att ta lätt på – de kan direkt påverka mängden frågevolym som kan hänföras till din auktoritativa tjänst, och om du snabbt behöver ändra posten kan det leda till längre än förväntad förändringsutbredning till alla användare.,
för poster som utnyttjar ett slags Avancerat trafikstyrningsscenario, som ns1: s filterkedja, är det bäst att hålla TTL så kort som möjligt. På så sätt, när en ändring antas av systemet, får användare i den andra änden som begär namnet den senaste informationen. Det är värt att notera att de flesta rekursiva servrar faktiskt inte förstår en TTL kortare än 30 sekunder – medan vi inte kommer att stoppa dig från att gå lägre än det, kan resultaten inte vara gynnsamma på lång sikt.,
För poster som sällan ändras, till exempel TXT eller MX-poster är det bäst att hålla dem någonstans mellan en timme (3600s) och en dag (86400s). När det är dags att anta ändringar med avseende på dessa typer av poster, kan det vara upp till dig att ändra TTL ner till ett kortare intervall innan du antar några ändringar för att säkerställa att ändringarna sprids snabbt.
SOA TTLs
högst upp i varje DNS-zon, i början av myndigheten (SOA), finns det fem TTL-värden som tjänar ett högre syfte i DNS.
SOA TTL – intervallet vid vilket SOA-posten själv uppdateras.,
uppdatera TTL – intervallet vid vilket sekundära servrar (sekundär DNS) är inställda för att uppdatera den primära zonfilen från den primära servern.
försök igen TTL – den hastighet med vilken en sekundär server kommer att försöka uppdatera den primära zonfilen om den ursprungliga uppdateringen misslyckades.
Expiry TTL – om uppdatering och försök misslyckas upprepade gånger, är detta den tidsperiod efter vilken den primära bör anses borta och inte längre auktoritativ för den givna zonen.,
NX TTL – om begäran av domänen resulterar i en obefintlig fråga (NXDOMAIN), är detta den tid som rekursorn respekterar för att returnera NXDOMAIN-svaret.
det rekommenderas att inte ändra dessa TTLs om du inte har ett mycket specifikt behov av att göra det, vilket ofta är ett mycket sällsynt fall.