dig @resolver.example -p 443 +tcp သည် TCP မှတစ်ဆင့် ပေါ့ 443 သို့ DNS မေးခွန်း ပို့သည်။ ၎င်းသည် DNSCrypt ကို ညှိနှိုင်းခြင်း မပြုပါ။

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

အပေါ်ဘက်သို့ ကုဒ်ဝှက်ထားသော ဆက်သွယ်မှုအတွက် DNSCrypt ကို နားလည်သော resolver အစိတ်အပိုင်းကို အသုံးပြုပါ။ ၎င်းသည် ဒေသတွင်း သာမန် DNS မျက်နှာပြင်ကို ပေးပါက သမားရိုးကျ DNS အကူသည် မှတ်တမ်းတင်ထားသော လိပ်စာနှင့် ပေါ့ဖြင့် မေးနိုင်သည်။

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

ဤကွဲပြားမှုသည် DNS over HTTPS နှင့် DNS over TLS အတွက်လည်း သက်ဆိုင်သည်။ dig အတွင်း ပေါ့နံပါတ် ပြောင်းခြင်းသည် ပရိုတိုကော အဒက်ပ်တာ မဟုတ်ပါ။ HTTP အခြေခံ မျက်နှာပြင်အခြားအတွက် Google Public DNS သို့ HTTPS JSON မေးခွန်း ကို အသုံးပြုပါ။ အချိန်ကုန်ဆုံးမှုကို နောက်ထပ် ပျက်နေသော SOCKS ဆာဗာအဖြစ် မကောက်ချက်ချမီ endpoint ၏ စာချုပ်ကို စစ်ဆေးပါ။

ဆက်စပ်ဆောင်းပါးများ