ዝቅተኛ የዲ ኤን ኤስ መዘግየት ፈጣን የበይነመረብ አሰሳ ቁልፍ ነው። እሱን ለመቀነስ የዲ ኤን ኤስ አገልጋዮችን እና በጥንቃቄ መምረጥ አስፈላጊ ነው ስም-አልባ ቅብብሎሽ. ግን የመጀመሪያው እርምጃ ከንቱ መጠይቆችን ማስወገድ ነው.

ለዚህ ነው ዲ ኤን ኤስ በመጀመሪያ የተነደፈው በከፍተኛ መሸጎጫ ፕሮቶኮል ነው። የዞን አስተዳዳሪዎች ለግለሰብ ግቤቶች የመኖርያ ጊዜን (TTL) ያዘጋጃሉ፣ እና ፈታሾች አላስፈላጊ ትራፊክን ለማስቀረት ግቤቶችን በማህደረ ትውስታ ውስጥ ሲያከማቹ ይህንን መረጃ ይጠቀማሉ።

መሸጎጥ ውጤታማ ነው? ከጥቂት አመታት በፊት፣ የእኔ ትንሽ ጥናት ፍፁም እንዳልሆነ አሳይቷል። አሁን ያለበትን ሁኔታ እንመልከት።

እኔ የተጠጋሁት መረጃ ለመሰብሰብ የተመሰጠረ የዲ ኤን ኤስ አገልጋይ ለምላሹ የ TTL ዋጋን ለማስቀመጥ. ለእያንዳንዱ ገቢ ጥያቄ ዝቅተኛው የ TTL መዝገቦች ተብሎ ይገለጻል። ይህ ስለ እውነተኛ ትራፊክ የቲቲኤል ስርጭት ጥሩ እይታ ይሰጣል፣ እና የግለሰብ ጥያቄዎችን ተወዳጅነት ግምት ውስጥ ያስገባል። የታሸገው የአገልጋዩ ስሪት ለብዙ ሰዓታት ሰርቷል።

የተገኘው የውሂብ ስብስብ 1 መዝገቦችን (ስም, qtype, TTL, የጊዜ ማህተም) ያካትታል. አጠቃላይ የቲቲኤል ስርጭት ይህ ነው (X-ዘንግ TTL በሰከንዶች ውስጥ ነው)

በ 86 (በአብዛኛው ለ SOA መዛግብት) ከትንሽ እብጠት በተጨማሪ ቲቲኤሎች በዝቅተኛ ክልል ውስጥ እንዳሉ በጣም ግልጽ ነው። እስቲ ጠለቅ ብለን እንመልከተው፡-

እሺ፣ ቲቲኤሎች ከ1 ሰዓት በላይ የሚበልጡ በስታቲስቲካዊነት ጉልህ አይደሉም። ከዚያ በ0-3600 ክልል ላይ እናተኩር፡-

አብዛኛዎቹ ቲቲኤሎች ከ0 እስከ 15 ደቂቃዎች ናቸው፡-

አብዛኛዎቹ ከ 0 እስከ 5 ደቂቃዎች ናቸው.

በጣም ጥሩ አይደለም.

ድምር ስርጭት ችግሩን የበለጠ ግልጽ ያደርገዋል፡-

ግማሹ የዲኤንኤስ ምላሾች TTL 1 ደቂቃ ወይም ከዚያ በታች፣ እና ሶስት አራተኛው TTL 5 ደቂቃዎች ወይም ከዚያ በታች አላቸው።

ቆይ ግን በእርግጥ የከፋ ነው። ከሁሉም በኋላ, ይህ TTL ከስልጣን አገልጋዮች ነው. ነገር ግን፣ የደንበኛ ፈላጊዎች (ለምሳሌ ራውተሮች፣ አካባቢያዊ መሸጎጫዎች) TTL ከበላይ ፈታሾች ይቀበላሉ እና በየሰከንዱ ይቀንሳል።

ስለዚህ ደንበኛው አዲስ ጥያቄ ከመላኩ በፊት በአማካይ እያንዳንዱን ግቤት ለዋናው ቲቲኤል ግማሽ ሊጠቀም ይችላል።

ምናልባት እነዚህ በጣም ዝቅተኛ ቲቲኤሎች ያልተለመዱ ጥያቄዎችን ብቻ እና ታዋቂ ድረ-ገጾችን እና ኤፒአይዎችን ላይሆኑ ይችላሉ? እስቲ እንመልከት፡-

የ X ዘንግ TTL ነው፣ የ Y ዘንግ የጥያቄ ተወዳጅነት ነው።

እንደ አለመታደል ሆኖ፣ በጣም ታዋቂዎቹ መጠይቆችም ለመሸጎጫ በጣም መጥፎ ናቸው።

እናሳድግ፡-

ፍርድ፡ በጣም መጥፎ ነው። ቀደም ሲል መጥፎ ነበር, ነገር ግን የበለጠ የከፋ ሆነ. የዲ ኤን ኤስ መሸጎጫ ምንም ፋይዳ የለውም። ጥቂት ሰዎች የአይኤስፒ ዲ ኤን ኤስ መፍቻቸውን ሲጠቀሙ (በጥሩ ምክንያቶች) የቆይታ መጨመር የበለጠ የሚታይ ይሆናል።

የዲ ኤን ኤስ መሸጎጫ ማንም የማይጎበኘው ይዘት ብቻ ጠቃሚ ሆኗል።

እባክዎን ሶፍትዌሩ ሊሆን እንደሚችል ልብ ይበሉ በተለያዩ መንገዶች ዝቅተኛ ቲቲኤሎችን መተርጎም.

ለምን?

ለምንድነው የዲኤንኤስ መዝገቦች ወደ ዝቅተኛ ቲቲኤል የተቀናበሩት?

የቆዩ የጭነት ማመላለሻዎች በነባሪ ቅንጅቶች ቀርተዋል።
የዲ ኤን ኤስ ጭነት ማመጣጠን በቲቲኤል ላይ የተመሰረተ ነው የሚሉ አፈ ታሪኮች አሉ (ይህ እውነት አይደለም - ከ Netscape Navigator ዘመን ጀምሮ ደንበኞቻቸው ከ RRs ስብስብ የዘፈቀደ የአይፒ አድራሻን መርጠዋል እና መገናኘት ካልቻሉ ሌላን በግልፅ ሞክረዋል)
አስተዳዳሪዎች ለውጦችን ወዲያውኑ መተግበር ይፈልጋሉ፣ ስለዚህ ለማቀድ ቀላል ነው።
የዲ ኤን ኤስ አገልጋይ ወይም የሎድ ሚዛን አስተዳዳሪ ስራውን ተጠቃሚዎች የሚጠይቁትን ውቅረት በብቃት ማሰማራት እንጂ ጣቢያዎችን እና አገልግሎቶችን እንደማያፋጥነው ይመለከተዋል።
ዝቅተኛ ቲቲኤሎች የአእምሮ ሰላም ይሰጡዎታል።
ሰዎች መጀመሪያ ላይ ዝቅተኛ ቲቲኤሎችን ለሙከራ አዘጋጅተው ከዚያ መቀየር ይረሳሉ።

በዝርዝሩ ውስጥ "አለመሳካትን" አላካተትኩም ምክንያቱም ከጊዜ ወደ ጊዜ አስፈላጊነቱ እየቀነሰ መጥቷል። ሁሉም ነገር ሲበላሽ የስህተት ገጽን ለማሳየት ተጠቃሚዎችን ወደ ሌላ አውታረ መረብ ማዞር ካስፈለገዎት ከ1 ደቂቃ በላይ መዘግየቱ ተቀባይነት ሊኖረው ይችላል።

በተጨማሪም፣ የአንድ ደቂቃ TTL ማለት ስልጣን ያላቸው የዲኤንኤስ አገልጋዮች ከ1 ደቂቃ በላይ ከታገዱ ማንም ሌላ ጥገኝነት ያለው አገልግሎት ማግኘት አይችልም። እና ምክንያቱ የውቅር ስህተት ወይም መጥለፍ ከሆነ ተደጋጋሚነት አይረዳም። በሌላ በኩል፣ በተመጣጣኝ ቲቲኤልዎች፣ ብዙ ደንበኞች የቀደመውን ውቅር መጠቀማቸውን ይቀጥላሉ እና ምንም ነገር አያስተውሉም።

የCDN አገልግሎቶች እና የጭነት ሚዛን ሰጪዎች ለዝቅተኛ ቲቲኤልዎች ተጠያቂ ናቸው፣በተለይ CNAMEsን ከዝቅተኛ ቲቲኤልዎች እና መዛግብት ጋር በተመሳሳይ ዝቅተኛ (ግን ገለልተኛ) 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

በማንኛውም ጊዜ CNAME ወይም ማንኛውም የ A መዝገቦች ጊዜው ሲያልቅ፣ አዲስ ጥያቄ መላክ አለበት። ሁለቱም 30 ሰከንድ ቲቲኤል አላቸው፣ ግን አንድ አይነት አይደለም። ትክክለኛው አማካኝ TTL 15 ሰከንድ ይሆናል።

ግን ቆይ! ከዚህም የባሰ ነው። አንዳንድ ፈታኞች በዚህ ሁኔታ ውስጥ ከሁለት ተያያዥ ዝቅተኛ ቲቲኤልዎች ጋር በጣም መጥፎ ባህሪ ያሳያሉ።

$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com 1 በCNAME github.map.fastly.net። github.map.ፈጣን.net. 1 በ A 151.101.16.133

የLevel3 ፈላጊው ምናልባት በ BIND ላይ ይሰራል። ይህን ጥያቄ መላኩን ከቀጠሉ፣ TTL 1 ሁልጊዜ ይመለሳል። በመሠረቱ፣ raw.githubusercontent.com መቼም አልተሸጎጠም።

በጣም ታዋቂ ከሆነው ጎራ ጋር እንደዚህ ያለ ሁኔታ ሌላ ምሳሌ ይኸውና፡

$ 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

ቢያንስ ሦስት የCNAME መዝገቦች። አይ. አንድ ጥሩ ቲቲኤል አለው፣ ግን ሙሉ በሙሉ ከንቱ ነው። ሌሎች CNAMEዎች የ60 ሰከንድ የመጀመሪያ ቲቲኤል አላቸው፣ ግን ለጎራዎች akamai.net ከፍተኛው TTL 20 ሰከንድ ነው እና አንዳቸውም በደረጃ አይደሉም።

ያለማቋረጥ የአፕል መሳሪያዎችን የሚመረምሩ ጎራዎችስ?

$ 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

እንደ ፋየርፎክስ እና ቲቲኤል ተመሳሳይ ችግር Level1 መፍታትን ሲጠቀሙ ብዙ ጊዜ በ3 ሰከንድ ውስጥ ይቆያሉ።

Dropbox?

$ መሰርሰሪያ client.dropbox.com @8.8.8.8 client.dropbox.com. 7 በCNAME ደንበኛ.dropbox-dns.com። ደንበኛ.dropbox-dns.com. 59 በ 162.125.67.3 $ መሰርሰሪያ ደንበኛ.dropbox.com @4.2.2.2 client.dropbox.com. 1 በCNAME ደንበኛ.dropbox-dns.com። ደንበኛ.dropbox-dns.com. 1 በ A 162.125.64.3

በቀረጻው ላይ safebrowsing.googleapis.com የቲቲኤል ዋጋ ልክ እንደ ፌስቡክ ጎራዎች 60 ሰከንድ ነው። እና, እንደገና, ከደንበኛው እይታ, እነዚህ እሴቶች በግማሽ ይቀንሳሉ.

ዝቅተኛ TTL ስለማዘጋጀትስ?

ስምን፣ የጥያቄ አይነትን፣ ቲቲኤልን እና በመጀመሪያ የተከማቸ የጊዜ ማህተም በመጠቀም፣ ጊዜው ባለፈበት የመሸጎጫ ግቤት ምክንያት የተላኩትን አላስፈላጊ የጥያቄዎች መጠን ለመገመት 1,5 ሚሊዮን ጥያቄዎችን በመሸጎጫ ፈላጊ ውስጥ የሚያልፉ ስክሪፕት ፃፍኩ።

47,4% ጥያቄዎች የተጠየቁት ነባር መዝገብ ካለቀ በኋላ ነው። ይህ ያለምክንያት ከፍ ያለ ነው።

ዝቅተኛው TTL ከተዋቀረ በመሸጎጥ ላይ ምን ተጽእኖ ይኖረዋል?

የ X ዘንግ ዝቅተኛው የቲቲኤል እሴቶች ነው። ከዚህ እሴት በላይ የምንጭ TTL ያላቸው መዝገቦች አይነኩም።

የY ዘንግ አስቀድሞ የተሸጎጠ ግቤት ካለው ደንበኛ የጥያቄዎች መቶኛ ነው፣ነገር ግን ጊዜው አልፎበታል እና አዲስ ጥያቄ እያቀረበ ነው።

ዝቅተኛውን TTL ወደ 47 ደቂቃዎች በማዘጋጀት የ"ተጨማሪ" ጥያቄዎች ድርሻ ከ 36% ወደ 5% ይቀንሳል። ዝቅተኛውን TTL ወደ 15 ደቂቃዎች በማዘጋጀት, የእነዚህ ጥያቄዎች ቁጥር ወደ 29% ይቀንሳል. ቢያንስ 1 ሰዓት TTL ወደ 17% ይቀንሳል. ጉልህ ልዩነት!

በአገልጋዩ በኩል ምንም ነገር አለመቀየር፣ ይልቁንስ በደንበኛ ዲ ኤን ኤስ መሸጎጫዎች (ራውተሮች፣ አካባቢያዊ ፈላጊዎች) ውስጥ ዝቅተኛውን TTL ማቀናበርስ?

የሚፈለጉት የጥያቄዎች ብዛት ከ47% ወደ 34% በትንሹ TTL 5 ደቂቃ፣ ወደ 25% በትንሹ 15 ደቂቃ እና ወደ 13% በትንሹ 1 ሰአት ይቀንሳል። ምናልባት 40 ደቂቃዎች በጣም ጥሩ ናቸው.

የዚህ ትንሽ ለውጥ ተጽእኖ በጣም ትልቅ ነው.

ውጤቱስ ምንድ ነው?

እርግጥ ነው, አገልግሎቱን ወደ አዲስ የደመና አቅራቢ, አዲስ አገልጋይ, አዲስ አውታረ መረብ, ደንበኞች የቅርብ ጊዜውን የዲ ኤን ኤስ መዝገቦችን መጠቀም ያስፈልገዋል. እና በትክክል ትንሽ ቲቲኤል እንዲህ ዓይነቱን ሽግግር በተቀላጠፈ እና በማይታወቅ ሁኔታ ለማድረግ ይረዳል። ነገር ግን ወደ አዲስ መሠረተ ልማት ሲሸጋገር፣ ደንበኞች በ1 ደቂቃ፣ 5 ደቂቃ ወይም 15 ደቂቃ ውስጥ ወደ አዲስ የዲኤንኤስ መዝገቦች እንዲሰደዱ ማንም አይጠብቅም። ዝቅተኛውን TTL ከ 40 ደቂቃዎች ይልቅ ወደ 5 ደቂቃዎች ማቀናበር ተጠቃሚዎች አገልግሎቱን እንዳይጠቀሙ አያግደውም.

ሆኖም፣ ይህ መዘግየትን በእጅጉ ይቀንሳል እና አላስፈላጊ ጥያቄዎችን በማስቀረት ግላዊነትን እና አስተማማኝነትን ያሻሽላል።

እርግጥ ነው፣ RFCs TTL በጥብቅ መከተል አለበት ይላሉ። እውነታው ግን የዲ ኤን ኤስ ስርዓት በጣም ውጤታማ ያልሆነ ሆኗል.

ስልጣን ካላቸው የዲ ኤን ኤስ አገልጋዮች ጋር እየሰሩ ከሆነ፣ እባክዎ የእርስዎን ቲቲኤልዎች ያረጋግጡ። በእውነቱ እንደዚህ ያሉ አስቂኝ ዝቅተኛ እሴቶች ያስፈልጉዎታል?

እርግጥ ነው, ለዲ ኤን ኤስ መዝገቦች ትናንሽ ቲቲኤልዎችን ለማዘጋጀት ጥሩ ምክንያቶች አሉ. ግን ለ 75% የዲ ኤን ኤስ ትራፊክ ማለት ይቻላል የማይለወጥ።

እና በሆነ ምክንያት ለዲ ኤን ኤስ ዝቅተኛ TTLዎችን መጠቀም ከፈለጉ በተመሳሳይ ጊዜ ጣቢያዎ መሸጎጫ እንዳልነቃ ያረጋግጡ። ለተመሳሳይ ምክንያቶች.

የሚያሄድ የአካባቢ የዲ ኤን ኤስ መሸጎጫ ካለዎት፣ ለምሳሌ dnscrypt-proxyአነስተኛውን TTL እንዲያዘጋጁ የሚፈቅድልዎ ይህንን ተግባር ይጠቀሙ። ይህ ጥሩ ነው። ምንም መጥፎ ነገር አይከሰትም. ዝቅተኛውን TTL ወደ 40 ደቂቃ (2400 ሰከንድ) እና 1 ሰዓት ያቀናብሩ። በጣም ምክንያታዊ ክልል።

ምንጭ: hab.com

ለአስቂኝ ዝቅተኛ TTL ለዲኤንኤስ መጠቀም ያቁሙ

ለምን?

ዝቅተኛ TTL ስለማዘጋጀትስ?

ውጤቱስ ምንድ ነው?