คู่มือการเลือก Public DNS Resolver

 (evilbit.de)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Public DNS Resolver ไม่ควรพิจารณาแค่ความเร็ว แต่ต้องดู ความเป็นส่วนตัว การกรอง เขตอำนาจศาล ผู้ให้บริการ และการส่งข้อมูลแบบเข้ารหัส ร่วมกัน โดยคู่มือนี้เปรียบเทียบบริการระดับโลก 30 รายตามความต้องการใช้งาน
  • เครื่องมือเลือกใช้ DoH·DoT·DoQ·DNSCrypt, การตรวจสอบ DNSSEC, IPv6, เขตอำนาจศาล, ประเภทผู้ให้บริการ และ EDNS Client Subnet เป็นตัวกรองแบบฮาร์ดฟิลเตอร์ และให้คะแนนตามลำดับความสำคัญของเป้าหมายการใช้งาน
  • การทดสอบความหน่วง DoH บนเบราว์เซอร์แสดงความเร็วเชิงเปรียบเทียบจากตำแหน่งปัจจุบัน แต่รวมโอเวอร์เฮดของ TLS/HTTP และไม่สามารถวัดรีโซลเวอร์ที่รองรับเฉพาะ DNS แบบไม่เข้ารหัสได้
  • DNS แบบเข้ารหัสช่วยลดการดักฟังหรือการแก้ไขข้อมูลระหว่างทางโดยผู้โจมตี แต่ ผู้ให้บริการรีโซลเวอร์ ที่เลือกยังคงมองเห็นโดเมนที่มีการค้นหาได้ จึงควรพิจารณาทั้งนโยบายไม่เก็บบันทึกและสถาปัตยกรรมแบบ oblivious
  • ในการเลือกใช้งานจริง ต้องพิจารณาร่วมกันทั้ง DNSSEC, จุดแลกเปลี่ยนระหว่างความเร็วกับความเป็นส่วนตัวของ ECS, ประสิทธิภาพของ DoQ, คุณลักษณะของ DNSCrypt, ข้อจำกัดของการวิเคราะห์ทราฟฟิก, ความต่างด้านการปฏิบัติตามมาตรฐาน, รวมถึงความเสี่ยงด้านเขตอำนาจศาลและการรวมศูนย์

เกณฑ์ที่เครื่องมือเลือกใช้ในการเปรียบเทียบ

  • Public DNS Resolver ถูกเปรียบเทียบโดยให้ผู้ใช้ตรวจเงื่อนไขที่สำคัญกับตนเองแล้วค้นหาตัวเลือกที่ตรงกัน
  • เงื่อนไขที่ใช้เป็น ฮาร์ดฟิลเตอร์
    • การส่งข้อมูลแบบเข้ารหัส: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
    • รองรับการตรวจสอบ DNSSEC
    • มีที่อยู่รีโซลเวอร์แบบ IPv6
    • เขตอำนาจศาลของผู้ให้บริการ
    • ประเภทผู้ให้บริการ: ไม่แสวงหากำไร·ชุมชน·สาธารณประโยชน์, เชิงพาณิชย์, ทั้งหมด
    • EDNS Client Subnet(ECS): ไม่ใช้, ใช้, ไม่สนใจ
  • รายการที่นำไป ให้คะแนนตามลำดับความสำคัญ
    • ความเป็นส่วนตัวสูงสุดและไม่เก็บบันทึกหรือเก็บบันทึกให้น้อยที่สุด
    • บล็อกมัลแวร์·ฟิชชิง
    • บล็อกโฆษณา·ตัวติดตาม
    • การคุ้มครองเด็กและบล็อกเนื้อหาสำหรับผู้ใหญ่
    • ไม่กรองและคืนค่า DNS response ตามที่เผยแพร่มา
    • รายการบล็อก·กฎที่ผู้ใช้กำหนดเองผ่านบัญชี
    • ความเร็วหน่วงต่ำจากโครงสร้าง Global Anycast
    • ผู้ให้บริการที่ไม่ใช่เชิงพาณิชย์

การทดสอบความเร็ว DoH ตามตำแหน่งปัจจุบัน

  • การทดสอบในตัวจะวัดเวลาไป-กลับจากเบราว์เซอร์ไปยัง รีโซลเวอร์ที่รองรับ DoH แต่ละราย
  • รีโซลเวอร์ที่รองรับเฉพาะ DNS แบบไม่เข้ารหัสไม่สามารถทดสอบด้วยวิธีนี้ได้
  • ผลลัพธ์เป็นเพียงค่าอ้างอิงเชิงเปรียบเทียบ และเนื่องจากรวมโอเวอร์เฮดของ TLS และ HTTP จึงควรรันทดสอบหลายครั้ง
  • เพราะเบราว์เซอร์ส่งคำถามไปยังรีโซลเวอร์แต่ละรายโดยตรง IP address ของผู้ใช้จึงถูกเปิดเผยต่อรีโซลเวอร์นั้น
  • การติดตั้งทดสอบได้แนวคิดจากโอเพนซอร์ส DNS Speed Test ของ Silviu Stroe แต่เป็นการพัฒนาแยกอิสระ และจะทำงานเมื่อหน้าเว็บให้บริการผ่าน HTTPS เท่านั้น

ความแตกต่างของประสิทธิภาพและการส่งข้อมูลแบบเข้ารหัส

  • การส่งข้อมูลแบบเข้ารหัสอย่าง DoH และ DoT เพิ่มความหน่วงต่อหนึ่งคำถาม แต่เวลาโหลดหน้าเว็บโดยรวมมักใกล้เคียงกับ DNS แบบไม่เข้ารหัส และโอเวอร์เฮดของ DoH ก็มีขนาดเล็กในสภาพแวดล้อมจริง
  • บนลิงก์ที่มีการสูญหายของแพ็กเก็ตหรือมีความหน่วงสูง Do53 แบบไม่เข้ารหัสยังคงได้เปรียบ
  • ประสิทธิภาพแตกต่างกันตามผู้ให้บริการและภูมิภาค ดังนั้นรีโซลเวอร์ที่เร็วที่สุดขึ้นอยู่กับตำแหน่งของผู้ใช้
  • ในการวัดแบบ end-to-end ขนาดใหญ่ของ DNS แบบเข้ารหัส พบว่ามีโอกาสถูกดักจับหรือถูกแก้ไขระหว่างส่งต่ำกว่า DNS แบบไม่เข้ารหัสอย่างมาก และมีโอเวอร์เฮดน้อย
  • อย่างไรก็ตาม ในงานวิจัยดังกล่าว ผู้ให้บริการ DoT ประมาณ 25% ให้ใบรับรอง TLS ที่ไม่ถูกต้อง จึงสำคัญมากที่จะเลือกผู้ให้บริการที่มีคุณภาพการดำเนินงานดี

ข้อจำกัดจริงของความเป็นส่วนตัว

  • DNS แบบเข้ารหัสซ่อนคำถามจากเครือข่ายได้ แต่ ผู้ให้บริการรีโซลเวอร์ ที่เลือกยังคงเห็นโดเมนทั้งหมดที่มีการค้นหา
  • หากประเด็นนี้เป็นปัญหา ควรเลือกผู้ให้บริการที่ไม่เก็บบันทึก หรือพิจารณาสถาปัตยกรรมแบบ oblivious อย่าง ODoH ที่แยกตัวตนออกจากคำถามผ่านพร็อกซี
  • Cloudflare และ Apple เป็นตัวอย่างของการนำ ODoH ไปใช้งานจริง
  • การใช้ DNS แบบเข้ารหัสเพียงอย่างเดียวไม่ได้ซ่อนเว็บไซต์ที่เข้าชมได้อย่างสมบูรณ์
    • แม้ใช้ DoH ก็ยังสามารถระบุโดเมนที่เข้าชมได้ด้วยความแม่นยำสูงผ่านการวิเคราะห์ทราฟฟิก
    • แม้แต่ EDNS padding ตามมาตรฐานก็ไม่สามารถป้องกันเรื่องนี้ได้ทั้งหมด
    • หากโมเดลภัยคุกคามนี้เกี่ยวข้องกับการใช้งานของคุณ ไม่ควรพึ่งพา padding เพียงอย่างเดียว และควรใช้ Tor หรือสถาปัตยกรรมแบบ oblivious ร่วมกัน

DNSSEC, ECS, เขตอำนาจศาล

  • เฉพาะรีโซลเวอร์ที่ทำ การตรวจสอบ DNSSEC เท่านั้นที่ช่วยป้องกันระเบียนปลอมแปลงได้
  • Google, Cloudflare, Quad9 ตรวจสอบ DNSSEC และจัดการ root key KSK rollover ครั้งแรกได้โดยไม่ทำให้ผู้ใช้เกิดปัญหา
  • หากความถูกต้องสมบูรณ์ของข้อมูลสำคัญ ควรมองการตรวจสอบ DNSSEC เป็นเงื่อนไขบังคับ
  • EDNS Client Subnet(ECS) จะส่งบางส่วนของ IP ไปยัง CDN เพื่อการกำหนดเส้นทางตามภูมิศาสตร์ที่ดีกว่า
    • Google และ OpenDNS ส่ง ECS เพื่อการจับคู่ CDN ที่แม่นยำกว่า
    • Cloudflare และ Quad9 เวอร์ชันมาตรฐานปิด ECS เพื่อความเป็นส่วนตัว
  • ที่ตั้งทางกฎหมายของผู้ให้บริการมีผลต่อมาตรการบังคับใช้และบันทึกข้อมูล
  • ปัจจุบันมีผู้ให้บริการเพียงไม่กี่รายที่ประมวลผลทราฟฟิก recursive DNS ของโลกในสัดส่วนสูง
  • NSA ของสหรัฐฯ เตือนว่าการใช้รีโซลเวอร์ภายนอกอาจเลี่ยงการกรองและการตรวจสอบ DNS ภายในองค์กรได้ จึงต้องชั่งน้ำหนักระหว่างความสะดวกกับการควบคุม

DoQ และ DNSCrypt

  • ในการวัดผล DoQ ปี 2022 พบว่า DNS-over-QUIC มีเวลาในการตอบสนองดีกว่าทั้ง DoT และ DoH
  • อย่างไรก็ตาม เนื่องจากข้อจำกัดของการตรวจสอบที่อยู่ใน QUIC ทำให้การจับมือเชื่อมต่อประมาณ 40% ช้าลง
  • หากทั้งฝั่งไคลเอนต์และรีโซลเวอร์รองรับ DoQ ก็เป็นตัวเลือกการเข้ารหัสที่ควรให้ความสำคัญ
    • ตัวอย่างบริการที่รองรับ: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS และบริการรายใหญ่ในจีน
  • DNSCrypt เป็นตัวเลือกการเข้ารหัสที่เก่ากว่า DoH, DoT และ DoQ โดยเวอร์ชัน 2 ออกมาในปี 2013
  • DNSCrypt เข้ารหัสตั้งแต่แพ็กเก็ตแรกด้วย public key ที่แชร์ล่วงหน้าของรีโซลเวอร์ จึงไม่ต้องมีการค้นหา hostname แบบไม่เข้ารหัส และไม่ต้องพึ่งพา CA
  • โหมด Anonymized DNS ในปี 2019 ยังช่วยซ่อน IP ของไคลเอนต์ได้ด้วย
  • ในกลุ่มที่เปรียบเทียบ ผู้ให้บริการ DNSCrypt ได้แก่ Quad9, OpenDNS, AdGuard, NextDNS, Control D และ Yandex
  • ยังขาดตัวเลขการใช้งานที่น่าเชื่อถือ และการวัดขนาดใหญ่อย่าง APNIC Labs ติดตาม DoH และ DoT แต่ไม่ได้ติดตาม DNSCrypt

คุณภาพการติดตั้งรีโซลเวอร์และข้อมูลด้านปฏิบัติการ

  • งานวิจัย Extended DNS Errors ปี 2023 พบว่ารีโซลเวอร์หลัก ๆ มีความไม่สอดคล้องกันของรายงานข้อผิดพลาดเพื่อการวินิจฉัยใน 94% ของกรณีทดสอบ
  • Cloudflare แสดงการรายงานข้อผิดพลาดที่แม่นยำที่สุดในงานวิจัยดังกล่าว
  • ความแตกต่างของคุณภาพการติดตั้งและการปฏิบัติตามมาตรฐานในแต่ละรีโซลเวอร์มีผลต่อการแก้ปัญหาและความน่าเชื่อถือ
  • ข้อมูลด้านปฏิบัติการ·ชุมชนที่ใช้อ้างอิงได้
    • ICANN Identifier Technology Health Indicators: ติดตามสัดส่วนรีโซลเวอร์ที่ตรวจสอบ DNSSEC และระดับการกระจุกตัวของรีโซลเวอร์
    • DNS-OARC workshop talks และ past-event archive: การบรรยายจากผู้ปฏิบัติงานและนักวิจัยเกี่ยวกับ DNS แบบเข้ารหัส ประสิทธิภาพรีโซลเวอร์ และการวัดผล
    • APNIC Labs measurements: ข้อมูลอัตราการตรวจสอบ DNSSEC การใช้งาน Public Resolver และการยอมรับ DoH·DoT แยกตามประเทศ

รีโซลเวอร์ขนาดเล็ก·ชุมชน·ท้องถิ่น

  • นอกเหนือจากตารางเปรียบเทียบ ยังมีรีโซลเวอร์เฉพาะทางระดับงานอดิเรก ชุมชน และรายประเทศ ซึ่งควรตรวจสอบสถานะปัจจุบันและนโยบายก่อนใช้งาน
  • รายการในยุโรปรวบรวมไว้ที่ European Alternatives
  • รีโซลเวอร์ในพื้นที่ที่มีการเซ็นเซอร์หรือมาตรการคว่ำบาตรรุนแรงอาจใช้กฎเนื้อหาในท้องถิ่น หรืออาจถูกดำเนินงานเพื่อหลีกเลี่ยงการบล็อกตามภูมิศาสตร์ จึงต้องระวังเป็นพิเศษ
  • ตัวอย่างบริการ
    • DNS4all: รีโซลเวอร์ยุโรปแบบไม่กรองที่เน้นความเป็นกลางและประสิทธิภาพ
    • BlahDNS: โครงการโอเพนซอร์สแบบงานอดิเรกสำหรับบล็อกโฆษณา ดำเนินงานบนเซิร์ฟเวอร์ขนาดเล็กในภูมิภาค รองรับ DoH·DoT·DoQ
    • LibreDNS: รีโซลเวอร์ชุมชนของ LibreOps พร้อมบล็อกโฆษณาและนโยบายไม่เก็บบันทึก รองรับ DoH·DoT
    • Dismail.de: รีโซลเวอร์ชุมชนจากเยอรมนีที่เน้นความเป็นส่วนตัว ไม่เก็บบันทึก รองรับ DoH·DoT
    • IIJ Public DNS: รีโซลเวอร์สาธารณะ DoH·DoT จาก Internet Initiative Japan ที่บล็อกโดเมนเนื้อหาล่วงละเมิดทางเพศเด็ก
    • DNS for Family: DoH สำหรับการกรองแบบครอบครัวที่รวมการบล็อกสื่อลามก การพนัน มัลแวร์ โฆษณา·ตัวติดตาม และ Safe Search
  • มีการกล่าวถึงบริการเก่าหรือที่ยุติแล้วซึ่งควรหลีกเลี่ยง ได้แก่ Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu และ Norton ConnectSafe

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ทุกครั้งที่เห็นรายการแบบนี้หรือประกาศบริการใหม่ ๆ ก็ไม่ได้รู้สึกตื่นเต้นเท่าไร และใน Hacker News ก็ดูเหมือนมีปฏิกิริยาแบบเดียวกันมากอย่างน่าประหลาดใจ
    ผมรัน บริการพร็อกซี DNS เองมาเกือบ 25 ปีแล้ว และเคยลองใช้ชุดซอฟต์แวร์ 3 แบบบนระบบปฏิบัติการ 6 ตัว รายการทั้งหมดในแท็บฟิลเตอร์นั้นทำเองได้ทั้งหมด และก็ทำอยู่จริง
    สิ่งที่น่าสนใจในรายการนี้ไม่ใช่ตัวเลือก แต่เป็นสิ่งที่มันเผยให้เห็น เช่น รายการที่ระบุว่า “China” ล้วนเขียนว่า “ดำเนินงานภายใต้กฎระเบียบของจีน” ซึ่งในปี 2026 ไม่ได้เป็นประเด็นเฉพาะกับรายการของจีนเท่านั้น แต่ยังเป็นเรื่องที่ผู้ใช้ในทวีปของผมเองก็ใส่ใจด้วย
    ข้อความว่า “ดำเนินงานโดยบุคคล 1 คนในเดนมาร์ก” เป็นข้อมูลที่น่าสนใจเพราะเผยให้เห็น bus factor แต่ก็ไม่อาจสันนิษฐานได้ว่ารายการอื่นดีกว่าเพียงเพราะไม่ได้พูดถึงประเด็นนี้ เรามีข้อมูลว่าใครอยู่เบื้องหลัง DNS.Watch น้อยกว่า Thomas Steen Rasmussen มาก และดูเหมือนช่วงไม่กี่ปีมานี้เคยล่มอย่างน้อยหนึ่งครั้ง จึงเป็นข้อกังวลที่สมเหตุสมผล
    Quad101 ดูเหมือนมีข้อจำกัดด้านพื้นที่ให้บริการ และยังมีปัจจัยอีกมากที่ไม่ได้อยู่ในรายการนี้แต่ผู้ใช้อาจให้ความสำคัญ เช่น Gcore เป็นบริษัท AI

    • เรื่อง “ดำเนินงานโดยบุคคล 1 คนในเดนมาร์ก” น่าสนใจกว่าในแง่ การเฝ้าระวังภายในองค์กร มากกว่า bus factor
      ถ้ามีหลายคนเกี่ยวข้องกับการดำเนินงาน พวกเขาจะคอยตรวจสอบกันเอง และหากเห็นเรื่องแปลก ๆ เช่น DNS resolver ทำ selective logging หรือแทรกแซงผลลัพธ์ ก็สามารถหยิบยกเป็นปัญหาได้ ถ้าคนคนเดียวดูแลทั้งหมด ก็ไม่มีใครคอยห้ามเขา
      คุณอาจคิดว่า “คนคนนั้นเป็นคนมีหลักการ คงไม่ทำแบบนั้นแน่” แต่แรงกดดันจากหน่วยงานบังคับใช้กฎหมายอาจรุนแรงมาก
    • ประมาณ 2 ปีก่อนผมตั้งค่า resolver เอง และมันก็ทำงานได้ดีเฉย ๆ ไม่เคยมีปัญหาเลย

  • ถ้าใช้ DNS ทางการของ ISP จะได้ เส้นทางที่สั้นที่สุด เท่าที่เป็นไปได้จากจุด handoff ของ ISP ไปยัง CDN หรือ trunk ต่างประเทศ กล่าวคืออย่าใช้ DNS ทั่วไปที่ไม่รู้โครงสร้างของ ISP
    ISP: ถึง Cloudflare 1ms
    Cloudflare: ถึง Cloudflare 10ms
    อย่างไรก็ตาม คำแนะนำนี้ใช้ได้กับประเทศที่มีกฎหมายความเป็นส่วนตัวดีและไม่มีการสอดส่องโดยรัฐ กล่าวคือไม่ใช่สหรัฐฯ

    • ถ้าต้องการ DNS ที่ไม่มีการเซ็นเซอร์ วิธีนั้นไม่ดี
    • ในทางปฏิบัติ การใช้ DNS ที่บล็อกเซิร์ฟเวอร์โฆษณา น่าจะให้ประสิทธิภาพโดยรวมดีกว่า
    • ไม่แน่ใจว่าประเทศแบบนั้นยังมีอยู่จริงหรือไม่ และนี่ไม่ใช่แค่เรื่องความเป็นส่วนตัวเท่านั้น เพราะแทบทุกประเทศพยายามไม่ให้ผู้ใช้เข้าถึงที่ที่ไม่อยากให้เข้าถึง และโดยมากทำแบบหยาบ ๆ คือ DNS เริ่มต้นของ ISP จะส่งไปยังหน้าคำเตือนแทนเว็บไซต์ที่ตั้งใจจะเปิด
      ดังนั้นการเปลี่ยนไปใช้ DNS อย่าง 8.8.8.8 แม้จะไม่ได้เพิ่มความเป็นส่วนตัวเสมอไป แต่ก็เป็นก้าวใหญ่ก้าวแรกในการ ปรับปรุงประสบการณ์การท่องเว็บ
    • Cloudflare ใช้ anycast อย่างที่รู้กันดี ดังนั้นไม่ว่ามาจากที่ไหน การตอบสนอง DNS ก็เหมือนกัน ตัวเลขที่ยกมาจึงยากจะบอกว่าเกิดจาก DNS
      กลับกัน Cloudflare อาจทำให้ขั้นตอน name resolution เร็วขึ้นได้ เพราะสามารถย่นการ recursive lookup สำหรับบริการของตนเอง และถ้าจำเป็นก็ใช้ eDNS Client Subnet เพื่อทำ location-based routing ได้
    • เปลี่ยน DNS แทบไม่มีผลต่อความเป็นส่วนตัว ยังอ่าน DNS query และ SNI ได้อยู่ดี

  • ต้องการคำแนะนำเรื่องการใช้ DNS resolver ร่วมกับ Wi‑Fi สาธารณะ
    Wi‑Fi สาธารณะจำนวนมากต้องใช้ DNS ของตัวเองเพื่อ redirect ไปยังหน้าตกลงเงื่อนไข และบางครั้งยังบังคับให้ยืนยันใหม่ทุก 30–60 นาที
    พอเกิดปัญหา ก็รู้ตัวว่าอินเทอร์เน็ตหยุด ทำ ping ไปที่ google.com รอ timeout เดาว่าเป็นปัญหา ISP แล้วค่อยนึกได้ว่าเซสชัน Wi‑Fi น่าจะหมดอายุ จากนั้นต้องเปลี่ยน DNS ล้างแคช เข้าโดเมนที่ไม่ใช่ TLS อนุมัติหน้าเกต แล้วค่อยเปลี่ยน DNS กลับ
    มันควรต้องมีอะไรสักอย่างมาจัดการเรื่องนี้ชัด ๆ

    • ถ้าเป็น macOS อาจแก้ได้ด้วย /etc/resolver
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      ผมเคยใช้วิธีนี้ตอนเว็บภายในมหาวิทยาลัย resolve ได้เฉพาะผ่าน nameserver ของเครือข่าย และคิดว่าน่าจะใช้กับ URL ที่ macOS ใช้ตรวจจับ captive portal ได้ด้วย ไว้ครั้งหน้าที่ไปร้านกาแฟต้องลองตรวจดู
    • บน macOS และ iOS สามารถสร้าง profile ที่ระบุ DNS server ที่จะใช้ตลอดเวลาได้ และจะมีผลกับ Wi‑Fi อื่น ๆ รวมถึงข้อมูลมือถือด้วย
      https://doh.lvv.me/
      ผมใช้สิ่งนี้มาหลายปีแล้ว และไม่เคยเจอปัญหากับฮอตสปอตสาธารณะ
    • ใส่ IP address ลงในแถบที่อยู่ไปตรง ๆ ก็ได้ โดยทั่วไปมักดัก ทราฟฟิกพอร์ต 80 ทั้งหมดอยู่แล้ว
    • เรื่องแบบนี้ระบบปฏิบัติการควรจัดการให้เป็นส่วนหนึ่งของ การรองรับ captive portal ควรติดต่อผู้ผลิตระบบปฏิบัติการแล้วแจ้งบั๊กไว้

  • ใช้ Unbound เป็น เซิร์ฟเวอร์ DoH ในเครื่อง แพ็กเกจ Unbound ของ Alpine Linux คอมไพล์มาพร้อมกับ libnghttp2 ที่จำเป็นสำหรับ DoH listener ในตัว และแค่นี้ก็เพียงพอสำหรับเปิดใช้ ECH แล้ว
    ใช้ cron ทุกชั่วโมงเพื่อพรีแคชโดเมนทั้งหมดที่ใช้บ่อย ISP คงไม่ไปยุ่งกับคำขอ DNS ของฉัน และพนักงานของพวกเขาก็เป็นคนประหลาดกว่าฉันเสียอีก ถ้าเริ่มดูเว็บบนมือถือ ก็คงสร้างเซิร์ฟเวอร์ DoH สาธารณะเอง ใช้เวลาไม่กี่นาที และยังได้ ล็อกการ query ของตัวเองเวลา debug ปัญหาแปลก ๆ ด้วย
    [1] - https://tls-ech.dev/

    • ใช้งาน DoH, DoT, DoQ, TCP, UDP ด้วยอินสแตนซ์เซิร์ฟเวอร์ public powerdns, dnsdist และเซิร์ฟเวอร์ recursive/authoritative ของตัวเองมาประมาณ 3 ปีแล้ว
      ก่อนหน้านี้เคยใช้ bind, unbound, dnsmasq เลยใช้เวลาตั้งค่าพอสมควร เสถียรมาก ใช้ได้ทั้งบนมือถือและอุปกรณ์รุ่นเก่า และยังใช้เป็น resolver ให้กับ unbound, adguard/dnsproxy หรือ resolve.conf ในเครื่องได้ด้วย
    • สงสัยว่าทำไมต้องพรีแคช ถ้าเพื่อความเร็วก็อย่างมากแค่ 30–50ms ไม่ใช่หรือ? ถ้า TTL ของ authoritative server สั้นกว่า 60 นาที ก็สงสัยว่าบังคับเป็น 3600 หรือเปล่า
      ยังสงสัยด้วยว่าตรวจ audit การเชื่อมต่อของทุกเว็บไซต์ที่เข้า เพื่อรวบรวมไปถึงโดเมนที่โฮสต์ asset แล้วพรีแคชทั้งหมดหรือไม่ หรือจริง ๆ แล้วสำคัญแค่โดเมนหลักของไซต์ที่มีผลต่อ latency ที่รู้สึกได้มากที่สุด
    • Unbound มี prefetch สำหรับต่ออายุ cache record ที่ใกล้หมดอายุ และยังมีตัวเลือกปรับแต่งเกี่ยวกับ cache กับ TTL อีกหลายอย่าง serve-expired ก็ดูเหมือนทำงานได้ดี
    • สงสัยว่า “ใช้ cron ทุกชั่วโมงเพื่อพรีแคชโดเมนทั้งหมดที่ใช้บ่อย” หน้าตาเป็นแบบไหน เป็น shell script ที่ query รายชื่อ hostname หรือเปล่า และเกณฑ์ของ “โดเมนที่ใช้” คืออะไร
    • ทางนี้ก็รัน Unbound อยู่เหมือนกัน ชอบตรงที่ใช้ wildcard ในการบล็อกโดเมนได้ ใช้ blocklist ขนาดใหญ่ แล้วมี allowlist เป็นข้อยกเว้นทับไว้ด้านบน
      ยังมีเครื่องมือเล็ก ๆ ที่ทำให้อินพุตอย่าง ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com กลายเป็น ads.acme.com แบบง่าย ๆ ด้วย
      อีกอย่างคือมีสคริปต์ที่สร้างรูปแบบแปรผันของโดเมนที่ใช้ เช่นถ้าโดเมนจริงคือ mybank.com ก็จะบล็อก myb4nk.com, mibank.com, mybank.{TLD อื่นทั้งหมด} และอื่น ๆ
      สร้างรูปแบบพวกนี้ออกมาเป็นหลายแสนรายการแล้วบล็อกทั้งหมดใน Unbound ทำแบบนี้หลังจากธนาคารส่งตัวอย่างเว็บ phishing ที่ดูน่าเชื่อถือมากมาให้ดู
      ใช้คอนฟิกนี้มาหลายปีแล้ว และ โดเมนที่บล็อกหนึ่งล้านรายการ ก็ยังรันได้ดีบน Pi 3 เก่า ๆ ถ้าเป็นคอมพิวเตอร์ที่แรงกว่านี้ Unbound น่าจะจัดการ blocklist ระดับหลายล้าน หรืออาจถึงหลายสิบล้านโดเมนได้ ยังไม่ได้ย้ายไปใช้แนวทาง allowlist-only
      บล็อกโดเมน Unicode ทั้งหมดด้วย โดเมนที่มีอักขระ Unicode ในชื่อจะเข้าไม่ได้ และฉันก็ไม่สนใจ

  • ใช้ NextDNS แล้วพอใจ มี ความสามารถในการตั้งค่า เยอะ เช่น จะเปิด filter list ไหน จะทำ logging อย่างไร เป็นต้น
    เสถียรและเร็วแทบทุกที่ ถ้ารัน resolver เองบนคลาวด์จะทำให้ได้แบบนี้ยากกว่า และยังไงก็ไม่อยากดูแลรักษาเองอยู่แล้ว

    • ฉันก็ใช้ NextDNS ได้ดีเหมือนกัน โดยเฉพาะหลังจากปรับแต่ง Pi-hole มาหลายปีจนเหนื่อยกับการดูแลรักษาแล้วก็ยิ่งพอใจ ใช้ร่วมกับ Mullvad VPN ได้ง่ายเมื่อต้องการด้วย
    • สำหรับฉันก็ถือว่าค่อนข้างดี

  • ไม่รู้ว่าทำไมมีแค่ 29 รายการ
    ผู้เขียนกำลังบอกว่าจำนวน open resolver จริง ๆ บนอินเทอร์เน็ตทุกวันนี้มีประมาณนี้หรือเปล่า
    สงสัยว่าจะพิจารณา “ความเป็นส่วนตัว” หรือ “ความปลอดภัย” ของ DNS แล้วไม่พิจารณา SNI ร่วมด้วยได้อย่างไร
    SNI ทำให้บุคคลที่สามเห็นได้ว่าผู้ใช้พยายามเชื่อมต่อไปยังชื่อโดเมนใดที่มีที่อยู่สาธารณะ และยังทำให้ขัดขวางการเชื่อมต่อนั้นได้ด้วย
    DNS ทำให้บุคคลที่สามเห็นได้เพียงว่าผู้ใช้ lookup ที่อยู่สาธารณะของชื่อโดเมนใดเท่านั้น หากจะเชื่อมโยงทราฟฟิกที่ไม่ใช่ DNS เข้ากับ query นี้ ก็ต้องอาศัยสมมติฐานเกี่ยวกับวิธีทำงานของซอฟต์แวร์นั้น
    ดังนั้นจึงไม่น่าแปลกใจที่บริษัทโฆษณาซึ่งครอบงำเว็บเบราว์เซอร์ยอดนิยม อยากให้ผู้ใช้เลือก DoH ภายในเบราว์เซอร์ หรือในระบบปฏิบัติการสำหรับองค์กร ถ้าเรียกมันอย่างหลอกลวงว่า “private DNS” บุคคลที่สามก็จะ correlate query กับทราฟฟิกที่ไม่ใช่ DNS ของซอฟต์แวร์ที่รันในเบราว์เซอร์หรือระบบปฏิบัติการสำหรับองค์กรได้มีประสิทธิภาพขึ้น
    คำกล่าวอ้างที่หลอกลวงแบบนี้อาจทำให้ถูกฟ้องได้ เช่น ในกรณีคำกล่าวอ้างที่หลอกลวงเรื่อง “private browsing” ผู้ใช้เคยชนะคดีมาแล้ว

    • 29 รายการนั้นหมายถึงบริการที่ผู้คนจำนวนมากไว้ใจในระดับหนึ่งว่าสามารถฝาก DNS query ไว้ได้ นอกจากนี้ 29 รายการนั้นยังเปิดเผยข้อมูลเกี่ยวกับคุณสมบัติของบริการด้วย
      ถ้าอ่านทั้งหน้า จะเห็นว่ามี public DNS resolver อื่น ๆ ที่ควรกล่าวถึงแยกไว้ด้วย
      ถ้าต้องการ open DNS resolver จำนวนมากที่ไม่เป็นที่รู้จักใน long tail ก็ใช้ Shodan ได้ แต่คงไม่อยากแนะนำให้ไว้ใจสิ่งที่เจอใน Shodan ถึงขั้นฝากการใช้อินเทอร์เน็ตไว้กับมัน
      SNI เป็นปัญหาความเป็นส่วนตัวของอินเทอร์เน็ตทั่วไปจริง แต่ไม่ใช่คุณสมบัติของ DNS มองในแง่ดีคือ ECH ผ่าน IETF แล้ว และจะค่อย ๆ เปิดให้ผู้ใช้ทั่วไปใช้
      — ผู้เขียน
    • ECH ยังไม่ได้เปิดให้ผู้ใช้เว็บทั่วไปใช้อย่างแพร่หลาย นอกจากไซต์ “ทดสอบ” บางแห่ง
      ในคำตอบของผู้เขียนก็ยังไม่ชัดว่า “you” หมายถึงใคร
      กรณีของฉัน ใช้ DNS ระยะไกลเฉพาะตอนดึงข้อมูล DNS จำนวนมากเป็นระยะ ๆ เท่านั้น เวลาเข้าถึง HTTP server จะไม่ส่งคำขอ DNS ระยะไกล ฉันมีข้อมูล IP address ที่ต้องใช้แล้ว และวิธีนี้เร็วกว่าและเสถียรกว่า
      โหลด ข้อมูล DNS จำนวนมาก จากหลายแหล่งไว้ในหน่วยความจำของ TLS forward proxy ในเครื่อง
      ผู้ใช้แต่ละคนไม่เหมือนกัน และแต่ละคนควรคิดเอง

  • ถ้าเป็นผู้ใช้ในแคนาดา CIRA ให้บริการ public resolver ผ่าน IPv4, IPv6, DoH และ DoT
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • ไม่แน่ใจว่าทำไมคนแคนาดาควรไว้ใจ CIRA มากกว่าทางเลือกอื่น ๆ แต่ก็มีแนวโน้มสูงว่าจะดีกว่าใช้ DNS เริ่มต้นของ ISP

  • DNScryptProxy ดูแลรายการเซิร์ฟเวอร์ DNS สาธารณะจำนวนมาก และยังระบุด้วยว่ารองรับ DNSSEC, การกรอง และการบันทึกล็อกหรือไม่
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • น่าจะดีถ้าเว็บไซต์แบบนี้มีการทดสอบ เปรียบเทียบความเร็ว พื้นฐานตามเครือข่ายโลคัล
    ถ้าเปรียบเทียบเวลา応答 P90 และเวลา応答ค่ามัธยฐานสำหรับการค้นหาแบบสุ่มได้ก็น่าจะดี

    • ผมเป็นผู้เขียน ตอนนี้เพิ่มแล้ว: https://evilbit.de/dns-resolver-guide2.html#speedtest
      แต่ทำงานเฉพาะกับ DoH เท่านั้น
    • ถ้าโคลนรีโพนี้แล้วแก้ชื่อโดเมนกับ resolver ตามต้องการ ก็น่าจะได้ผลลัพธ์คล้ายกับที่มองหาอยู่
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • ผมรันอินสแตนซ์ smokeping ไว้ในเครื่องเพื่อจุดประสงค์นี้ โดย ping ไปยัง DNS server หลายตัว, DNS ของ ISP และเว็บไซต์หลัก ๆ บางแห่ง แล้วอัปเดต upstream ของ DNS server ในเครื่องเป็นระยะตามผลลัพธ์นั้น
      ในสภาพแวดล้อมของผม DNS server รายใหญ่ทั้งหมดอยู่ในช่วง 5~6ms แต่ก็ไม่ได้เป็นแบบนั้นเสมอไป DNS ของ ISP ก็มีค่าเฉลี่ยใกล้เคียงกัน แต่ความแปรปรวนสูงและมี spike พุ่งไปถึง 50ms ทั้งที่ควรเป็นตำแหน่งที่เร็วที่สุด

  • DNS เป็นหัวข้อที่สำคัญมากต่อความเป็นส่วนตัวและความปลอดภัย ผมคิดว่าการโฮสต์ โครงสร้างพื้นฐานของตัวเอง ดีกว่าการเลือก DNS สาธารณะ
    ไม่จำเป็นต้องใช้อินสแตนซ์สาธารณะ แค่รัน ADGUARD, unbound, dnsmasq, dnsdist ในโหมด recursive บนเราเตอร์หรือเครื่องก็พอ
    และตั้งค่าข้อจำกัดกับรายการบล็อกได้ตามความต้องการ

    • ถึงอย่างนั้น ISP ก็ยังบันทึกทุก query ได้อยู่ดี