Lege DNS-latinsje is de kaai foar fluch blêdzjen op ynternet. Om it te minimalisearjen, is it wichtich om DNS-tsjinners foarsichtich te selektearjen en . Mar de earste stap is om nutteleaze fragen kwyt te reitsjen.
Dit is de reden dat DNS oarspronklik is ûntworpen as in protokol mei hege cache. Sônebehearders sette in tiid om te libjen (TTL) foar yndividuele yngongen, en resolvers brûke dizze ynformaasje by it bewarjen fan ynstjoerings yn it ûnthâld om ûnnedich ferkear te foarkommen.
Is caching effektyf? In pear jier lyn liet myn lytse ûndersyk sjen dat it net perfekt wie. Litte wy ris sjen nei de aktuele stân fan saken.
Om ynformaasje te sammeljen haw ik patched om de TTL-wearde foar it antwurd op te slaan. It wurdt definieare as de minimale TTL fan har records foar elk ynkommende fersyk. Dit jout in goed oersjoch fan 'e TTL-ferdieling fan echte ferkear, en hâldt ek rekken mei de populariteit fan yndividuele oanfragen. De patched ferzje fan de tsjinner wurke ferskate oeren.
De resultearjende dataset bestiet út 1 records (namme, qtype, TTL, tiidstempel). Hjir is de algemiene TTL-distribúsje (X-as is TTL yn sekonden):
Njonken in lytse bult op 86 (meast foar SOA-records), is it frij dúdlik dat de TTL's yn it lege berik binne. Litte wy in tichterby besjen:
Okee, TTL's grutter dan 1 oere binne net statistysk signifikant. Lit ús dan rjochtsje op it berik 0-3600:
De measte TTL's binne fan 0 oant 15 minuten:
De grutte mearderheid is fan 0 oant 5 minuten:
It is net hiel goed.
Kumulative ferdieling makket it probleem noch dúdliker:
De helte fan 'e DNS-antwurden hat in TTL fan 1 minút of minder, en trijekwart hat in TTL fan 5 minuten of minder.
Mar wachtsje, it is eins slimmer. Dit is ommers TTL fan autoritative servers. Client-resolvers (bgl. routers, lokale caches) ûntfange lykwols in TTL fan streamop-resolvers, en it nimt elke sekonde ôf.
Sa kin de kliïnt eins elke yngong brûke foar gemiddeld de helte fan 'e orizjinele TTL foardat jo in nij fersyk ferstjoere.
Miskien binne dizze heul lege TTL's allinich fan tapassing op ûngewoane oanfragen en net populêre websiden en API's? Litte wy ris sjen:
De X-as is TTL, de Y-as is query populariteit.
Spitigernôch binne de populêrste fragen ek de minste om te cache.
Litte wy ynzoome:
Oardiel: it is echt slim. It wie earder al slim, mar it waard noch slimmer. DNS-caching is praktysk nutteloos wurden. Om't minder minsken de DNS-resolver fan har ISP brûke (om goede redenen), wurdt de tanimming fan latency merkberder.
DNS-caching is allinich nuttich wurden foar ynhâld dy't gjinien besykje.
Tink derom ek dat de software kin ynterpretearje lege TTLs.
Wêrom is it sa?
Wêrom binne DNS-records ynsteld op sa'n lege TTL?
- Legacy load balancers waarden oerbleaun mei standertynstellingen.
- D'r binne myten dat DNS-loadbalancing hinget ôf fan TTL (dit is net wier - sûnt de dagen fan Netscape Navigator hawwe kliïnten in willekeurich IP-adres keazen út in set fan RR's en transparant besocht in oar as se net kinne ferbine)
- Behearders wolle wizigingen fuortendaliks tapasse, sadat it makliker is om te plannen.
- De behearder fan in DNS-tsjinner of loadbalancer sjocht syn taak as it effisjint ynsetten fan de konfiguraasje dy't brûkers freegje, en net it fersnellen fan siden en tsjinsten.
- Lege TTL's jouwe jo frede fan geast.
- Minsken sette yn earste ynstânsje lege TTL's foar testen en ferjitte se dan te feroarjen.
Ik haw "failover" net yn 'e list opnommen, om't it hieltyd minder relevant wurdt. As jo brûkers moatte omliede nei in oar netwurk gewoan om in flaterside wer te jaan as absolút al it oare is brutsen, is in fertraging fan mear dan 1 minút wierskynlik akseptabel.
Derneist betsjut in TTL fan ien minút dat as autoritative DNS-tsjinners langer dan 1 minút blokkearre wurde, gjinien oars tagong kin ta ôfhinklike tsjinsten. En oerstalligens sil net helpe as de oarsaak in konfiguraasjeflater of in hack is. Oan 'e oare kant, mei ridlike TTL's, sille in protte kliïnten de foarige konfiguraasje trochgean en nea wat fernimme.
CDN-tsjinsten en loadbalancers binne foar in grut part de skuld foar lege TTL's, foaral as se CNAME's kombinearje mei lege TTL's en records mei like lege (mar ûnôfhinklike) TTL's:
$ 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
Wannear't de CNAME of ien fan 'e A-records ferrinne, moat in nij fersyk stjoerd wurde. Beide hawwe in 30 twadde TTL, mar it is net itselde. De werklike gemiddelde TTL sil 15 sekonden wêze.
Mar wachtsje! It is noch slimmer. Guon resolvers gedrage har heul min yn dizze situaasje mei twa assosjearre lege TTL's:
$ 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
De Level3-resolver rint wierskynlik op BIND. As jo trochgean mei it ferstjoeren fan dit fersyk, sil in TTL fan 1 yn wêzen wurde weromjûn. raw.githubusercontent.com wurdt nea yn cache bewarre.
Hjir is in oar foarbyld fan sa'n situaasje mei in heul populêr domein:
$ 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
Op syn minst trije CNAME-records. Ay. Men hat in fatsoenlike TTL, mar it is hielendal nutteloos. Oare CNAMEs hawwe in earste TTL fan 60 sekonden, mar foar domeinen akamai.net de maksimum TTL is 20 sekonden en net ien fan harren is yn faze.
Hoe sit it mei domeinen dy't konstant ûndersiikje fan Apple-apparaten?
$ 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
Itselde probleem as Firefox en TTL sille meastentiids op 1 sekonde sitte by it brûken fan 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
By de opname safebrowsing.googleapis.com TTL-wearde is 60 sekonden, lykas Facebook-domeinen. En, wer, út it eachpunt fan 'e klant, wurde dizze wearden halve.
Hoe sit it mei it ynstellen fan in minimum TTL?
Mei help fan de namme, fersyktype, TTL, en oarspronklik bewarre tiidstempel, skreau ik in skript om 1,5 miljoen oanfragen te simulearjen dy't troch in caching-resolver passe om it folume fan ûnnedige oanfragen te skatten dy't ferstjoerd binne fanwege in ferrûne cache-yngong.
47,4% fan oanfragen waarden makke neidat in besteande rekord wie ferrûn. Dit is ûnferstannich heech.
Wat sil de ynfloed wêze op caching as de minimale TTL is ynsteld?
De X-as is de minimale TTL-wearden. Records mei boarne TTL's boppe dizze wearde wurde net beynfloede.
De Y-as is it persintaazje oanfragen fan in kliïnt dy't al in cached yngong hat, mar it is ferrûn en makket in nij fersyk.
It oandiel fan "ekstra" oanfragen wurdt fermindere fan 47% nei 36% troch gewoan de minimale TTL op 5 minuten yn te stellen. Troch de minimale TTL op 15 minuten yn te stellen, sakket it oantal fan dizze oanfragen nei 29%. In minimum TTL fan 1 oere ferleget se nei 17%. Wichtich ferskil!
Hoe sit it mei neat oan 'e serverkant te feroarjen, mar ynstee de minimale TTL yn te stellen yn client DNS-caches (routers, lokale resolvers)?
It oantal fereaske oanfragen sakket fan 47% nei 34% mei in minimum TTL fan 5 minuten, nei 25% mei in minimum fan 15 minuten, en nei 13% mei in minimum fan 1 oere. Miskien is 40 minuten optimaal.
De ynfloed fan dizze lytse feroaring is enoarm.
Wat binne de gefolgen?
Fansels kin de tsjinst ferpleatst wurde nei in nije wolkprovider, nije server, nij netwurk, wêrtroch kliïnten de lêste DNS-records brûke moatte. En in frij lytse TTL helpt om sa'n oergong soepel en ûnmerkber te meitsjen. Mar mei de oergong nei nije ynfrastruktuer ferwachtet gjinien dat kliïnten binnen 1 minút, 5 minuten of 15 minuten migrearje nei nije DNS-records. It ynstellen fan de minimale TTL op 40 minuten ynstee fan 5 minuten sil net foarkomme dat brûkers tagong krije ta de tsjinst.
Dit sil de latency lykwols signifikant ferminderje en privacy en betrouberens ferbetterje troch ûnnedige oanfragen te foarkommen.
Fansels sizze de RFC's dat TTL strikt folge wurde moat. Mar de realiteit is dat it DNS-systeem te yneffisjint wurden is.
As jo wurkje mei autoritative DNS-tsjinners, kontrolearje dan jo TTL's. Binne jo echt nedich sokke bespotlik lege wearden?
Fansels binne d'r goede redenen om lytse TTL's yn te stellen foar DNS-records. Mar net foar de 75% fan DNS-ferkear dat praktysk net feroaret.
En as jo om ien of oare reden wirklik lege TTL's moatte brûke foar DNS, soargje derfoar dat jo side gjin caching ynskeakele hat. Om deselde redenen.
As jo in lokale DNS-cache hawwe rinnen, lykas wêrmei jo te setten minimum TTLs, brûk dizze funksje. Dit is goed. Neat slim sil barre. Stel de minimale TTL yn op sawat 40 minuten (2400 sekonden) en 1 oere. Hiel ridlik berik.
Boarne: www.habr.com
