Az alacsony DNS késleltetés kulcsfontosságú tényező a gyors internetezéshez. Ennek minimalizálása érdekében fontos, hogy gondosan válasszuk ki a DNS-szervereket és . De először is meg kell szabadulni a haszontalan lekérdezésektől.
Ezért a DNS-t eredetileg úgy tervezték, mint egy erősen gyorsítható protokollt. A zónaadminisztrátorok élettartamot (TTL) állítanak be egyes rekordokhoz, míg a feloldók ezt az információt használják a rekordok memóriában való tárolásához, hogy elkerüljék a szükségtelen forgalmat.
Hatékony a gyorsítótárazás? Néhány éve egy kis kutatásom azt mutatta, hogy nem tökéletes. Nézzük meg a jelenlegi helyzetet.
Az információ összegyűjtéséhez módosítottam a TTL érték megőrzésére a válaszhoz. Ez a rekordok minimális TTL-jeként van definiálva, minden bejövő lekérdezés esetén. Ez jó áttekintést ad a valódi forgalom TTL eloszlásáról, és figyelembe veszi a különböző lekérdezések népszerűségét. A módosított szerver néhány órán át működött.
Az eredményül kapott adathalmaz 1 583 579 rekordot tartalmaz (name, qtype, TTL, timestamp). Itt van a TTL teljes eloszlása (X tengely — TTL másodpercekben):
Kivéve a nem jelentős csúcsot 86 400-on (főleg az SOA rekordok esetén), meglehetősen nyilvánvaló, hogy a TTL-ek alacsony tartományban vannak. Nézzük meg közelebbről:
Rendben, az 1 óránál hosszabb TTL statisztikailag nem jelentős. Akkor koncentráljunk a 0−3600 közötti tartományra:
A legtöbb TTL 0-tól 15 percig terjed:
A túlnyomó többség 0-tól 5 percig terjed:
Ez nem túl jó.
A felhalmozott eloszlás még nyilvánvalóbbá teszi a problémát:
A DNS válaszok felében a TTL 1 perc vagy ennél kevesebb, háromnegyedük esetén pedig 5 perc vagy kevesebb.
De várjon, valójában mindenki még rosszabb. Hiszen ez a TTL az autoritatív szerverektől származik. Azonban az ügyfél feloldók (például routerek, helyi gyorsítótárak) a feljebb lévő feloldóktól kapják a TTL-t, ami minden másodpercben csökken.
Így az ügyfél valójában minden rekordot átlagosan az eredeti TTL feléig használhat, majd új lekérdezést küld.
Lehet, hogy ezek az nagyon alacsony TTL-ek csak a szokatlan lekérdezésekre vonatkoznak, és nem a népszerű weboldalakra és API-kra? Nézzük meg:
Az X tengely a TTL, az Y tengely a lekérdezések népszerűsége.
Sajnos a legnépszerűbb lekérdezések is a legrosszabbul gyorsíthatók.
Hozzávetőleg:
Verdikt: a helyzet valóban rossz. Már korábban is rossz volt, de még rosszabbá vált. A DNS gyorsítótárazás gyakorlatilag haszontalanná vált. Mivel egyre kevesebb ember használja a szolgáltatója DNS-értelmezőjét (tiszteletre méltó okokból), a késleltetés növekedése egyre észlelhetőbbé válik.
A DNS gyorsítótárazás csak olyan tartalom számára hasznos, amelyet senki sem látogat.
Ezen kívül vegye figyelembe, hogy a szoftver értelmezheti az alacsony TTL-t.
Miért van ez?
Miért állítanak be ilyen alacsony TTL-t a DNS-bejegyzések számára?
- A régi terhelésmegosztók az alapértelmezett beállításokkal maradtak.
- Keringnek egy mítosz, hogy a DNS-alapú terhelésmegosztás a TTL-től függ (ez nem igaz – a Netscape Navigator óta a kliensek véletlenszerű IP-címet választanak a RR készletből, és áttérnek egy másikra, ha nem tudnak csatlakozni).
- A DNS-szerver vagy terhelésmegosztó adminisztrátorai azt kívánják elérni, hogy hatékonyan telepítsék a felhasználók által megkívánt konfigurációt, nem pedig a weboldalak és szolgáltatások sebességének növelését.
- Az alacsony TTL nyugalmat ad.
- Az emberek kezdetben alacsony TTL-t állítanak be tesztelés céljából, majd elfelejtik megváltoztatni őket.
- Nem vettem fel a "kikapcsolási tesztet", mivel ez egyre kevésbé releváns. Ha a felhasználókat egy másik hálózatra kell átirányítani, csak azért, hogy egy hibás oldalt jelenítsenek meg, amikor minden más összeomlott, talán elfogadható a több mint 1 perces késleltetés.
Ezen kívül a 1 perces TTL azt jelenti, hogy ha az illetékes DNS-szerverek több mint 1 percre leállnak, senki más nem tudja elérni a függő szolgáltatásokat. A redundancia nem segít, ha a hiba konfigurációs hiba vagy betörés miatt következik be. Másrészt, ésszerű TTL-nél sok kliens továbbra is a korábbi konfigurációt használja, és soha semmit nem tapasztal.
Az alacsony TTL-ért nagyrészt a CDN szolgáltatások és terhelésmegosztók a felelősek, különösen amikor CNAME-t kis TTL-el és hasonlóan alacsony (de független) TTL-bejegyzéseket kombinálnak:
$ 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
$ 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
Minden alkalommal, amikor lejár a CNAME vagy bármelyik A rekord, új kérést kell küldeni. Mindkettő 30 másodperces TTL-lel rendelkezik, de ez nem egyezik meg. A tényleges átlagos TTL 15 másodperc lesz.
De várj! Még rosszabb a helyzet. Egyes feloldók nagyon rosszul viselkednek ilyen helyzetben, alacsony TTL-ekkel:
$ 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
A Level3 feloldó valószínűleg BIND-ot használ. Ha folytatod ennek a kérésnek a küldését, mindig 1-es TTL-t fog visszaadni. Lényegében, raw.githubusercontent.com soha nem kerül tárolásra.
Íme egy másik példa egy ilyen helyzetre egy nagyon népszerű domain esetében:
$ 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
Legalább három CNAME rekord. Jaj. Az egyiknek normális TTL-je van, de ez teljesen haszontalan. A többi CNAME kezdeti TTL-je 60 másodperc, de a domainok akamai.net maximális TTL-je 20 másodperc, és egyik sem szinkronizált.
Mi a helyzet azokkal a domainekkel, amelyek folyamatosan lekérdezik az Apple eszközöket?
$ 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
Ugyanaz a probléma, mint a Firefoxnál, és a TTL a legtöbb időben 1 másodpercre ragad a Level3 feloldó használatakor.
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
A rekordnál safebrowsing.googleapis.com a TTL értéke 60 másodperc, mint a Facebook domaineknél. És megint, az ügyfél szempontjából ezek az értékek feleződnek.
Mi a helyzet a minimális TTL beállításával?
Használva a nevet, a kérés típusát, a TTL-t és az eredetileg tárolt időbélyeget, írtam egy szkriptet, hogy 1,5 millió kérést szimuláljak, amelyek egy gyorsítótárazó feloldón haladnak át, hogy felmérjem a lejárt gyorsítótárazási bejegyzés miatt küldött felesleges kérések mennyiségét.
A kérések 47,4%-a a meglévő bejegyzés lejárta után készült. Ez elfogadhatatlanul magas.
Mi lesz a hatása a gyorsítótárazásra, ha minimális TTL-t állítanak be?
Az X tengely a TTL minimális értékeit mutatja. Az ennél magasabb TTL-lel rendelkező bejegyzések nem érintettek.
Y tengely — az olyan kliensek által leadott kérések százaléka, akiknek már van tárolt bejegyzésük, de annak lejárt a határideje, és új kérést indítanak.
A "felesleges" kérések aránya 47%-ról 36%-ra csökken, ha a minimális TTL-t 5 percre állítják. Ha a minimális TTL-t 15 percre állítják, akkor ezek a kérések 29%-ra csökkennek. Az 1 órás minimális TTL 17%-ra csökkenti őket. Jelentős különbség!
Mi lenne, ha semmit sem változtatnánk a szerveren, hanem inkább a minimális TTL-t állítanánk be a klienst DNS-cache-jében (útválasztók, helyi feloldók)?
A szükséges kérések száma 47%-ról 34%-ra csökken, ha a minimális TTL 5 percre van állítva, 25%-ra csökken 15 perces minimum esetén, és 13%-ra 1 órás minimum mellett. Talán az optimális érték 40 perc.
Ennek a minimális változtatásnak a hatása óriási.
Mik a következmények?
Természetesen a szolgáltatás átírható egy új felhőszolgáltatóra, új szerverre, új hálózatra, követelve a kliensektől, hogy használják az új DNS-bejegyzéseket. És egy viszonylag alacsony TTL segít simán és észrevétlenül végrehajtani ezt az átmenetet. De amikor új infrastruktúrára váltunk, senki sem várja el, hogy a kliensek 1, 5 vagy 15 percen belül új DNS-bejegyzésekre álljanak át. A minimális TTL 40 percre állítása nem akadályozza meg a felhasználókat, hogy hozzáférjenek a szolgáltatáshoz.
Ez azonban jelentősen csökkenti a késleltetést, és javítja a bizalmas adatkezelést és megbízhatóságot, elkerülve a felesleges kéréseket.
Természetesen az RFC-k azt mondják, hogy szigorúan be kell tartani a TTL-t. De a valóság az, hogy a DNS rendszere túl hatékonnyá vált.
Ha autorizált DNS-szerverekkel dolgozik, kérjük, ellenőrizze a TTL-jeit. Valóban szüksége van ilyen nevetségesen alacsony értékekre?
Természetesen vannak megalapozott indokok a DNS-bejegyzések alacsony TTL-inek beállítására. De a DNS-forgalom 75%-ának számára, amely gyakorlatilag nem változik.
És ha bármilyen okból tényleg alacsony TTL-t kell használnia a DNS-hez, mindenképpen győződjön meg arról, hogy az Ön weboldalán nincs bekapcsolva a gyorsítótárazás. Ugyanezen okok miatt.
Ha helyi DNS-cache fut, például , amely lehetővé teszi a minimális TTL beállítását, használja ezt a funkciót. Ez rendben van. Semmi rossz nem fog történni. Állítson be minimális TTL-t körülbelül 40 perc (2400 másodperc) és 1 óra között. Teljesen ésszerű tartomány.
Forrás: habr.com
