ใครเป็นผู้ดำเนินการ 1.1.1.1? การตรวจสอบที่อยู่ DNS ก่อนจะเชื่อถือ
ที่อยู่ DNS ที่ใช้ร่วมกับ VPN ไม่จำเป็นต้องดำเนินการโดย VPN นั้น ระบุตัวรีโซลเวอร์ แล้วตรวจสอบเส้นทางและนโยบายชื่อส่วนตัวแยกกัน
คุณวาง 1.1.1.1 ลงในช่อง DNS ของ VPN หน้าเว็บโหลดได้ และตอนนี้บทแนะนำดูเหมือนจะได้รับการยืนยันแล้ว ข้อสังเกตนั้นแคบกว่าที่รู้สึก: แอปพลิเคชันทำงานต่างออกไป และการเปลี่ยนแปลงยังไม่ได้บอกอะไรเกี่ยวกับใครที่ตอบคำถามหรือทำไมการตั้งค่าเดิมจึงล้มเหลว บทแนะนำที่คัดลอกกันมามักเรียกที่อยู่สาธารณะที่คุ้นเคยว่า “DNS ของ VPN” ซึ่งเป็นการอ้างสิทธิ์เกี่ยวกับความเป็นเจ้าของ ไม่ใช่การเข้าถึง การตรวจสอบว่าที่อยู่แทนอะไรใช้เวลาห้านาทีและป้องกันการเปลี่ยนแปลงถาวรที่ทำด้วยเหตุผลผิด
การตั้งค่าที่ใช้งานได้ไม่ใช่ตัวตน
ที่อยู่ในช่องตั้งค่าเป็นจุดปลายทาง และจุดปลายทางมีผู้ดำเนินการ ข้อเท็จจริงสองข้อนี้แยกจากกัน และข้อที่สองคือข้อที่ผู้คนข้ามไป สำหรับคู่ที่ถูกคัดลอกบ่อยที่สุด คำตอบเป็นสาธารณะ: Cloudflare เผยแพร่ 1.1.1.1 และ 1.0.0.1 เป็นที่อยู่รีโซลเวอร์ของตน และแสดงรายการไว้ในเอกสารอ้างอิงที่อยู่ทางการของตน นั่นคือเหตุผลที่ชื่อผู้ดำเนินการอยู่ข้างที่อยู่ ไม่ใช่ในบทแนะนำแยกต่างหาก
การป้อนคู่นั้นขณะอุโมงค์ทำงานไม่ได้ทำให้บริษัท VPN เป็นผู้ดำเนินการและไม่ได้ทำให้ทราฟฟิกไม่ระบุตัวตน คำถามออกจากเครื่องของคุณไปยังบริษัทที่เผยแพร่ช่วงที่อยู่ และบริษัทนั้นอาจมีชื่อเสียงแต่ก็ยังอาจไม่ใช่ฝ่ายที่บทแนะนำสื่อถึง ป้ายกำกับในคำแนะนำกับผู้ดำเนินการในความเป็นจริงเป็นการอ้างสองอย่างที่ต่างกัน ทั้งสองไม่ได้บอกว่าใครดำเนินการเส้นทางเครือข่ายในระหว่างนั้น
ใช้เอกสารอ้างอิงที่เผยแพร่ของรีโซลเวอร์เองเพื่อยืนยันคู่ที่อยู่หรือจุดปลายทางที่เข้ารหัส คำแนะนำจากผู้ให้บริการรายอื่นอาจชอบด้วยกฎหมาย และ “แนะนำโดย” “เข้าถึงผ่าน” และ “ดำเนินการโดย” ยังคงอธิบายความสัมพันธ์สามแบบที่ต่างกัน
เปรียบเทียบสามสิ่งที่บันทึกต้องการ
บันทึกที่พร้อมสำหรับการทบทวนแยกคำถามสามข้อ: ใครควรได้รับคำถาม การแลกเปลี่ยนเป็นข้อความธรรมดาหรือเข้ารหัส และเส้นทางใดควรพามันไป ชื่อผู้ให้บริการไม่สามารถเติมข้อที่สองหรือสามได้ และป้ายประเทศไม่สามารถเติมได้สักข้อ เขียนรายการทั้งสามก่อนการเปลี่ยนแปลงและเปรียบเทียบหลังจากนั้น รายการเหล่านั้นแลกเปลี่ยนกันไม่ได้ และการปฏิบัติต่อมันเป็นหนึ่งเดียวคือวิธีที่การคาดเดากลายเป็นเอกสาร
การเปรียบเทียบคือสิ่งที่เปลี่ยนการตั้งค่าที่ใช้งานได้ให้เป็นการตัดสินใจที่บันทึกไว้ หากไม่มี คนถัดไปจะได้รับที่อยู่โดยไม่มีเหตุผลแนบมาด้วย อ่านคอลัมน์ที่สามของตารางด้านล่างก่อน เพราะนั่นคือที่ที่คำอธิบายที่มั่นใจส่วนใหญ่หยุดลงจริง
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
ตารางสั้นโดยเจตนา ประเด็นคือแต่ละรายการตอบคำถามต่างกัน และไม่มีช่องเดียวที่เติมครบทั้งสาม
ตัวส่งต่อภายในซ่อนแหล่งที่มาจริง
อุปกรณ์ที่ตั้งให้ใช้เราเตอร์เป็น DNS กำลังชี้ไปยังตัวส่งต่อ ที่อยู่นั้นระบุผู้รับถัดไปของคำถาม ไม่ใช่รีโซลเวอร์ที่ตอบในที่สุด รีโซลเวอร์สตับภายในเพิ่มขั้นตอนพิเศษเดียวกัน และเป็นการง่ายที่จะสับสนกับของจริงเพราะมันปรากฏในทุกเอาต์พุตสถานะ
สตับส่งต่อไปยังแหล่งที่เอาต์พุตเดียวกันก็แสดงรายการด้วย โดยปกติอยู่ต่ำลงไป อ่านทั้งห่วงโซ่ก่อนสรุปอะไรเกี่ยวกับผู้ดำเนินการ เพราะบรรทัดแรกไม่ใช่คำตอบทั้งหมด มิฉะนั้นคุณกำลังเรียกแผนกต้อนรับว่าบริษัท
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'คำสั่งที่สองใช้ชื่อสะท้อนของรีโซลเวอร์ ในที่ที่ผู้ดำเนินการเผยแพร่ชื่อนั้น เพื่อรายงานที่อยู่ต้นทางที่มันเห็น คำสั่งที่สามระบุเซิร์ฟเวอร์ที่ตอบ ซึ่งมักไม่ใช่ที่อยู่ที่คุณกำหนดค่า เปรียบเทียบทั้งสามเอาต์พุตก่อนจดบันทึกผู้ดำเนินการ
DNS ที่เข้ารหัสเปลี่ยนสิ่งที่มองเห็น ไม่ใช่ใครที่มองเห็น
DNS over HTTPS และ DNS over TLS ปกป้องการแลกเปลี่ยนระหว่างไคลเอนต์กับรีโซลเวอร์ รีโซลเวอร์ยังคงอ่านทุกชื่อที่มีการถาม เพราะการตอบคือหน้าที่ สิ่งที่เปลี่ยนคือใครสามารถเฝ้าดูการแลกเปลี่ยนได้: เครือข่ายภายในเห็นการเชื่อมต่อกับจุดปลายทางหนึ่งจุดแทนที่จะเป็นกระแสคำถามแบบข้อความธรรมดา
สิ่งที่ไม่เปลี่ยนคือความสัมพันธ์แบบความไว้วางใจ ซึ่งยังชี้ไปที่องค์กรที่ดำเนินการจุดปลายทางนั้น เบราว์เซอร์ที่มีการตั้งค่า DNS ที่ปลอดภัยของตัวเองสามารถข้ามรีโซลเวอร์ของระบบปฏิบัติการได้ทั้งหมด มองทั้งสองเป็นการกำหนดค่าสองชุดที่อาจไม่ตรงกัน ไม่ใช่การตั้งค่าเดียวที่ใช้สองครั้ง
ชื่อส่วนตัวต้องการการตัดสินใจของตัวเองอีกครั้ง อุโมงค์งานอาจกำหนดเส้นทางโดเมนที่เลือกไปยังรีโซลเวอร์ขององค์กร และการแทนที่ด้วยบริการสาธารณะอาจทำให้การค้นหาภายในเสียหรือเปิดเผยชื่อภายในให้ฝ่ายผิด ตรวจสอบนโยบายโดเมนก่อนแทนที่การตั้งค่าของอะแดปเตอร์ทั้งตัว
รักษาข้อสังเกตให้แคบ
เมื่อเปรียบเทียบ ให้รักษาการกำหนดค่าเดิมและเปลี่ยนการตั้งค่าทีละอย่าง บันทึกแอปพลิเคชัน การดำเนินการ นโยบายรีโซลเวอร์ และว่าชื่อสาธารณะกับชื่อส่วนตัวที่อนุญาตยังแก้ไขได้หลังเชื่อมต่อใหม่หรือไม่ การเปรียบเทียบที่มีสองการเปลี่ยนแปลงไม่ได้พิสูจน์สักอย่าง เขียนผลลัพธ์ในที่ที่คนถัดไปจะหาเจอ ข้างการตั้งค่าเอง
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comหากแอปพลิเคชันเริ่มทำงาน ให้รักษาข้ออ้างให้เล็กเท่าที่หลักฐานอนุญาต การเปลี่ยนแปลงนั้นช่วยในการทดสอบหนึ่งครั้ง และไม่ได้บอกอะไรว่าผู้ดำเนินการรายก่อนกระทำโดยสุจริตใจหรือไม่ อุโมงค์เสียหรือไม่ หรืออุปกรณ์อื่นต้องการการแทนที่แบบเดียวกันหรือไม่ ผลลัพธ์ที่ยั่งยืนคือการกำหนดค่าที่คุณอธิบายผู้ดำเนินการและวัตถุประสงค์ได้