เข้ารหัสไว้ ให้ปลอดภัย: การทำงานกับ ESNI, DoH และ DoT

การพัฒนาล่าสุดในการปกป้องความเป็นส่วนตัวบนอินเทอร์เน็ต ได้แก่ การบ่งชี้ชื่อเซิร์ฟเวอร์ TLS ที่เข้ารหัส (ESNI) และ DNS ที่เข้ารหัสในรูปแบบของ DNS ผ่าน HTTPS (DoH) ซึ่งทั้งสองอย่างนี้ถือเป็นข้อขัดแย้งอย่างมากจากผู้รวบรวมข้อมูล

มาดูเหตุผลคร่าวๆ ว่าทำไมถึงมีอยู่ รายละเอียดเกี่ยวกับที่มา และเทคโนโลยีเบื้องหลังการทำงาน

DNS จำเป็นต้องทำงาน อย่างถูกต้อง

การเชื่อมต่อเครือข่ายส่วนตัวเสมือนแบบอุโมงค์แยก (VPN), โปรโตคอลการค้นหาอัตโนมัติของเว็บพร็อกซี (WPAD), DNS มัลติคาสต์ที่ไม่มีการกำหนดค่าเป็นศูนย์, บัญชีดำแบบเรียลไทม์ (RBL) และเทคโนโลยีที่ใช้งานกันอย่างแพร่หลายอื่น ๆ อีกมากมายจะพังเมื่อ DNS ไม่ ทำงานได้อย่างถูกต้อง

ทำลายอินเทอร์เน็ตเพื่อผลกำไรและชื่อเสียง

ย้อนกลับไปในปี 2546 ผู้ใช้อินเทอร์เน็ตได้เรียนรู้เกี่ยวกับความสำคัญของ DNS ในระดับโลก เมื่อบริษัทซึ่งเรียกใช้โดเมนระดับบนสุด .com (TLD) ของ .com เลือกที่จะหยุดการออกการตอบสนองของ NXDOMAIN พวกเขา แอบอ้างเป็น โดเมนที่ไม่มีอยู่จริงเพื่อพยายามแสดงโฆษณามากขึ้น ขายโดเมนมากขึ้น และสร้างรายได้มากขึ้นในท้ายที่สุด ผลกระทบที่ไม่คาดคิดส่งผลให้เกิดการอภิปรายสาธารณะและรายงานที่น่าอับอายจากคณะกรรมการที่ปรึกษาด้านความปลอดภัยและเสถียรภาพของ ICANN (SSAC) โครงการนี้ปิดตัวลงจริงๆ แต่จากมุมมองทางเทคนิค ช่องโหว่ยังคงมีอยู่

ต่อมาในปี 2551 ความพยายามอีกครั้งในการจัดการ DNS เพื่อผลกำไรถูกเปิดเผยต่อสาธารณะเมื่อผู้ให้บริการอินเทอร์เน็ตรายใหญ่ที่สุดบางรายได้แนะนำช่องทางต่างๆ สำหรับการโจมตีแบบสคริปต์ข้ามไซต์กับเว็บไซต์ ใดๆ อย่าง แท้จริง เนื่องจากลักษณะของช่องโหว่ แม้แต่เว็บไซต์ที่โฮสต์บนเครือข่ายส่วนตัวและไม่สามารถเข้าถึงได้จากอินเทอร์เน็ตก็สามารถถูกโจมตีได้

ปัญหาที่พบไม่ได้อยู่ที่โปรโตคอลอินเทอร์เน็ตหลัก แต่กลับเป็นปัญหาที่ทวีความรุนแรงขึ้นจากการสร้างรายได้ที่ไม่เหมาะสมของคุณลักษณะ DNS บางอย่าง

Paul Vixie สมาคมระบบอินเทอร์เน็ต (ISC)

แม้ว่าจะเป็นความจริงที่โปรโตคอลเองไม่ได้เป็นต้นเหตุของปัญหา แต่ก็เป็นความจริงที่โปรโตคอลเหล่านี้ไม่ได้ป้องกันผู้ไม่หวังดีจากการใช้ระบบในทางที่ผิด ดังนั้นจากมุมมองทางเทคนิค ช่องโหว่ยังคงมีอยู่

ทำลายอินเทอร์เน็ตเพื่อการเฝ้าระวังและการเซ็นเซอร์

ในปี 2559 พบว่า ISP ในอิหร่านจัดการ DNS คราวนี้แทนที่จะฉีดโฆษณา พวกเขาบล็อกการเข้าถึงเซิร์ฟเวอร์อีเมล 139 โดเมนจาก 10,000 โดเมนแรกบนอินเทอร์เน็ต ไม่ชัดเจนว่านี่เป็นนโยบายโดยเจตนาในการปฏิเสธบริการกับโดเมนเฉพาะเหล่านี้หรือไม่ ซึ่งคล้ายกับการเซ็นเซอร์ที่มีชื่อเสียงระดับโลกในประเทศจีน หรืออาจเป็นเพียงตัวอย่างการใช้งานทางเทคนิคที่ไม่ดีของระบบใดก็ตามที่ขัดขวางการสืบค้น DNS

การไม่รู้ว่าเหตุใด DNS ถูกสกัดกั้นจึงมีความสำคัญ แม้ว่าเราจะละทิ้งคำถามด้านศีลธรรมและกฎหมายเกี่ยวกับการเฝ้าระวังและการเซ็นเซอร์แบบครอบคลุม แต่เทคโนโลยีที่ใช้ในการทำเช่นนี้กลับไม่เป็นไปตามมาตรฐานและอาจขัดขวางได้เป็นอย่างดี การใช้อินเทอร์เน็ตตามปกติ ในชีวิตประจำวัน สมเหตุสมผล และถูกกฎหมายของคุณ

จากมุมมองทางเทคนิค ช่องโหว่ยังคงมีอยู่

ทำลายอินเทอร์เน็ตเพื่อจุดประสงค์ที่ชั่วร้าย

แน่นอนว่าไม่ใช่แค่หน่วยงานทางการค้าและรัฐบาลที่พยายามสกัดกั้นการรับส่งข้อมูลทางอินเทอร์เน็ตด้วยวิธีการของตนเอง มีตัวอย่างมากมายของอาชญากรที่พยายามจี้การเชื่อมต่อ โดยปกติเพื่อจุดประสงค์ในการขโมยข้อมูลผู้ใช้หรือหลอกให้ผู้ใช้เปิดเผยข้อมูลรับรองการเข้าถึงที่สำคัญ ที่เด่นชัดที่สุดคือการเป็นพิษของแคช DNS ถูกนำมาใช้เพื่อนำผู้ใช้ไปยังไซต์ฟิชชิ่ง ปรับใช้แรนซัมแวร์ ปรับใช้บ็อตเน็ต ปฏิเสธบริการไปยังเว็บไซต์เฉพาะ และอีกมากมาย

TLS Leaks ใครเชื่อมต่อกับใคร

Transport Layer Security (TLS) เป็นเทคโนโลยีที่อยู่เบื้องหลัง HTTPS ซึ่งเป็นเวอร์ชันที่ปลอดภัยของ HTTP ที่เราทุกคนพึ่งพากันทุกวัน การสร้างการเชื่อมต่อ TLS ต้องใช้หลายขั้นตอน ในระหว่างนั้นเซิร์ฟเวอร์จะพิสูจน์ตัวตนด้วยการแสดงใบรับรอง และแลกเปลี่ยนคีย์การเข้ารหัสใหม่

การให้เซิร์ฟเวอร์ใช้ใบรับรองเพื่อพิสูจน์ตัวตนเป็นขั้นตอนที่สำคัญมาก เนื่องจากส่วนหนึ่งของใบรับรองเป็นคีย์เข้ารหัสสาธารณะแบบอสมมาตร

เมื่อไคลเอ็นต์ส่งข้อความโดยใช้คีย์นี้ เฉพาะเซิร์ฟเวอร์ที่อยู่ในความครอบครองของคีย์ส่วนตัวที่เกี่ยวข้องเท่านั้นที่สามารถอ่านข้อความได้ ด้วยเหตุนี้ ใครก็ตามที่สกัดกั้นหรือฟังการเชื่อมต่อจะถูกล็อคและไม่สามารถอ่านเนื้อหาได้

อย่างไรก็ตาม การแลกเปลี่ยนครั้งแรกนั้นยังคงทำอย่างชัดเจนโดยไม่มีการเข้ารหัส ซึ่งหมายความว่าผู้สังเกตการณ์จะทราบข้อมูลประจำตัวของเซิร์ฟเวอร์เสมอ

การจัดหน้าโดเมน

เครื่องมือประเภทต่อต้านการเซ็นเซอร์สองสามตัวช่วยแก้ปัญหาการรั่วไหลนี้ใน TLS ได้เป็นระยะเวลาหนึ่งโดยใช้เทคนิคที่เรียกว่าการปิดหน้าโดเมน สิ่งนี้ใช้ประโยชน์จากข้อเท็จจริงที่ว่าเมื่อสร้างการเชื่อมต่อ HTTPS แล้ว ผู้ให้บริการโฮสต์รายใหญ่ส่วนใหญ่จะไม่ตรวจสอบเพื่อดูว่าชื่อโฮสต์ที่แสดงในคำขอ HTTP แต่ละรายการตรงกับชื่อที่ใช้ในการแฮนด์เชค TLS หรือไม่ ในแง่ของเครื่องมือความเป็นส่วนตัว ฟีเจอร์นี้ถูกมองว่าเป็นฟีเจอร์ที่มีประโยชน์ที่ช่วยให้สามารถสื่อสารแบบลับๆ กับไซต์ที่ซ่อนอยู่ได้ สำหรับผู้ให้บริการโฮสต์และผู้รวบรวมข้อมูล นี่ถือเป็นการละเมิดวิธีการใช้งานข้อมูลจำเพาะ

นี่เป็นช่องโหว่ในตัวของมันเอง และด้วยเหตุนี้ผู้ให้บริการโฮสติ้งรายใหญ่หลายรายจึงได้รับการแก้ไขแล้ว รวมถึง AWS

การแก้ปัญหาโดยการเปลี่ยนมาตรฐาน: Encrypted SNI (ESNI)

แนวคิดเบื้องหลัง ESNI คือการป้องกันไม่ให้ TLS รั่วไหลข้อมูลใดๆ โดยการเข้ารหัสข้อความ ทั้งหมด รวมถึงข้อความ Client Hello เริ่มต้น สิ่งนี้ทำให้ผู้สังเกตการณ์รายใด ๆ ตกอยู่ในความมืดมิดเกี่ยวกับใบรับรองเซิร์ฟเวอร์ที่เซิร์ฟเวอร์นำเสนอ

ในการดำเนินการนี้ ไคลเอ็นต์ต้องมีคีย์เข้ารหัสก่อนทำการเชื่อมต่อ ดังนั้น ESNI จึงต้องวางชุดคีย์การเข้ารหัส ESNI เฉพาะในระเบียน SRV ใน DNS

รายละเอียดที่แน่นอนของเรื่องนี้ยังคงอยู่ในการไหล อย่างไรก็ตาม เนื่องจากข้อกำหนดยังไม่ได้รับการสรุป อย่างไรก็ตาม เรื่องนี้ Mozilla Firefox และ Cloudflare ได้นำ ESNI ไปใช้งานจริงแล้ว

การรักษาความปลอดภัยและการเข้ารหัส DNS

เพื่อให้ส่งคีย์ ESNI โดยไม่ถูกสกัดกั้น สิ่งสำคัญคือต้องป้องกันการปลอมแปลง DNS

นับตั้งแต่ปี 1993 ชุมชนอินเทอร์เน็ตได้พยายามรักษาความปลอดภัย DNS IETF ตั้งข้อสังเกตว่าการประชุมการแก้ปัญหาในช่วงต้นได้กล่าวถึง:

1. การป้องกันการเปิดเผยข้อมูล DNS แก่บุคคลที่ไม่ได้รับอนุญาต
2. รับรองความสมบูรณ์ของข้อมูล
3. การตรวจสอบแหล่งที่มาของข้อมูล

การประชุมเหล่านี้ส่งผลให้มีมาตรฐาน Domain Name System Security Extensions (DNSSEC) ในปี 1997 มาตรฐานนี้เลือกที่จะจัดการกับข้อกังวลสองในสามข้อนี้ เนื่องจากทีมออกแบบได้ตัดสินใจอย่างชัดแจ้งเพื่อควบคุมการคุกคามของการเปิดเผยข้อมูลทั้งหมดอย่างชัดเจนนอกขอบเขต

ดังนั้น DNSSEC หมายความว่าผู้ใช้สามารถวางใจได้ว่าคำตอบสำหรับการสืบค้น DNS ของพวกเขาคือสิ่งที่เจ้าของโดเมนตั้งใจให้เป็น ในบริบทของ ESNI นี่หมายความว่าเรารู้ว่าคีย์ที่เราได้รับไม่ได้ถูกแก้ไข และโชคดีที่ช่องโหว่จำนวนมากที่กล่าวถึงข้างต้นหายไปเมื่อมีการใช้งาน DNSSEC อย่างไรก็ตาม ไม่รับประกันความเป็นส่วนตัว ดังนั้นจึงยังเสี่ยงต่อปัญหาที่เกิดจากระบบเฝ้าระวังและเซ็นเซอร์

น่าเสียดาย เนื่องจากสามารถใช้งานร่วมกับ “DNS ที่ไม่ปลอดภัย” แบบย้อนหลังได้อย่างสมบูรณ์และค่อนข้างยากที่จะนำไปใช้อย่างถูกต้อง การนำ DNSSEC มาใช้นั้นต่ำมาก เจ้าของโดเมนจำนวนมากเลิกล้มความพยายามในการกำหนดค่าดังกล่าว โดยเห็นได้จากการกำหนดค่าที่ไม่ถูกต้องและการตั้งค่าครึ่งหนึ่งจำนวนมากที่พบในปกติ

DNS ผ่าน HTTPS (DoH)

สำหรับการส่งคีย์ ESNI โดยที่ผู้ดูไม่ทราบว่าผู้ใช้พยายามเข้าชมไซต์ใด สิ่งสำคัญคือต้องป้องกันการดักฟัง DNS ด้วยเหตุนี้ จึงค่อนข้างสมเหตุสมผลและเข้าใจได้ว่า DNS ที่เข้ารหัส (เช่น DoH) เป็นสิ่งที่ดี อย่างไรก็ตาม ในปัจจุบัน DNS ไม่ได้ถูกเข้ารหัส

Mozilla, Google, APNIC, Cloudflare, Microsoft และอื่นๆ มีการเคลื่อนไหวเพื่อเปลี่ยนแปลงสิ่งนี้

ประสบการณ์ผู้ใช้เข้ารหัสในอุดมคติ

ผู้ใช้ที่ต้องการใช้ประโยชน์จากเทคโนโลยีข้างต้นอาจมีรายการข้อกำหนดที่ค่อนข้างยาว เมื่อพูดถึงรายละเอียด UX ที่ใช้งานได้จริงในการทำงานกับการเข้ารหัส มีแนวโน้มว่าพวกเขาต้องการหลีกเลี่ยงสิ่งที่ชอบ:

• ถูกบังคับให้ใช้บริการ DNS เฉพาะ (ไม่ว่าจะดีแค่ไหน) หรือให้ตัวเลือกที่มองไม่เห็นหรือหาได้ยาก
• แต่ละแอปในอุปกรณ์ที่จัดการ DNS ต่างกัน (เช่น Firefox สามารถค้นหาสิ่งที่ Safari ไม่สามารถทำได้)
• แอปทั้งหมดบนอุปกรณ์ต้องสร้างการใช้งาน DNS ที่ปลอดภัยภายในตัวมันเอง
• ต้องกำหนดค่า DNS ด้วยตนเองหลายครั้ง
• ต้องเลือกความเป็นส่วนตัวและความปลอดภัย
• แอพถอยกลับไปสู่การทำงานที่ไม่ปลอดภัยโดยไม่ได้รับความยินยอมจากผู้ใช้

ผู้ใช้ที่คำนึงถึงความเป็นส่วนตัวต้องการ:

• ความเป็นส่วนตัวจากการถูกสอดส่องโดยไร้เหตุผลจากใครก็ตาม
• การป้องกันจากโฆษณาที่กำหนดเป้าหมายที่พวกเขาไม่ยินยอม
• การปกป้องเนื้อหาที่เผยแพร่ของตนเอง (เช่น บนเว็บไซต์ส่วนตัว) จากการเปลี่ยนแปลงหรือจัดการระหว่างทางไปยังผู้ดูรายอื่น
• รับรองว่าผู้ดูเนื้อหาที่เผยแพร่ของตนเองจะไม่ประสบปัญหาเพียงแค่การเข้าถึงเท่านั้น
• เพื่อให้มีตัวเลือกในการควบคุม DNS บนเครือข่ายของตนเองต่อไป (เพราะในบางครั้ง DNS แบบแบ่งขอบเขตจะดีสำหรับการรักษาทรัพยากรภายในให้จำกัดขอบเขตสำหรับผู้ใช้ภายใน)
• ความสามารถในการเลือกใช้หรืออย่างน้อยก็เลือกไม่ใช้การกรองที่ระดับ DNS (เช่น Quad9, CleanBrowsing และ OpenDNS Family Shield)
• การกำหนดค่าที่ง่าย ไม่ยุ่งยาก (เช่น DHCP)
• จะถูกขอให้ยินยอมให้ใช้ DNS โดยไม่มีการเข้ารหัส
• การป้องกันไม่เพียงแต่สำหรับทราฟฟิกเบราว์เซอร์ แต่สำหรับทราฟฟิกทุกประเภท เช่น อีเมล Slack VoIP SSH VPN เป็นต้น

ความพยายามในการเข้ารหัสปัจจุบัน

มีตัวเลือกใดบ้างสำหรับผู้ใช้ที่มีเป้าหมายข้างต้น

โซลูชันของ Mozilla เป็นจุดเริ่มต้น แต่ยังห่างไกลจากอุดมคติ พวกเขารักษาความปลอดภัยให้กับ Firefox เท่านั้น ค่าเริ่มต้นคือแทนที่การตั้งค่าระบบปฏิบัติการของคุณให้เป็นทางเลือกของผู้ให้บริการ (Cloudflare) โดยไม่ต้องพูด และมันก็กลับกลายเป็นไม่ปลอดภัยอย่างเงียบๆ (ในกรณีที่ DNS ที่เข้ารหัสถูกบล็อก ฯลฯ )

โซลูชันของ Google เป็นแนวทางที่ดีกว่า พวกเขากำลังรักษาความปลอดภัยให้กับ Android 9+ ซึ่งใช้ได้กับ ทุก แอป (ฉันไม่แน่ใจเกี่ยวกับแผน Chrome OS ของพวกเขา แต่ฉันสงสัยว่ากำลังทำงานอยู่) พวกเขายังรักษาความปลอดภัย Chrome ไว้บนทุกแพลตฟอร์ม แต่จะทริกเกอร์การรักษาความปลอดภัยก็ต่อเมื่อแพลตฟอร์มโฮสต์ได้รับการกำหนดค่าให้ใช้ผู้ให้บริการที่สนับสนุนความปลอดภัยเท่านั้น นี่เป็นสิ่งที่ดีในแง่ของทางเลือกของผู้ใช้ แต่ไม่เหมาะเพราะจะกลับกลายเป็นความไม่ปลอดภัยอย่างเงียบๆ

เบราว์เซอร์หลักอื่น ๆ ทั้งหมดยังใช้การสนับสนุน

ในสถานการณ์ที่เหมาะสมที่สุดสำหรับผู้ใช้ ชุมชนที่กว้างขึ้นของซอฟต์แวร์และนักพัฒนาระบบปฏิบัติการจะ:

1. หยุดใช้คุณสมบัติความปลอดภัย DNS ใหม่ในระดับแอปพลิเคชัน
2. เริ่มใช้งานในระดับ OS
3. เคารพการกำหนดค่าระดับระบบปฏิบัติการ หรือขอความยินยอมจากผู้ใช้

การใช้ DNS ที่เข้ารหัสในระดับ OS เราสามารถดำเนินการตามรูปแบบการกระจายแบบเดียวกับที่เรามีสำหรับตัวแก้ไข DNS ในปัจจุบัน การเรียกใช้เซิร์ฟเวอร์ DNS ของตนเองบนเครือข่ายของตนเอง และการทำให้ตัวแก้ไขนั้นปลอดภัย เหมาะสมที่จะเป็นตัวเลือกต่อไป เช่นเดียวกับการใช้ผู้ให้บริการแบบรวมศูนย์

Linux และ BSD มีฟังก์ชันนี้อยู่แล้วโดยมีตัวเลือกมากมาย น่าเสียดายที่ไม่มี distro ใดที่เปิดใช้งานใด ๆ โดยค่าเริ่มต้นเท่าที่ฉันรู้ ลองใช้ nss-tls หากคุณต้องการบางสิ่งที่จะเสียบเข้ากับ glibc

การใช้งาน DNS-over-TLS ของ Google ใน Android 9+ ก็ทำไปแล้วเช่นกัน มันทำงานโดยการทดสอบเซิร์ฟเวอร์ DNS สำหรับการสนับสนุนการเข้ารหัส ถ้ามีก็จะใช้ หากไม่เป็นเช่นนั้น เช่นเดียวกับ Chrome จะยังคงดำเนินต่อไปในลักษณะที่ไม่ปลอดภัยโดยไม่ต้องขอความยินยอม

เป็นที่น่าสังเกตว่าเครือข่ายส่วนใหญ่ได้รับการกำหนดค่าให้ใช้เซิร์ฟเวอร์ DNS ที่ไม่สนับสนุนการเข้ารหัส ดังนั้นโซลูชันที่ติดตั้งใน Android ยังไม่ได้เปลี่ยนแปลงอะไรสำหรับผู้ใช้ส่วนใหญ่ บางทีมันอาจจะดีกว่าที่จะเสนอให้ถอยกลับไปใช้ DNS ที่เข้ารหัสแบบรวมศูนย์ในกรณีที่การกระจายอำนาจไม่รองรับการเข้ารหัส

สำหรับอุปกรณ์รสชาติของ Apple และ Microsoft การสนับสนุน DNS ที่เข้ารหัสยังไม่มาถึงอย่างเป็นทางการในขณะที่เขียนบทความนี้ Microsoft ได้ประกาศความตั้งใจที่จะสนับสนุน DNS ที่เข้ารหัสในเดือนพฤศจิกายน 2019 ในเดือนพฤศจิกายน 2019 หวังว่า Apple จะตามมาในไม่ช้า

วิธีแก้ปัญหา DNS ที่เข้ารหัส

มีวิธีแก้ปัญหาบางอย่างในรูปแบบของพร็อกซีที่สามารถเรียกใช้ในเครื่องได้ ด้วยวิธีนี้ คอมพิวเตอร์ของผู้ใช้จะพูดกับ DNS ที่ไม่ได้เข้ารหัสด้วยตัวเอง ซึ่งจะพูด DNS ที่เข้ารหัสไปยังผู้ให้บริการใดๆ ก็ตามที่ได้รับการกำหนดค่าให้ใช้ นี่ไม่ใช่วิธีแก้ปัญหาในอุดมคติ แต่เมื่อใช้วิธีแก้ไขปัญหาชั่วคราว มันก็เหมาะสม

แรงบันดาลใจในการเขียนบทความนี้คือพร็อกซี DNSCrypt ซึ่งมีความเสถียรมาก มีเสียงระฆังและเสียงนกหวีดมากมาย และเป็นแบบข้ามแพลตฟอร์ม รองรับโปรโตคอล DNSCrypt รุ่นเก่า เช่นเดียวกับโปรโตคอล DNS ผ่าน TLS (DoT) และ DNS ผ่าน HTTPS (DoH) ที่ใหม่กว่า

สำหรับผู้ใช้ Windows มีตัวติดตั้งและ GUI ที่เรียกว่า Simple DNSCrypt ซึ่งมีคุณสมบัติครบถ้วนและใช้งานง่ายมาก

ฉันแนะนำ แต่โปรดทราบว่าโลกอาจยังไม่พร้อมสำหรับคุณ และคุณอาจต้องปิดการใช้งานเป็นครั้งคราว (เช่น เมื่อคุณต้องใช้แคปทีฟพอร์ทัลที่ร้านกาแฟที่คุณชื่นชอบ หรือที่ LAN งานสังสรรค์).

ตัวเลือกอื่น

นอกจากนี้ยังมี Technitium DNS Server ซึ่งรองรับ DNS ที่เข้ารหัส เป็นแพลตฟอร์มข้ามแพลตฟอร์ม (Windows, MacOS, Linux บน ARM/Raspberry Pi) และมีเว็บอินเตอร์เฟสที่ลื่นไหล อยู่ภายใต้ "อื่นๆ" เพราะเป็นเครื่องมือที่ครอบคลุมมากกว่าวิธีแก้ปัญหาเฉพาะสำหรับปัญหานี้ (น่าจะเป็นทางเลือกที่ดีถ้าคุณต้องการเรียกใช้เซิร์ฟเวอร์ Raspberry Pi DNS ที่บ้าน ฉันสนใจที่จะรับฟังความคิดเห็นจากผู้ที่ทดลองใช้งานในความคิดเห็นด้านล่าง)

สำหรับอุปกรณ์ Android หรือ iOS (iPhone, iPad ฯลฯ) ของคุณ ยังมีแอพ 1.1.1.1 ซึ่งจะบังคับการสืบค้น DNS ทั้งหมดของคุณผ่านบริการ Cloudflare Encrypted DNS ฉันได้ยินมาว่ามีแอปที่ยืดหยุ่นกว่าด้วย เช่น Intra แต่ฉันยังไม่ได้ใช้เวลาทดสอบเลย

แน่นอน คุณยังสามารถเปิดใช้งาน DNS ที่เข้ารหัสได้ทั้งใน Firefox และ Chrome - พึงระลึกไว้เสมอว่าข้อแม้ทั้งหมดที่กล่าวถึงข้างต้น

ความน่าเชื่อถือของ DNS: งานอันดับหนึ่ง

มีการโต้เถียงกันมากมายเกี่ยวกับเทคโนโลยีความเป็นส่วนตัวทางอินเทอร์เน็ต อย่างไรก็ตาม เมื่อพูดถึงการใช้มาตรการรักษาความปลอดภัยและความเป็นส่วนตัว เทคโนโลยีที่เป็นปัญหาไม่ได้เกี่ยวกับการรักษาความลับเป็นหลัก มันเกี่ยวกับการรับรองความน่าเชื่อถือและการรับประกันว่าเทคโนโลยียังคงทำงานได้อย่างถูกต้องแม้จะมีพฤติกรรมของผู้อื่น กระนั้น เราต้องระลึกไว้เสมอว่า เทคโนโลยีที่ปราศจากการปกป้องความเป็นส่วนตัวนั้นไม่ดี การป้องกันที่นำไปใช้ได้ไม่ดีก็สามารถทำให้สถานการณ์แย่ลงได้เช่นเดียวกับที่เทคโนโลยีไม่มีการป้องกันความเป็นส่วนตัว