i en ideel verden ville DNS være som en af dem, som set-på-TV rotisserie ovne-sæt den og glem det. Internettet er dog et dynamisk skiftende sted, og hvad der kan være relevant i det ene øjeblik er muligvis ikke det næste.
for at klare dette blev DNS designet med en mekanisme til at opdatere poster og sikre, at brugerne altid fik det mest relevante svar, da de anmodede om det.
det grundlæggende
tid til at leve, eller TTL for kort, er den slags udløbsdato, der sættes på en DNS-post., TTL tjener til at fortælle den rekursive server eller lokale resolver, hvor længe den skal holde posten i sin cache. Jo længere TTL, jo længere resolver holder disse oplysninger i sin cache. Jo kortere TTL, jo kortere tid resolver holder disse oplysninger i sin cache.
For eksempel har vi example.com. Example.com har en a-record på toppen af zoneonen for at pege os til en server. Med en TTL på 3600 sekunder, eller 1 time, det betyder, at som en rekursiv server lærer om example.com det vil gemme, at oplysninger om A-record på example.com for en time., Enhver anden, der bruger den samme resolver, får det samme Svar, og på den autoritative side vil der ikke være nogen forespørgsel til serveren, medmindre TTL løber tør.
bedste praksis
TTL ‘ er er intet at tage let på – de kan direkte påvirke mængden af forespørgselsvolumen, der kan henføres til din autoritative service, og i tilfælde af at du hurtigt skal ændre posten, kan det resultere i længere end forventet ændringsformering til alle brugere.,
For poster, der udnytter et slags avanceret trafikstyringsscenarie, såsom NS1S filterkæde, er det bedst at holde TTL så kort som muligt. Denne måde, når en ændring er vedtaget af systemet, brugere på den anden ende anmoder om navnet får de seneste oplysninger. Det er værd at bemærke, at de fleste rekursive servere faktisk ikke forstår en TTL kortere end 30 sekunder – selvom vi ikke forhindrer dig i at gå lavere end det, er resultaterne muligvis ikke gunstige i det lange løb.,
For poster, der sjældent ændrer sig, såsom T .t-eller m. – poster, er det bedst at opbevare dem et sted mellem en time (3600s) og en dag (86400s). Når det kommer tid til at vedtage ændringer med hensyn til disse typer poster, kan det være nødvendigt for dig at ændre TTL ned til et kortere interval, før du vedtager ændringer for at sikre, at ændringerne formeres hurtigt.
SOA TTLs
øverst i hver DNS-zoneone, i starten af Authority (SOA), er der fem TTL-værdier, der tjener et højere formål i DNS.
SOA ttl – det interval, hvor selve SOA-posten opdateres.,
Opdater TTL – det interval, hvor sekundære servere (sekundær DNS) er indstillet til at opdatere den primære zoneonefil fra den primære server.
prøv igen TTL – den hastighed, hvormed en sekundær server vil prøve igen for at opdatere den primære fileonefil, hvis den oprindelige opdatering mislykkedes.
udløb TTL – hvis opdatering og forsøg igen mislykkes gentagne gange, er dette den tidsperiode, hvorefter den primære skal betragtes som væk og ikke længere autoritativ for den givne zoneone.,n.ttl – i tilfælde af at anmodning om domænet resulterer i en ikke-eksisterende forespørgsel (N .domain), er dette den tid, der respekteres af recursoren for at returnere n .domain-svaret.
det anbefales ikke at ændre disse TTL ‘ er, medmindre du har et meget specifikt behov for det, hvilket ofte er et meget sjældent tilfælde.