A Domain Name System (DNS) latency kulcsfontosságú eleme a jó online élménynek. A DNS-késleltetés minimalizálása érdekében fontos szerepet játszik a DNS-kiszolgálók és névtelenítési relék gondos kiválasztása.
de a késleltetés minimalizálásának legjobb módja az, hogy elkerüljük a haszontalan lekérdezések elküldését. Ezért tervezték a DNS-t, az első nap óta, hogy erősen gyorsítótárazható protokoll legyen. Az egyes rekordok egy time-to-live (TTL), eredetileg meghatározott zóna rendszergazdák, és resolvers használja ezt az információt, hogy ezeket a rekordokat a memóriában, hogy elkerüljék a felesleges forgalmat.
hatékony a gyorsítótár? Egy gyors tanulmány, amelyet néhány évvel ezelőtt készítettem, azt mutatta, hogy van hely a fejlesztésre. Ma szeretnék egy új pillantást vetni a jelenlegi helyzetre.
ehhez egy titkosított DNS-kiszolgálót javítottam, hogy minden bejövő lekérdezéshez tárolja a válasz eredeti TTL-jét, amelyet rekordjainak minimális TTL-ként határoztak meg. Ez jó áttekintést nyújt a valós forgalom TTL eloszlásáról, de az egyes lekérdezések népszerűségét is figyelembe veszi.
Ez a foltos verzió néhány órán át futhatott. A kapott adathalmaz 1,583,579 (név, qtype, TTL, időbélyeg) csomókból áll. Itt van a teljes TTL Eloszlás (az X tengely a TTL másodpercben):
mellett elhanyagolható bump 86,400 (főleg SOA records), ez elég nyilvánvaló, hogy a TTLS az alacsony tartományban. Nagyítás:
rendben, az 1 óra feletti TTL-K statisztikailag jelentéktelenek. Fókuszáljunk a 0-3 600 tartományra:
és ahol a legtöbb TTL 0 és 15 perc között ül:
a túlnyomó többség 0-5 perc között van:
Ez nem nagy. Az összesített Eloszlás még nyilvánvalóbbá teheti a kérdést:
Az Internet fele legalább 1 perces TTL-vel rendelkezik, háromnegyede pedig legalább 5 perces TTL-vel rendelkezik.
de várj, ez valójában rosszabb. Ezek a hiteles kiszolgálók által meghatározott TTLS-ek. Azonban, TTLS lekért kliens resolvers (például útválasztók, helyi gyorsítótárak) kap egy TTL, hogy upstream resolvers csökken másodpercenként. Tehát átlagosan az ügyfél tényleges időtartama egy gyorsítótárazott bejegyzést használhat, mielőtt új lekérdezést igényelne, az eredeti TTL fele.
lehet, hogy ezek a nagyon alacsony TTL-ek csak a nem gyakori lekérdezéseket érintik, nem pedig a népszerű webhelyeket és API-kat. Vessünk egy pillantást:
sajnos a legnépszerűbb lekérdezések is a leginkább értelmetlenek a gyorsítótárhoz. Nagyítsunk rá:
ítélet: nagyon rossz, vagy inkább már rossz volt, és egyre rosszabb lett. A DNS gyorsítótár a haszontalan mellett vált. Kevesebb ember használja az internetszolgáltató DNS-feloldóját (jó okokból), a megnövekedett késleltetés észrevehetőbbé válik. A DNS-gyorsítótár csak olyan tartalomhoz lett hasznos, amelyet senki sem látogat meg. Vegye figyelembe azt is, hogy a szoftver eltérően értelmezheti az alacsony TTL-eket.
miért?
miért állítják be a DNS-rekordokat ilyen alacsony TTL-ekkel?
- a korábbi terheléselosztók az alapértelmezett beállításokkal maradnak.
- a városi legenda, hogy a DNS-alapú terheléselosztás a TTLs-től függ (nem).
- az adminisztrátorok azt akarják, hogy a változtatásokat azonnal alkalmazzák, mert kevesebb tervezési munkát igényelhet.
- DNS vagy terheléskiegyenlítő rendszergazdaként az Ön feladata, hogy hatékonyan telepítse a konfigurációs embereket, ne pedig a webhelyek és szolgáltatások gyorsaságát.
- az alacsony TTLs nyugalmat ad.
nem vagyok benne “a failover” abban a listában, mivel ez egyre kevésbé releváns. Ha a szándék az, hogy átirányítsa a felhasználókat egy másik hálózatra, csak azért, hogy megjelenjen egy sikertelen bálna oldal, amikor minden más ég, valószínűleg elfogadható több mint egy perces késés.
CDNs, majd a terhelés-balancers nagyrészt a hibás, különösen akkor, ha összekapcsolják a CNAME rekordok rövid TTLs a bejegyzések is, amelyek rövid (de független) TTLs:
$ drill raw.githubusercontent.comraw.githubusercontent.com. 9 IN CNAME github.map.fastly.net.github.map.fastly.net. 20 IN A 151.101.128.133github.map.fastly.net. 20 IN A 151.101.192.133github.map.fastly.net. 20 IN A 151.101.0.133github.map.fastly.net. 20 IN A 151.101.64.133
új lekérdezést kell küldeni, amikor a CNAME, vagy a jegyző jár le. Mindkettőnek van egy 30 másodperces TTL-je, de nincsenek fázisban. A tényleges átlagos TTL 15 másodperc lesz.
de várj! Ez rosszabb. Néhány feloldó elég rosszul viselkedik egy ilyen alacsony TTL-CNAME + alacsony TTL-rekordok helyzet:
$ drill raw.githubusercontent.com @4.2.2.2raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net.github.map.fastly.net. 1 IN A 151.101.16.133
Ez a Level3 feloldója, amely szerintem fut BIND. Ha továbbra is elküldi ezt a lekérdezést, a visszaküldött TTL mindig 1 lesz. Lényegében, raw.githubusercontent.com soha nem lesz Gyorsítótárazva.
itt van egy másik példa az alacsony TTL-CNAME + alacsony TTL-rekordok helyzetére, amely egy nagyon népszerű nevet tartalmaz:
$ drill detectportal.firefox.com @1.1.1.1detectportal.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.106a1089.dscd.akamai.net. 10 IN A 104.123.50.88
legalább három CNAME rekord. Jaj. Az egyiknek van egy tisztességes TTL – je, de teljesen haszontalan. Más CNAMEs egy eredeti TTL 60 másodperc; az akamai.net a nevek maximum 20 másodperces TTL-t tartalmaznak, és ezek egyike sem fázisban van.
mi lenne, ha az Apple eszközök folyamatosan szavaznának?
$ drill 1-courier.push.apple.com @4.2.2.21-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.84gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
ugyanaz a konfiguráció, mint a Firefox, a TTL pedig a Level3 felbontójának használatakor legtöbbször 1-re ragadt.
mi a helyzet a Dropbox?
$ drill client.dropbox.com @8.8.8.8client.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.2client.dropbox.com. 1 IN CNAME client.dropbox-dns.com.client.dropbox-dns.com. 1 IN A 162.125.64.3
safebrowsing.googleapis.com van egy TTL 60 másodperc. A Facebook-neveknek 60 másodperces TTL-je van. És még egyszer, ügyfél szemszögéből, ezeket az értékeket fel kell felére csökkenteni.
mi lenne a minimális TTL beállításával?
az eredetileg tárolt név, lekérdezés típusa, TTL és időbélyeg segítségével írtam egy szkriptet, amely szimulálja a gyorsítótár-feloldón átmenő 1,5+ millió lekérdezést annak becslésére, hogy hány lekérdezést küldtek el egy lejárt gyorsítótár-bejegyzés miatt. A lekérdezések 47,4% – a egy meglévő, gyorsítótárazott bejegyzés lejárta után történt. Ez indokolatlanul magas.
mi lenne a hatása a gyorsítótárazásra, ha minimális TTL-t állítanának be?
Az X tengely a beállított minimális TTL. Azok a rekordok, amelyek eredeti TTL-je magasabb volt, mint ez az érték, nem érintettek. Az Y tengely egy olyan ügyfél által készített lekérdezések százalékos aránya, amely már rendelkezik gyorsítótárazott bejegyzéssel, de új lekérdezés történt, és a gyorsítótárazott bejegyzés lejárt.
a lekérdezések száma 47% – ról 36% – ra csökken, csak egy minimális TTL 5 perc beállításával. A minimum 15 perces TTL beállításával a szükséges lekérdezések száma 29% – ra csökken. Az 1 órás minimális TTL 17% – ra csökken. Ez jelentős különbség!
mi lenne, ha nem változik semmi szerver-oldalon, de az, hogy ügyfél a DNS-cache (routerek, helyi névfeloldók, valamint cache…) meg minimum TTL helyett?
A száma, szükséges lekérdezések csepp 47% – ról 34% – kal a minimálbér TTL 5 perc, 25% – a egy 15 perces minimális, illetve 13%, 1 óra minimum. 40 perc talán egy édes hely. Ennek a minimális változásnak a hatása hatalmas.
milyen következményekkel jár?
természetesen egy szolgáltatás átválthat egy új felhőszolgáltatóra, egy új kiszolgálóra, egy új hálózatra, amely megköveteli az ügyfelektől a naprakész DNS-rekordok használatát. A viszonylag alacsony TTL-ek segítenek az átmenet súrlódásmentessé tételében. Az új infrastruktúrába költözők azonban nem számíthatnak arra, hogy az ügyfelek az új DNS-rekordokat 1 perc, 5 perc vagy 15 perc alatt használják.
az 5 perc helyett legalább 40 perc TTL beállítása nem akadályozza meg a felhasználókat a szolgáltatás elérésében. Ugyanakkor drasztikusan csökkenti a késleltetést ,és javítja az adatvédelmet (több lekérdezés = több követési lehetőség) és a megbízhatóságot a szükségtelen lekérdezések elkerülésével.
természetesen az RFC-k azt mondják, hogy a TTLs-t szigorúan tiszteletben kell tartani. De a valóság az, hogy a DNS nem hatékony.
ha hiteles DNS-kiszolgálókat működtet, kérjük, olvassa el újra a TTLs-t. Tényleg szükség van ezekre, hogy nevetségesen alacsony?
olvassa el: hogyan válasszuk ki a DNS TTL értékeket
persze, vannak érvényes okok az alacsony DNS TTLs használatához. De nem az Internet 75% – a számára, hogy olyan tartalmat szolgáltasson, amely többnyire megváltoztathatatlan,de értelmetlen a gyorsítótár. Ha bármilyen okból valóban alacsony DNS-TTLs-t kell használnia, akkor győződjön meg róla, hogy a gyorsítótár sem működik a webhelyén. Ugyanezen okok miatt.
ha olyan helyi DNS-gyorsítótárat használ, mint például a DNSCrypt-proxy, amely lehetővé teszi a minimális TTLs beállítását, használja ezt a funkciót. Ez rendben van. Semmi rossz nem fog történni. Állítsa ezt a minimális TTL-t 40 perc (2400 másodperc) és 1 óra között; ez egy teljesen ésszerű tartomány.
adaptált eredeti bejegyzést, amely megjelent 00f.net