Low DNS latency is a key factor for fast internet performance. To minimize it, it’s important to carefully select DNS servers and . But first, we should eliminate unnecessary queries.
This is why DNS was originally created as a highly cacheable protocol. Zone administrators set the time-to-live (TTL) for individual records, and resolvers use this information when storing records in memory to avoid unnecessary traffic.
Is caching effective? A couple of years ago, my small study showed that it is not perfect. Let’s take a look at the current situation.
To gather information, I patched to retain the TTL value for the response. It is defined as the minimum TTL of its records for each incoming query. This provides a good overview of the TTL distribution of real traffic and accounts for the popularity of individual queries. The patched version of the server ran for several hours.
The resulting dataset consists of 1,583,579 records (name, qtype, TTL, timestamp). Here is the overall distribution of TTL (the X-axis is TTL in seconds):
Excluding a slight bump at 86,400 (mainly for SOA records), it’s quite obvious that TTLs are in the low range. Let’s look closer:
Okay, TTLs over 1 hour are statistically insignificant. So let’s focus on the range of 0−3600:
Most TTLs range from 0 to 15 minutes:
The overwhelming majority are from 0 to 5 minutes:
This is not good.
The cumulative distribution makes the issue even more apparent:
In half of DNS responses, the TTL is 1 minute or less, and three-quarters have 5 minutes or less.
But wait, it’s actually even worse. This is the TTL from authoritative servers. However, client resolvers (e.g., routers, local caches) receive TTL from upstream resolvers, and it decreases every second.
Thus, a client can effectively use each record, on average, for half of the original TTL, after which it will send a new request.
Perhaps these very low TTLs only apply to unusual queries, not popular websites and APIs? Let’s take a look:
The X-axis is TTL, the Y-axis is query popularity.
Unfortunately, the most popular queries are also the worst cached.
Nærmer os:
Dom: det står virkelig skidt til. Det har været dårligt før, men nu er det kun blevet værre. DNS-caching er blevet næsten ubrugeligt. Da færre og færre bruger deres udbyders DNS-resolver (af god grund), bliver forsinkelsen mere mærkbar.
DNS-caching er kun blevet nyttigt for indhold, som ingen besøger.
Derudover skal du være opmærksom på, at software kan lav TTL.
Hvorfor er det sådan?
Hvorfor er der så lav TTL for DNS-poster?
- Forældede belastningsfordelere har stået tilbage med standardindstillinger.
- Der er myter om, at DNS-belastningsfordeling afhænger af TTL (det er ikke korrekt — siden Netscape Navigator vælger klienter tilfældigt en IP-adresse fra et sæt RR og prøver gennemsigtigt en anden, hvis de ikke kan oprette forbindelse)
- Administratorer ønsker at anvende ændringer med det samme, da det gør planlægningen lettere.
- DNS-serverens eller belastningsfordelerens administrators opgave er at implementere den konfiguration, som brugerne anmoder om, effektivt og ikke at fremskynde websteder og tjenester.
- Lav TTL giver fred i sindet.
- Folk sætter oprindeligt lav TTL for testning og glemmer at ændre dem senere.
Jeg har ikke inkluderet «failover» i listen, da det bliver mindre relevant. Hvis du skal omdirigere brugerne til et andet netværk kun for at vise en fejlside, når alt andet er gået galt, er det nok acceptabelt med en forsinkelse på mere end 1 minut.
Desuden betyder en minutters TTL, at hvis de autoritative DNS-servere er nede i mere end 1 minut, vil ingen kunne få adgang til afhængige tjenesteder. Og redundans hjælper ikke, hvis årsagen er en konfigurationsfejl eller et hack. På den anden side, med rimelige TTL vil mange klienter fortsætte med at bruge den tidligere konfiguration og aldrig bemærke noget.
De lave TTL er i høj grad skyld i tjenester som CDN og belastningsfordelere, især når de kombinerer CNAME med lav TTL og poster med tilsvarende lav (men uafhængig) TTL:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Hver gang en CNAME eller hvilken som helst af A-posterne udløber, skal der sendes en ny forespørgsel. Begge har en TTL på 30 sekunder, men de stemmer ikke overens. Den faktiske gennemsnitlige TTL vil være 15 sekunder.
Men vent! Det bliver værre. Nogle resolveres opførsel er meget dårlig i sådan en situation med to tilknyttede lave TTL'er.
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3-resolveren arbejder sandsynligvis på BIND. Hvis du fortsætter med at sende denne forespørgsel, vil der altid blive returneret en TTL på 1. Grundlæggende set. raw.githubusercontent.com bliver aldrig cachelagret.
Her er et andet eksempel på en sådan situation med et meget populært domæne:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Mindst tre CNAME-poster. Av. En har en anstændig TTL, men det er fuldstændig nytteløst. I andre CNAME'er er den oprindelige TTL 60 sekunder, men for domænerne akamai.net er den maksimale TTL 20 sekunder, og ingen af dem er i fase.
Hvad med domæner, der konstant spørger enheder fra Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Den samme problematik som med Firefox, og TTL vil i det meste af tiden sidde fast på 1 sekund, når der bruges en Level3-resolver.
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
For optegnelsen safebrowsing.googleapis.com er TTL-værdien 60 sekunder, ligesom for Facebooks domæner. Og igen, set fra klientens synspunkt, halveres disse værdier.
Hvad med at sætte en minimum TTL?
Ved at bruge navnet, forespørgselstypen, TTL og det først gemte tidsstempel, har jeg skrevet et script til at simulere 1,5 millioner forespørgsler, der går gennem en cache-resolver, for at vurdere omfanget af unødvendige forespørgsler, der sendes på grund af en udløbet cache-post.
47,4% af forespørgslerne blev lavet efter udløbet af den eksisterende post. Det er uforholdsmæssigt højt.
Hvilken indflydelse vil det have på caching, hvis der sættes en minimum TTL?
X-aksen viser de minimale TTL-værdier. Poster med oprindelige TTL værdier over dette tal påvirkes ikke.
Y-aksen viser procentdelen af anmodninger fra klienter, der allerede har en cached post, men hvor gyldigheden er udløbet, og de laver en ny anmodning.
Andelen af "overflødige" anmodninger falder fra 47 % til 36 % ved blot at sætte en minimal TTL til 5 minutter. Ved at indstille en minimal TTL til 15 minutter reduceres antallet af disse anmodninger til 29 %. En minimal TTL på 1 time sænker dem til 17 %. En betydelig forskel!
Hvad med at ændre intet på server-siden, men i stedet sætte minimale TTL-værdier i klienternes DNS-caches (routere, lokale resolvere)?
Antallet af nødvendige anmodninger falder fra 47 % til 34 % ved at indstille en minimal TTL til 5 minutter, til 25 % med et minimum på 15 minutter og til 13 % med et minimum på 1 time. Måske er den optimale værdi 40 minutter.
Indflydelsen af denne minimale ændring er enorm.
Hvad er konsekvenserne?
Selvfølgelig kan tjenesten overføres til en ny cloud-udbyder, en ny server, et nyt netværk, hvilket kræver, at kunderne bruger de nyeste DNS-poster. En tilstrækkelig lav TTL hjælper med at gennemføre en sådan overgang glat og uset. Men med overgangen til den nye infrastruktur forventer ingen, at kunderne skifter til de nye DNS-poster inden for 1 minut, 5 minutter eller 15 minutter. At sætte en minimal levetid på 40 minutter i stedet for 5 minutter vil ikke forhindre brugerne i at få adgang til tjenesten.
Men det vil markant reducere forsinkelsen og forbedre privatlivets fred og pålidelighed ved at undgå unødvendige anmodninger.
Selvfølgelig siger RFC, at man skal overholde TTL strengt. Men virkeligheden er, at DNS-systemet er blevet for ineffektivt.
Hvis du arbejder med autoritative DNS-servere, skal du tjekke dine TTL. Har du virkelig brug for så latterligt lave værdier?
Selvfølgelig er der gode grunde til at sætte lave TTL-værdier for DNS-poster. Men ikke for 75 % af DNS-trafikken, som næsten ikke ændrer sig.
Og hvis du af en eller anden grund virkelig har brug for at bruge lave TTL-værdier for DNS, så sørg også for, at caching ikke er aktiveret på dit websted. Af de samme årsager.
Hvis du har en lokal DNS-cache som , som gør det muligt at indstille minimum TTL, brug denne funktion. Det er helt i orden. Der vil ikke ske noget galt. Indstil en minimum TTL på cirka mellem 40 minutter (2400 sekunder) og 1 time. Et helt rimeligt interval.
Kilde: habr.com
