DNS latency နည်းပါးခြင်းသည် မြန်ဆန်စွာရှာဖွေခြင်းအတွက် အဓိကအချက်ဖြစ်သည်။ ၎င်းကို လျှော့ချရန်၊ DNS ဆာဗာများနှင့် ဂရုတစိုက်ရွေးချယ်ရန် အရေးကြီးပါသည်။ အမည်မသိ relay များ. ဒါပေမယ့် သင် ပထမဆုံးလုပ်ရမှာက အသုံးမဝင်တဲ့မေးခွန်းတွေကို ဖယ်ရှားလိုက်ပါ။

ထို့ကြောင့် DNS ကို မူလက အလွန်အမင်း ကက်ချနိုင်သော ပရိုတိုကောအဖြစ် ဒီဇိုင်းထုတ်ထားသည်။ ဇုန်စီမံခန့်ခွဲသူများသည် တစ်ဦးချင်းမှတ်တမ်းများအတွက် အသက်ရှင်ရန်အချိန် (TTL) ကို သတ်မှတ်ပေးပြီး ဖြေရှင်းသူများသည် မလိုအပ်သောအသွားအလာများကိုရှောင်ရှားရန် မှတ်ဉာဏ်တွင် မှတ်တမ်းများသိမ်းဆည်းသည့်အခါ ဤအချက်အလက်ကို အသုံးပြုသည်။

caching က ထိရောက်ပါသလား။ လွန်ခဲ့တဲ့ နှစ်အနည်းငယ်က ကျွန်တော့်ရဲ့ သုတေသနအသေးစားက အဲဒါက မပြည့်စုံဘူးဆိုတာ ပြသခဲ့တယ်။ လက်ရှိ အနေအထားကို ကြည့်ရအောင်။

အချက်အလက်စုဆောင်းရန်အတွက် ကျွန်ုပ်ပြင်ဆင်ထားပါသည်။ ကုဒ်ဝှက်ထားသော DNS ဆာဗာ တုံ့ပြန်မှုအတွက် TTL တန်ဖိုးကို သိမ်းဆည်းရန်။ အဝင်တောင်းဆိုမှုတစ်ခုစီအတွက် ၎င်းကို ၎င်း၏မှတ်တမ်းများ၏ အနည်းဆုံး TTL အဖြစ် သတ်မှတ်သည်။ ၎င်းသည် စစ်မှန်သောအသွားအလာများ၏ TTL ဖြန့်ဖြူးမှုကို ကောင်းမွန်သောခြုံငုံသုံးသပ်ချက်ပေးကာ တစ်ဦးချင်းတောင်းဆိုမှုများ၏ရေပန်းစားမှုကိုလည်း ထည့်သွင်းစဉ်းစားသည်။ ဆာဗာ၏ ဖာထေးထားသောဗားရှင်းသည် နာရီပေါင်းများစွာ အလုပ်လုပ်သည်။

ရလဒ်ဒေတာအတွဲတွင် 1 မှတ်တမ်းများ (အမည်၊ qtype၊ TTL၊ အချိန်တံဆိပ်) ပါဝင်သည်။ ဤသည်မှာ အလုံးစုံ TTL ဖြန့်ဖြူးခြင်းဖြစ်သည် (x-axis သည် TTL စက္ကန့်အတွင်းဖြစ်သည်)။

86 (အများစုမှာ SOA မှတ်တမ်းများအတွက်) အနည်းငယ် အဖုအထစ်မှလွဲ၍ TTL များသည် အနိမ့်ဆုံးအကွာအဝေးတွင် ရှိနေသည်ကို သိသာပါသည်။ အနီးကပ်ကြည့်ရအောင်-

အိုကေ၊ 1 နာရီကျော် TTL များသည် စာရင်းအင်းအရ အရေးမပါပါ။ ထို့နောက် 0-3600 အကွာအဝေးကို အာရုံစိုက်ကြပါစို့။

TTL အများစုသည် 0 နှင့် 15 မိနစ်အကြားဖြစ်သည်-

အများစုသည် 0 မှ 5 မိနစ်အထိဖြစ်သည်။

ဒါက သိပ်မကောင်းဘူး။

စုစည်းဖြန့်ဝေမှုသည် ပြဿနာကို ပိုမိုထင်ရှားစေသည်-

DNS တုံ့ပြန်မှုတစ်ဝက်သည် 1 မိနစ် သို့မဟုတ် ထိုထက်နည်းသော TTL ရှိပြီး လေးပုံသုံးပုံသည် 5 မိနစ် သို့မဟုတ် ထိုထက်နည်းသော TTL ရှိသည်။

ဒါပေမယ့် စောင့်ပါ၊ တကယ်ဆို ပိုဆိုးပါတယ်။ ဤသည်မှာ တရားဝင်ဆာဗာများမှ TTL ဖြစ်သည်။ သို့သော်လည်း၊ client ဖြေရှင်းသူများ (ဥပမာ- router များ၊ local caches) သည် upstream ဖြေရှင်းသူများထံမှ TTL ကို ရရှိပြီး စက္ကန့်တိုင်း လျော့နည်းသွားပါသည်။

ထို့ကြောင့်၊ client သည် တောင်းဆိုချက်အသစ်မပေးပို့မီ ပျမ်းမျှအားဖြင့် မူရင်း TTL တစ်ဝက်အတွက် မှတ်တမ်းတစ်ခုစီကို အမှန်တကယ် အသုံးပြုနိုင်သည်။

ဤအလွန်နည်းသော TTL များသည် ပုံမှန်မဟုတ်သော တောင်းဆိုမှုများနှင့်သာ သက်ဆိုင်ပြီး လူကြိုက်များသော ဝဘ်ဆိုက်များနှင့် API များတွင်သာ သက်ရောက်နိုင်ပါသလား။ တစ်ချက်ကြည့်လိုက်ရအောင်-

X-axis သည် TTL ဖြစ်ပြီး Y-axis သည် query popularity ဖြစ်သည်။

ကံမကောင်းစွာပဲ၊ ရေပန်းအစားဆုံးမေးခွန်းများသည် အဆိုးဆုံး ကက်ရှ်လည်းဖြစ်သည်။

ဇူးမ်ချဲ့ကြည့်ရအောင်-

စီရင်ချက်- တကယ်ကို ဆိုးပါတယ်။ ဆိုးနေပြီ၊ ပိုဆိုးလာပြီ။ DNS caching သည် လုံးဝ အသုံးမဝင်တော့ပါ။ လူအနည်းငယ်သည် ၎င်းတို့၏ ISP ၏ DNS ဖြေရှင်းပေးသူကို (အကြောင်းပြချက်ကောင်းအတွက်) အသုံးပြုလာသည်နှင့်အမျှ latency တိုးလာမှုသည် ပိုမိုသိသာလာသည်။

DNS caching သည် မည်သူမျှ ဝင်ကြည့်ခြင်းမရှိသော အကြောင်းအရာအတွက်သာ အသုံးဝင်ပါသည်။

ဆော့ဖ်ဝဲ ဖြစ်နိုင်ကြောင်းကိုလည်း သတိပြုပါ။ ကွဲပြားခြားနား နိမ့်သော TTL များကို အနက်ဖွင့်ပါ။

အဘယ်ကြောင့်ဤမျှ?

DNS မှတ်တမ်းများကို ဤကဲ့သို့သော TTL အသေးတစ်ခုအဖြစ် အဘယ်ကြောင့် သတ်မှတ်သနည်း။

• ဟောင်းနွမ်းနေသော ဝန်ချိန်ခွင်လျှာများကို ပုံသေဆက်တင်များဖြင့် ကျန်ခဲ့သည်။
• DNS load ချိန်ခွင်လျှာသည် TTL ပေါ်တွင်မူတည်သည်ဟု ဒဏ္ဍာရီများရှိပါသည်။ (၎င်းသည် မမှန်ပါ - Netscape Navigator ကြောင့်၊ clients များသည် RR set မှ ကျပန်း IP လိပ်စာကို ရွေးကာ ချိတ်ဆက်၍မရပါက နောက်တစ်ခုအား ပွင့်လင်းမြင်သာစွာ စမ်းကြည့်ပါ)
• စီမံခန့်ခွဲသူများသည် အပြောင်းအလဲများကို ချက်ချင်းအသုံးချလိုသောကြောင့် အစီအစဉ်ဆွဲရန် ပိုမိုလွယ်ကူပါသည်။
• DNS ဆာဗာ သို့မဟုတ် load balancer ၏ စီမံခန့်ခွဲသူသည် သုံးစွဲသူများ တောင်းဆိုထားသော ဖွဲ့စည်းမှုပုံစံကို ထိရောက်စွာ ဖြန့်ကျက်ပြီး ဝဘ်ဆိုက်များနှင့် ဝန်ဆောင်မှုများ၏ လည်ပတ်မှုကို အရှိန်မြှင့်ခြင်းအဖြစ် မြင်သည်။
• နိမ့်သော TTL သည် စိတ်ငြိမ်သက်မှုကို ပေးသည်။
• လူများသည် စမ်းသပ်ရန်အတွက် TTL များကို ကနဦးတွင် နိမ့်ကျသည်ဟု သတ်မှတ်ပြီးနောက် ၎င်းတို့ကို ပြောင်းလဲရန် မေ့သွားကြသည်။

ဆီလျော်မှုနည်းလာသောကြောင့် "failover" မပါဝင်ပါ။ အခြားအရာအားလုံးပျက်သွားသောအခါ အမှားစာမျက်နှာကိုပြသရန် သုံးစွဲသူများအား အခြားကွန်ရက်သို့ ပြန်ညွှန်းရန် လိုအပ်ပါက၊ 1 မိနစ်ထက်ပိုသော နှောင့်နှေးမှုကို လက်ခံနိုင်ဖွယ်ရှိသည်။

ထို့အပြင်၊ တစ်မိနစ် TTL ဆိုသည်မှာ တရားဝင် DNS ဆာဗာများကို 1 မိနစ်ထက်ပို၍ ပိတ်ဆို့ထားလျှင် အခြားမည်သူမျှ မှီခိုနေသော ဝန်ဆောင်မှုများကို ဝင်ရောက်ကြည့်ရှုနိုင်မည်မဟုတ်ကြောင်း ဆိုလိုသည်။ အကြောင်းရင်းသည် ဖွဲ့စည်းမှုဆိုင်ရာ အမှားအယွင်း သို့မဟုတ် ဟက်ခ်ဖြစ်လျှင် ထပ်လောင်းခြင်းမှာ အထောက်အကူမဖြစ်ပါ။ အခြားတစ်ဖက်တွင်၊ ကျိုးကြောင်းဆီလျော်သော TTLs များဖြင့်၊ သုံးစွဲသူအများအပြားသည် ယခင်ဖွဲ့စည်းပုံကို ဆက်လက်အသုံးပြုမည်ဖြစ်ပြီး မည်သည့်အခါမျှ သတိမထားမိပါ။

နိမ့်သော TTL များသည် CDN ဝန်ဆောင်မှုများနှင့် load balancers များ၏ အမှားအယွင်းများဖြစ်ပြီး အထူးသဖြင့် ၎င်းတို့သည် CNAME များကို TTL နည်းပါးသော မှတ်တမ်းများနှင့် အညီအမျှနိမ့် (သို့သော်လည်း သီးခြား) TTLs များနှင့် ပေါင်းစပ်သောအခါ-

$ 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 ရှိသည်၊ သို့သော် ၎င်းတို့သည် တူညီသည်မဟုတ်။ ပျှမ်းမျှ TTL သည် 15 စက္ကန့်ဖြစ်သည်။

ဒါပေမယ့် ခဏစောင့်! ပိုဆိုးလာသည်။ အချို့သော ဖြေရှင်းသူများသည် ဤအခြေအနေတွင် ချိတ်ဆက်ထားသော TTL နည်းပါးသော နှစ်ခုဖြင့် အလွန်ဆိုးရွားစွာ ပြုမူကြသည်-

$drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com။ 1 CNAME တွင် github.map.fastly.net။ github.map.fastly.net ။ 1 IN A 151.101.16.133

Level3 ဖြေရှင်းသူသည် BIND တွင် လုပ်ဆောင်နေနိုင်သည် ။ အကယ်၍ သင်သည် ဤမေးခွန်းကို ဆက်လက်ပေးပို့ပါက၊ ၎င်းသည် 1 ၏ TTL ကို အမြဲတမ်း ပြန်ပေးလိမ့်မည်။ အဓိကအားဖြင့်၊ 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 မှတ်တမ်းသုံးခု။ အိုး တစ်ခုတွင် ကောင်းမွန်သော TTL ရှိသည်၊ သို့သော် ၎င်းသည် လုံးဝ အသုံးမဝင်ပါ။ အခြား CNAME များတွင် ကနဦး TTL စက္ကန့် 60 ရှိသည်၊ သို့သော် ဒိုမိန်းများအတွက် akamai.net အမြင့်ဆုံး TTL သည် စက္ကန့် 20 ဖြစ်ပြီး ၎င်းတို့ထဲမှ တစ်ခုမျှ အဆင့်တွင်မရှိပါ။

Apple စက်ပစ္စည်းများကို အဆက်မပြတ် စစ်တမ်းကောက်ယူသည့် ဒိုမိန်းများကော။

$ 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

Firefox နှင့် TTL ကဲ့သို့ ပြဿနာသည် Level1 ဖြေရှင်းသူကို အသုံးပြုသည့်အခါ အများစုတွင် 3 စက္ကန့်တွင် ရပ်တန့်သွားမည်ဖြစ်သည်။

Dropbox လား?

$drill client.dropbox.com @8.8.8.8 client.dropbox.com ။ 7 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 CNAME client.dropbox-dns.com တွင်။ client.dropbox-dns.com 1 IN A 162.125.64.3

ရိုက်ကူးရေးမှာ safebrowsing.googleapis.com Facebook ဒိုမိန်းများကဲ့သို့ စက္ကန့် 60 တန် TTL တန်ဖိုး။ နောက်တဖန်၊ client ၏ရှုထောင့်မှ၊ ဤတန်ဖိုးများကို ထက်ဝက်လျှော့ချသည်။

အနည်းဆုံး TTL ကို ဘယ်လို သတ်မှတ်မလဲ။

အမည်၊ တောင်းဆိုမှုအမျိုးအစား၊ TTL နှင့် မူလသိမ်းဆည်းထားသည့် အချိန်တံဆိပ်ကို အသုံးပြု၍ သက်တမ်းကုန်ဆုံးသွားသော ကက်ရှ်ဝင်ရောက်မှုကြောင့် ပေးပို့သည့် အပိုတောင်းဆိုချက်ပမာဏကို ခန့်မှန်းရန် ကက်ရှ်ဖြေရှင်းရေးစနစ်မှတစ်ဆင့် တောင်းဆိုချက်ပေါင်း 1,5 သန်းကို အတုယူရန် ဇာတ်ညွှန်းတစ်ခုကို ရေးသားခဲ့သည်။

လက်ရှိ မှတ်တမ်း သက်တမ်းကုန်ပြီးနောက် တောင်းဆိုမှု၏ 47,4% ကို ပြုလုပ်ခဲ့သည်။ ဒါက ယုတ္တိမတန်ဘူး။

အနိမ့်ဆုံး TTL ကို သတ်မှတ်ပါက ကက်ရှ်လုပ်ခြင်းအပေါ် မည်သို့အကျိုးသက်ရောက်မှုရှိမည်နည်း။

X-axis သည် အနည်းဆုံး TTL တန်ဖိုးများဖြစ်သည်။ ဤတန်ဖိုးအထက် TTL ကြမ်းများဖြင့် မှတ်တမ်းများကို ထိခိုက်မည်မဟုတ်ပါ။

Y ဝင်ရိုးသည် ကက်ရှ်ထည့်သွင်းထားပြီးဖြစ်သည့် သုံးစွဲသူတစ်ဦးထံမှ တောင်းဆိုချက်ရာခိုင်နှုန်းဖြစ်သော်လည်း ၎င်းသည် သက်တမ်းကုန်သွားကာ တောင်းဆိုချက်အသစ်တစ်ခု ပြုလုပ်နေသည်။

အနိမ့်ဆုံး TTL ကို 47 မိနစ်အထိ သတ်မှတ်ရုံဖြင့် "အပို" တောင်းဆိုမှုများ၏ ဝေစုကို 36% မှ 5% သို့ လျှော့ချသည်။ အနိမ့်ဆုံး TTL ကို 15 မိနစ်အထိ သတ်မှတ်ခြင်းသည် ဤတောင်းဆိုမှုအရေအတွက်ကို 29% သို့ လျှော့ချပေးသည်။ အနည်းဆုံး 1 နာရီ၏ TTL သည် ၎င်းတို့အား 17% သို့ လျှော့ချပေးသည်။ သိသာထင်ရှားသောခြားနားချက်။

ဆာဗာဘက်တွင် မည်သည့်အရာကိုမျှ မပြောင်းလဲဘဲ၊ client DNS ကက်ရှ်များ (routers၊ local solutionrs) တွင် အနည်းဆုံး TTL များကို သတ်မှတ်ခြင်းအစား၊

အနည်းဆုံး TTL ကို 47 မိနစ်၊ အနည်းဆုံး 34 မိနစ်မှ 5% နှင့် အနည်းဆုံး 25 နာရီဖြင့် 15% သို့ သတ်မှတ်သောအခါ လိုအပ်သော တောင်းဆိုမှုအရေအတွက်သည် 13% မှ 1% သို့ ကျဆင်းသွားသည်။ မိနစ် 40 သည် အကောင်းဆုံးဖြစ်နိုင်သည်။

ဤအနည်းငယ်သောပြောင်းလဲမှု၏ သက်ရောက်မှုသည် ကြီးမားသည်။

အကျိုးဆက်တွေက ဘာတွေလဲ။

သေချာပါသည်၊ သင်သည် ဝန်ဆောင်မှုတစ်ခုအား cloud ဝန်ဆောင်မှုပေးသူအသစ်၊ ဆာဗာအသစ်၊ ကွန်ရက်အသစ်တစ်ခုထံသို့ ပြောင်းရွှေ့နိုင်ပြီး သုံးစွဲသူများ၏ နောက်ဆုံး DNS မှတ်တမ်းများကို အသုံးပြုရန် လိုအပ်ပါသည်။ သေးငယ်သော TTL သည် ထိုအပြောင်းအလဲကို ချောမွေ့ချောမွေ့စေပါသည်။ သို့သော် သင်အခြေခံအဆောက်အအုံအသစ်သို့ ပြောင်းရွှေ့သည့်အခါ၊ သုံးစွဲသူများသည် DNS မှတ်တမ်းအသစ်သို့ 1 မိနစ်၊ 5 မိနစ် သို့မဟုတ် 15 မိနစ်အတွင်း ပြောင်းရွှေ့ရန် မည်သူမျှ မျှော်လင့်မည်မဟုတ်ပါ။ အနိမ့်ဆုံး TTL ကို 40 မိနစ်အစား မိနစ် 5 သို့ သတ်မှတ်ခြင်းသည် အသုံးပြုသူများ ဝန်ဆောင်မှုကို ဝင်ရောက်ခြင်းမှ တားဆီးမည်မဟုတ်ပါ။

သို့သော်၊ ၎င်းသည် ကြာမြင့်ချိန်ကို သိသိသာသာ လျှော့ချပြီး မလိုအပ်သော တောင်းဆိုမှုများကို ရှောင်ရှားခြင်းဖြင့် ကိုယ်ရေးကိုယ်တာနှင့် ယုံကြည်စိတ်ချရမှုကို တိုးတက်စေသည်။

ဟုတ်ပါတယ်၊ RFCs တွေက TTL တွေကို တင်းတင်းကျပ်ကျပ် ကျင့်သုံးသင့်တယ်လို့ ပြောကြပါတယ်။ ဒါပေမယ့် တကယ့်လက်တွေ့မှာ DNS စနစ်ဟာ ထိရောက်မှု မရှိသလောက်ပါပဲ။

အကယ်၍ သင်သည် တရားဝင် DNS ဆာဗာများနှင့် အလုပ်လုပ်နေပါက၊ ကျေးဇူးပြု၍ သင်၏ TTLs ကို စစ်ဆေးပါ။ ဒီလို ရယ်စရာကောင်းတဲ့ နိမ့်ကျတဲ့ တန်ဖိုးတွေကို သင် အမှန်တကယ် လိုအပ်ပါသလား။

DNS မှတ်တမ်းများအတွက် TTL ငယ်များကို သတ်မှတ်ရန် အကြောင်းပြချက်ကောင်းများရှိပါသည်။ သို့သော် ပြောင်းလဲရုံသာရှိသော DNS အသွားအလာ၏ 75% အတွက် မဟုတ်ပါ။

အကယ်၍ သင်သည် အကြောင်းတစ်ခုခုကြောင့် DNS အတွက် TTL များကို အမှန်တကယ် လိုအပ်ပါက၊ သင့် site တွင် caching enabled မရှိကြောင်း သေချာပါစေ။ တူညီသောအကြောင်းပြချက်များအတွက်။

အကယ်၍ သင့်တွင်၊ ထိုကဲ့သို့သော ဒေသန္တရ DNS ကက်ရှ်တစ်ခု လည်ပတ်နေပါက၊ dnscrypt-proxyအနည်းဆုံး TTL ကို သတ်မှတ်ခွင့်ပြုသည့် ဤလုပ်ဆောင်ချက်ကို အသုံးပြုပါ။ ဒါက ပုံမှန်ပါပဲ။ မကောင်းတာ ဘာမှဖြစ်မလာဘူး။ အနိမ့်ဆုံး TTL ကို မိနစ် 40 (2400 စက္ကန့်) နှင့် 1 နာရီကြားတွင် သတ်မှတ်ပေးပါ။ ရှိသင့်ရှိထိုက်တဲ့အပိုင်း။

source: www.habr.com