Az alacsony DNS késleltetés kulcsa a gyors internetes böngészésnek. Ennek minimalizálása érdekében fontos gondosan kiválasztani a DNS-kiszolgálókat és . De az első lépés az, hogy megszabaduljon a haszontalan lekérdezésektől.
Ez az oka annak, hogy a DNS-t eredetileg nagymértékben gyorsítótárazható protokollnak tervezték. A zóna adminisztrátorai beállítják az életidőt (TTL) az egyes bejegyzésekhez, és a feloldók ezt az információt használják fel a bejegyzések memóriában való tárolása során, hogy elkerüljék a felesleges forgalmat.
A gyorsítótár hatékony? Pár éve egy kis kutatásom kimutatta, hogy nem volt tökéletes. Vessünk egy pillantást a dolgok jelenlegi állására.
Az információgyűjtéshez foltoztam a válasz TTL értékének mentéséhez. Ez az egyes bejövő kérések rekordjainak minimális TTL-je. Ez jó áttekintést ad a valós forgalom TTL-eloszlásáról, és figyelembe veszi az egyedi kérések népszerűségét is. A szerver javított verziója több órán keresztül működött.
Az eredményül kapott adatkészlet 1 583 579 rekordból áll (név, qtype, TTL, időbélyeg). Íme a teljes TTL eloszlás (az X-tengely TTL másodpercben):
A 86-nál (leginkább SOA rekordoknál) tapasztalható kisebb ütéstől eltekintve elég egyértelmű, hogy a TTL-ek az alacsony tartományban vannak. Nézzük meg közelebbről:
Oké, az 1 óránál hosszabb TTL-ek statisztikailag nem szignifikánsak. Akkor fókuszáljunk a 0–3600 tartományra:
A legtöbb TTL 0 és 15 perc közötti:
A legtöbb 0 és 5 perc közötti:
Nem túl jó.
A kumulatív eloszlás még nyilvánvalóbbá teszi a problémát:
A DNS-válaszok felének TTL-je legfeljebb 1 perc, háromnegyedének pedig 5 perces vagy annál rövidebb.
De várj, tényleg rosszabb. Végül is ez a TTL a mérvadó szerverektől. Az ügyfélfeloldók (például útválasztók, helyi gyorsítótárak) azonban TTL-t kapnak az upstream feloldóktól, és ez másodpercenként csökken.
Így az ügyfél minden bejegyzést átlagosan az eredeti TTL feléig használhat fel, mielőtt új kérést küldene.
Lehet, hogy ezek a nagyon alacsony TTL-ek csak szokatlan kérésekre vonatkoznak, népszerű webhelyekre és API-kra nem? Nézzük meg:
Az X tengely a TTL, az Y tengely a lekérdezés népszerűsége.
Sajnos a legnépszerűbb lekérdezések gyorsítótárazása is a legrosszabb.
Nagyítsunk rá:
Ítélet: nagyon rossz. Már korábban is rossz volt, de még rosszabb lett. A DNS-gyorsítótárazás gyakorlatilag használhatatlanná vált. Ahogy egyre kevesebben használják internetszolgáltatójuk DNS-feloldóját (jó okokból), a várakozási idő növekedése észrevehetőbbé válik.
A DNS-gyorsítótárazás csak olyan tartalmak esetében vált hasznossá, amelyeket senki sem látogat meg.
Kérjük, vegye figyelembe azt is, hogy a szoftver az alacsony TTL-eket értelmezni.
Miért van ez?
Miért vannak a DNS rekordok ilyen alacsony TTL-re állítva?
- A korábbi terheléselosztók alapbeállításai megmaradtak.
- Vannak mítoszok, miszerint a DNS terheléselosztása a TTL-től függ (ez nem igaz - a Netscape Navigator napjai óta az ügyfelek véletlenszerű IP-címet választottak egy sor RR-ből, és transzparens módon megpróbáltak másikat, ha nem tudnak csatlakozni)
- Az adminisztrátorok azonnal szeretnék alkalmazni a változtatásokat, így könnyebb a tervezés.
- A DNS-kiszolgáló vagy a terheléselosztó rendszergazdája a feladatának tekinti a felhasználók által kért konfiguráció hatékony telepítését, és nem a webhelyek és szolgáltatások felgyorsítását.
- Az alacsony TTL-ek nyugalmat biztosítanak.
- Az emberek először alacsony TTL-eket állítanak be a teszteléshez, majd elfelejtik megváltoztatni azokat.
A "feladatátvételt" nem vettem fel a listára, mert egyre kevésbé releváns. Ha át kell irányítania a felhasználókat egy másik hálózatra, csak azért, hogy hibaoldalt jelenítsen meg, amikor minden más hibás, akkor az 1 percnél hosszabb késleltetés valószínűleg elfogadható.
Ezenkívül az egyperces TTL azt jelenti, hogy ha a mérvadó DNS-kiszolgálókat több mint 1 percig blokkolják, senki más nem férhet hozzá a függő szolgáltatásokhoz. A redundancia pedig nem segít, ha az ok konfigurációs hiba vagy feltörés. Másrészt ésszerű TTL-ek mellett sok ügyfél továbbra is a korábbi konfigurációt fogja használni, és soha nem vesz észre semmit.
A CDN-szolgáltatások és a terheléselosztók nagyrészt okolhatók az alacsony TTL-ekért, különösen, ha a CNAME-ket alacsony TTL-ekkel és a rekordokat ugyanolyan alacsony (de független) TTL-ekkel kombinálják:
$ 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
Amikor a CNAME vagy bármelyik A rekord lejár, új kérést kell küldeni. Mindkettőnek 30 másodperces TTL-je van, de nem ugyanaz. A tényleges átlagos TTL 15 másodperc lesz.
De várj! Még rosszabb. Egyes feloldók nagyon rosszul viselkednek ebben a helyzetben, két kapcsolódó alacsony TTL-lel:
$ 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-en fut. Ha továbbra is elküldi ezt a kérést, mindig 1-es TTL-t küldünk vissza. raw.githubusercontent.com soha nincs gyorsítótárban.
Í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. Ay. Az egyiknek tisztességes TTL-je van, de teljesen használhatatlan. Más CNAME-ok kezdeti TTL-je 60 másodperc, de a domainek esetében akamai.net a maximális TTL 20 másodperc, és egyik sem fázisban van.
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-nél, legtöbbször 1 másodpercnél elakad 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 felvételen safebrowsing.googleapis.com A TTL értéke 60 másodperc, mint a Facebook domaineknél. És ismét, az ügyfél szemszögéből ezek az értékek a felére csökkennek.
Mit szólnál egy minimális TTL beállításához?
A név, a kérés típusa, a TTL és az eredetileg tárolt időbélyeg felhasználásával írtam egy szkriptet, amely 1,5 millió gyorsítótár-feloldón áthaladó kérést szimulál, hogy megbecsüljem a lejárt gyorsítótár-bejegyzés miatt küldött szükségtelen kérések mennyiségét.
A kérelmek 47,4%-a egy meglévő rekord lejárta után érkezett. Ez indokolatlanul magas.
Milyen hatással lesz a gyorsítótárazásra, ha beállítja a minimális TTL-t?
Az X tengely a minimális TTL értékek. Ez az érték feletti forrás-TTL-vel rendelkező rekordokat nem érinti.
Az Y tengely egy olyan ügyféltől érkező kérések százalékos aránya, amelynek már van gyorsítótárazott bejegyzése, de az lejárt, és új kérelmet küld.
Az „extra” kérések aránya 47%-ról 36%-ra csökken a minimális TTL 5 percre állításával. Ha a minimális TTL-t 15 percre állítja, ezeknek a kéréseknek a száma 29%-ra csökken. A minimális 1 órás TTL 17%-ra csökkenti őket. Jelentős különbség!
Mi lenne, ha nem változtatnánk semmit a szerver oldalon, hanem beállítanánk a minimális TTL-t a kliens DNS gyorsítótáraiban (routerek, helyi feloldók)?
A szükséges kérelmek száma 47%-ról 34%-ra csökken minimum 5 perces TTL mellett, 25%-ra minimum 15 perccel, és 13%-ra minimum 1 órával. Talán 40 perc az optimális.
Ennek a kis változásnak óriási a hatása.
Milyen következményekkel jár?
Természetesen a szolgáltatás áthelyezhető új felhőszolgáltatóhoz, új szerverhez, új hálózathoz, megkövetelve az ügyfelektől a legújabb DNS rekordok használatát. És egy meglehetősen kicsi TTL segít abban, hogy egy ilyen átmenetet zökkenőmentesen és észrevehetetlenül lehessen végrehajtani. Az új infrastruktúrára való átállással azonban senki sem várja el az ügyfelektől, hogy 1 percen, 5 percen vagy 15 percen belül áttérjenek az új DNS-rekordokra. A minimális TTL 40 perc helyett 5 percre állítása nem akadályozza meg a felhasználókat a szolgáltatás elérésében.
Ez azonban jelentősen csökkenti a várakozási időt, és javítja az adatvédelmet és a megbízhatóságot a szükségtelen kérések elkerülésével.
Természetesen az RFC-k azt mondják, hogy a TTL-t szigorúan be kell tartani. De a valóság az, hogy a DNS-rendszer túlságosan nem hatékony.
Ha hiteles DNS-kiszolgálókkal dolgozik, ellenőrizze a TTL-eket. Tényleg ilyen nevetségesen alacsony értékek kellenek?
Természetesen jó okok vannak arra, hogy kis TTL-eket állítsunk be a DNS-rekordokhoz. De nem a DNS-forgalom 75%-ára, amely gyakorlatilag változatlan marad.
És ha valamilyen okból valóban alacsony TTL-eket kell használnia a DNS-hez, ugyanakkor győződjön meg arról, hogy webhelyén nincs engedélyezve a gyorsítótárazás. Ugyanezen okokból.
Ha fut egy helyi DNS-gyorsítótár, mint pl amely lehetővé teszi a minimális TTL-ek beállítását, használja ezt a funkciót. Ez jó. Semmi rossz nem fog történni. Állítsa a minimális TTL-t körülbelül 40 percre (2400 másodpercre) és 1 órára. Egészen ésszerű tartomány.
Forrás: will.com