ການວາງ resolver ພາຍໃນກ່ອນ ແລະ resolver ສາທາລະນະຕໍ່ໄປ ບໍ່ໄດ້ບອກ Squid ວ່າຊື່ໃດເປັນຂອງ namespace ໃດ.

ໃນ Squid 6 ແລະ 7, dns_nameservers ແທນລາຍການ resolver ປົກກະຕິດ້ວຍທີ່ຢູ່ເຊີບເວີ. ໄວຍາກອນຂອງມັນບໍ່ມີການແຜງຕາມໂດເມນ. ຄຳຕອບທາງລົບທີ່ຖືກຕ້ອງກໍແຕກຕ່າງຈາກ resolver ທີ່ເຂົ້າບໍ່ໄດ້, ດັ່ງນັ້ນທາງເລືອກອື່ນບໍ່ແມ່ນວິທີທີ່ໜ້າເຊື່ອຖືໃນການຄົ້ນຫາ namespace ທີ່ບໍ່ສອດຄ່ອງ.

ເສັ້ນທາງຄຳຖາມຕາມໂດເມນ

ຕົວສົ່ງ DNS ທ້ອງຖິ່ນສາມາດສະແດງນະໂຍບາຍທີ່ຂາດ. ໃນການຕັ້ງຄ່າ dnsmasq ທີ່ມີຢູ່, suffix ສ່ວນຕົວສາມາດເສັ້ນທາງໄດ້ດັ່ງນີ້:

server=/internal.example/192.0.2.53

ປ່ຽນໂດເມນ ແລະ ທີ່ຢູ່. ຕັ້ງຄ່າ upstream ເລີ່ມຕົ້ນທີ່ໄດ້ຮັບອະນຸມັດສຳລັບຊື່ອື່ນ, ຕົວຮັບຟັງທີ່ເໝາະສົມ ແລະ ຂໍ້ຈຳກັດການເຂົ້າ. ຈາກນັ້ນຊີ້ Squid ໄປຫາ resolver ນັ້ນດ້ວຍການຕັ້ງຄ່າທີ່ເວີຊັນທີ່ຕິດຕັ້ງຮອງຮັບ.

ທາງເລືອກອື່ນ, ໃຊ້ບໍລິການ DNS ຂອງອົງກອນທີ່ແກ້ໄຂ namespace ທັງສອງຢ່າງຖືກຕ້ອງ. ຫຼີກລ້ຽງການຖອຍກັບສາທາລະນະທີ່ເປີດເຜີຍຊື່ສ່ວນຕົວໂດຍຕອບບໍ່ໄດ້.

ຖ້າ proxy ແມ່ເຮັດການຄົ້ນຫາປາຍທາງ, ຂັ້ນຕອນນັ້ນຕ້ອງການ namespace ສ່ວນຕົວ. resolver ເທິງໂຮສ Squid ທ້ອງຖິ່ນຈະບໍ່ແກ້ການຄົ້ນຫາຂອງ proxy ແມ່.

ກວດກໍລະນີທາງລົບນຳ

ເລືອກຊື່ສ່ວນຕົວທີ່ຖືກຕ້ອງ, ຊື່ສາທາລະນະທີ່ຖືກຕ້ອງ ແລະ ຊື່ສ່ວນຕົວທີ່ບໍ່ມີ. ສຳລັບແຕ່ລະອັນ, ກຳນົດ upstream ທີ່ຕັ້ງໃຈ ແລະ ວ່າຄຳຕອບທີ່ຄາດຫວັງເປັນທີ່ຢູ່ ຫຼື ຄຳຕອບທາງລົບ. ກໍລະນີສຸດທ້າຍເຜີຍໃຫ້ເຫັນການຖອຍກັບສາທາລະນະໂດຍບໍ່ໄດ້ຕັ້ງໃຈຫຼັງຄຳຕອບທາງລົບພາຍໃນ.

ລວມຄອບຄົວທີ່ຢູ່ທີ່ລູກຄ້າຕ້ອງການ. ການຄົ້ນຫາ A ທີ່ເຮັດວຽກບໍ່ໄດ້ພິສູດວ່າ AAAA ປະຕິບັດຕາມນະໂຍບາຍ ຫຼື ສົ່ງຄືນປາຍທາງທີ່ເຂົ້າເຖິງໄດ້. ສັງເກດສະຖານະ cache ນຳ: ຄຳຕອບທີ່ເກັບໄວ້ອາດປິດບັງວ່າຄຳຖາມໃໝ່ຈະເລືອກ upstream ໃດ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ