HTTP ပရောက်စီကွင်းဆက်၌ DNS ချို့ယွင်းမှုများ− မည်သည့်အဆင့်က အမည်ကို ဖြေရှင်းသနည်း

client → local forward proxy → HTTP parent → website

DNS အားလုံးသည် “ပရောက်စီ” ၏ဖြစ်သည်ဟု မဆိုဘဲ မအောင်မြင်သော အမည်မှ စတင်ပါ−

အဆုံးမှတ်များသည် ဟို့စ်အမည်များဖြစ်ပါက ထိုအဆင့်များသည် မတူညီသော ရီဇော်လာများကို အသုံးပြုနိုင်သည်။ HTTPS အတွက် ဖော်ဝါဒ်ပရောက်စီသည် CONNECT ၏ ဦးတည်ဟို့စ်နှင့် ပို့ကို မိဘထံ ပေးပို့နိုင်ပြီး မိဘက နောက်ဆုံးချိတ်ဆက်မှုကို ပြုလုပ်သည်။ မူလကလိုင်းယန့်သည် ဝက်ဘ်ဆိုက်ကို ဦးစွာ ဖြေရှင်းရန် မလိုအပ်ပါ။ သာမန် HTTP ပေးပို့မှုသည်လည်း ဦးတည်အချက်အလက်များကို ရှေ့သို့ သယ်ဆောင်သည်။

ဤသည် အမည်တိုင်းကို စက်တစ်လုံးတည်းက မေးမည်ဟု ကတိမဟုတ်ပါ။ ACL အကဲဖြတ်မှု၊ ကက်ရှ်၊ မူဝါဒနှင့် အကောင်အထည်ဖော်မှု အသေးစိတ်များက ထပ်ဆောင်း ရှာဖွေမှုများ ဖြစ်စေနိုင်သည်။

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

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