Hướng dẫn chọn public DNS resolver

 (evilbit.de)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Với public DNS resolver, không chỉ nên nhìn vào tốc độ mà còn phải xem xét đồng thời quyền riêng tư, khả năng lọc, phạm vi pháp lý, đơn vị vận hành và truyền tải được mã hóa; hướng dẫn này so sánh 30 dịch vụ toàn cầu theo từng nhu cầu
  • Công cụ lựa chọn dùng DoH·DoT·DoQ·DNSCrypt, xác thực DNSSEC, IPv6, phạm vi pháp lý, loại nhà vận hành và EDNS Client Subnet làm bộ lọc cứng, rồi chấm điểm mức ưu tiên theo mục đích sử dụng
  • Bài kiểm tra độ trễ DoH trên trình duyệt cho thấy tốc độ tương đối tại vị trí hiện tại, nhưng có bao gồm overhead TLS/HTTP và không đo được các resolver chỉ hỗ trợ DNS thuần văn bản
  • DNS được mã hóa giúp giảm nguy cơ bị nghe lén hoặc sửa đổi bởi bên trung gian, nhưng nhà cung cấp resolver được chọn vẫn có thể nhìn thấy các domain được truy vấn, nên cần cân nhắc cả chính sách không lưu log và thiết kế oblivious
  • Khi lựa chọn trong thực tế, cần xem xét cùng lúc DNSSEC, sự đánh đổi giữa tốc độ và quyền riêng tư của ECS, hiệu năng DoQ, đặc tính của DNSCrypt, giới hạn của phân tích lưu lượng, khác biệt về mức tuân thủ tiêu chuẩn, cũng như rủi ro về phạm vi pháp lý và tập trung hóa

Các tiêu chí mà công cụ lựa chọn so sánh

  • Public DNS resolver được so sánh theo cách người dùng đánh dấu các điều kiện mà họ coi trọng để tìm dịch vụ phù hợp
  • Các điều kiện dùng làm bộ lọc cứng
    • Truyền tải được mã hóa: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
    • Hỗ trợ xác thực DNSSEC
    • Cung cấp địa chỉ resolver IPv6
    • Phạm vi pháp lý của nhà vận hành
    • Loại nhà vận hành: phi lợi nhuận·cộng đồng·vì lợi ích công, thương mại, hoặc tất cả
    • EDNS Client Subnet(ECS): không dùng, có dùng, hoặc không quan trọng
  • Các hạng mục được đưa vào chấm điểm ưu tiên
    • Quyền riêng tư tối đa và không lưu log hoặc chỉ lưu log tối thiểu
    • Chặn malware·phishing
    • Chặn quảng cáo·tracker
    • Kiểm soát của phụ huynh và chặn nội dung người lớn
    • Không lọc, trả nguyên vẹn phản hồi DNS đã được công bố
    • Danh sách chặn·quy tắc tùy chỉnh thông qua tài khoản
    • Tốc độ độ trễ thấp toàn cầu dựa trên Anycast
    • Nhà vận hành phi thương mại

Kiểm tra tốc độ DoH theo vị trí hiện tại

  • Bài kiểm tra tích hợp đo thời gian khứ hồi từ trình duyệt tới từng resolver hỗ trợ DoH
  • Resolver chỉ hỗ trợ DNS thuần văn bản không thể kiểm tra bằng cách này
  • Kết quả chỉ mang tính tham khảo tương đối, và vì bao gồm overhead TLS và HTTP nên giả định là phải chạy nhiều lần
  • Do trình duyệt gửi truy vấn trực tiếp đến từng resolver, địa chỉ IP của người dùng sẽ lộ ra với resolver tương ứng
  • Cách triển khai bài kiểm tra lấy ý tưởng từ mã nguồn mở DNS Speed Test của Silviu Stroe nhưng là triển khai độc lập, và chỉ chạy khi trang được phục vụ qua HTTPS

Khác biệt giữa hiệu năng và truyền tải được mã hóa

  • Truyền tải được mã hóa như DoH và DoT làm tăng độ trễ trên mỗi truy vấn, nhưng tổng thời gian tải trang trong nhiều trường hợp vẫn gần với DNS thuần văn bản, và overhead của DoH trong môi trường thực tế cũng thường nhỏ
  • Trên các liên kết có mất gói hoặc độ trễ cao, Do53 thuần văn bản vẫn có lợi thế
  • Hiệu năng thay đổi theo nhà cung cấp và khu vực, nên resolver nhanh nhất còn phụ thuộc vào vị trí của người dùng
  • Trong các phép đo đầu-cuối quy mô lớn về DNS được mã hóa, xác suất truy vấn bị chặn giữa đường hoặc bị sửa đổi thấp hơn nhiều so với DNS thuần văn bản, và overhead là nhỏ
  • Tuy nhiên, trong nghiên cứu đó khoảng 25% nhà cung cấp DoT cung cấp chứng chỉ TLS không hợp lệ, nên việc chọn nhà cung cấp có chất lượng vận hành tốt là rất quan trọng

Giới hạn thực tế của quyền riêng tư

  • DNS được mã hóa che giấu truy vấn trên đường truyền mạng, nhưng nhà cung cấp resolver mà bạn chọn vẫn có thể thấy mọi domain bạn đã tra cứu
  • Nếu đây là vấn đề, hãy chọn nhà vận hành không lưu log hoặc cân nhắc các thiết kế oblivious như ODoH, nơi proxy tách riêng danh tính và truy vấn
  • Cloudflare và Apple là các trường hợp đã triển khai ODoH
  • Chỉ riêng DNS được mã hóa không thể che giấu hoàn toàn website đã truy cập
    • Ngay cả khi dùng DoH, phân tích lưu lượng vẫn có thể xác định domain đã truy cập với độ chính xác cao
    • Padding EDNS tiêu chuẩn cũng không ngăn chặn hoàn toàn điều này
    • Nếu mô hình đe dọa của bạn bao gồm nguy cơ này, đừng chỉ dựa vào padding mà hãy dùng thêm Tor hoặc thiết kế oblivious

DNSSEC, ECS, phạm vi pháp lý

  • Chỉ các resolver thực hiện xác thực DNSSEC mới bảo vệ được trước các bản ghi giả mạo
  • Google, Cloudflare và Quad9 đều xác thực DNSSEC, và đã xử lý lần rollover khóa gốc KSK đầu tiên mà không gây gián đoạn cho người dùng
  • Nếu tính toàn vẹn là quan trọng, nên xem xác thực DNSSEC là điều kiện bắt buộc
  • EDNS Client Subnet(ECS) gửi một phần IP tới CDN để định tuyến địa lý tốt hơn
    • Google và OpenDNS gửi ECS để có ánh xạ CDN chính xác hơn
    • Cloudflare và Quad9 tiêu chuẩn tắt ECS để bảo vệ quyền riêng tư
  • Nơi đăng ký pháp lý của nhà vận hành ảnh hưởng tới các biện pháp có thể bị cưỡng chế và việc lưu log
  • Một số ít nhà cung cấp đang xử lý tỷ trọng lớn lưu lượng recursive DNS trên toàn cầu
  • NSA của Mỹ cảnh báo rằng resolver bên ngoài có thể bỏ qua cơ chế lọc và kiểm tra DNS nội bộ, vì vậy cần cân nhắc sự cân bằng giữa tiện lợi và khả năng kiểm soát

DoQ và DNSCrypt

  • Trong các phép đo DoQ năm 2022, DNS-over-QUIC cho thời gian phản hồi vượt cả DoT lẫn DoH
  • Tuy vậy, do giới hạn xác thực địa chỉ của QUIC, khoảng 40% quá trình bắt tay đã chậm hơn
  • Nếu cả client và resolver đều hỗ trợ, DoQ là lựa chọn mã hóa nên được ưu tiên
    • Ví dụ hỗ trợ: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, và các dịch vụ lớn tại Trung Quốc
  • DNSCrypt là lựa chọn mã hóa cũ hơn DoH, DoT và DoQ; phiên bản 2 ra mắt vào năm 2013
  • DNSCrypt mã hóa ngay từ gói đầu tiên bằng khóa công khai được chia sẻ trước của resolver, nên không cần tra cứu hostname thuần văn bản hay phụ thuộc vào CA
  • Chế độ Anonymized DNS từ năm 2019 cũng che giấu cả IP của client
  • Trong các đối tượng so sánh, các nhà cung cấp DNSCrypt gồm Quad9, OpenDNS, AdGuard, NextDNS, Control D và Yandex
  • Thiếu số liệu sử dụng đáng tin cậy, và các phép đo quy mô lớn như APNIC Labs có theo dõi DoH và DoT nhưng không theo dõi DNSCrypt

Chất lượng triển khai resolver và dữ liệu vận hành

  • Trong nghiên cứu Extended DNS Errors năm 2023, các resolver lớn có báo cáo lỗi chẩn đoán không khớp trong 94% trường hợp thử nghiệm
  • Cloudflare cho thấy mức báo lỗi chính xác nhất trong nghiên cứu đó
  • Khác biệt về chất lượng triển khai và mức tuân thủ tiêu chuẩn giữa các resolver ảnh hưởng đến khả năng xử lý sự cố và độ tin cậy
  • Dữ liệu vận hành·cộng đồng có thể tham khảo
    • ICANN Identifier Technology Health Indicators: theo dõi tỷ lệ resolver xác thực DNSSEC và mức độ tập trung của resolver
    • DNS-OARC workshop talks và past-event archive: bài trình bày của nhà vận hành·nhà nghiên cứu về DNS được mã hóa, hiệu năng resolver và các phép đo
    • APNIC Labs measurements: dữ liệu theo quốc gia về tỷ lệ xác thực DNSSEC, mức sử dụng public resolver và mức chấp nhận DoH·DoT

Resolver quy mô nhỏ·cộng đồng·khu vực

  • Ngoài bảng so sánh còn có các resolver mang tính sở thích, cộng đồng hoặc chuyên biệt theo quốc gia, và cần kiểm tra tình trạng hiện tại cũng như chính sách trước khi sử dụng
  • Danh sách tại châu Âu được tổng hợp ở European Alternatives
  • Resolver ở các khu vực có kiểm duyệt mạnh hoặc chịu lệnh trừng phạt có thể áp dụng quy tắc nội dung địa phương hoặc được vận hành để vượt chặn địa lý, nên cần thận trọng hơn
  • Ví dụ dịch vụ
    • DNS4all: resolver châu Âu không lọc, ưu tiên tính trung lập và hiệu năng
    • BlahDNS: dự án chặn quảng cáo mã nguồn mở mang tính hobby, vận hành trên các máy chủ khu vực quy mô nhỏ, hỗ trợ DoH·DoT·DoQ
    • LibreDNS: resolver cộng đồng của LibreOps, chặn quảng cáo và chính sách không lưu log, hỗ trợ DoH·DoT
    • Dismail.de: resolver cộng đồng của Đức tập trung vào quyền riêng tư, không lưu log, hỗ trợ DoH·DoT
    • IIJ Public DNS: resolver DoH·DoT công khai của Internet Initiative Japan, chặn các domain liên quan đến tài liệu lạm dụng tình dục trẻ em
    • DNS for Family: DoH có lọc cho gia đình, bao gồm nội dung người lớn, cờ bạc, malware, quảng cáo·tracker và Safe Search
  • Các dịch vụ legacy hoặc đã ngừng hoạt động cần tránh được nhắc tới gồm Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu và Norton ConnectSafe

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Các ý kiến trên Hacker News

  • Mỗi khi thấy những danh sách kiểu này hoặc thông báo ra mắt dịch vụ mới, tôi không có nhiều cảm xúc, và trên Hacker News dường như cũng có khá nhiều phản ứng tương tự
    Tôi đã tự vận hành dịch vụ DNS proxy gần 25 năm, đã thử ba bộ phần mềm trên sáu hệ điều hành, và tất cả các mục trong tab bộ lọc đều là những thứ tôi có thể tự làm, và thực tế đang làm
    Điều thú vị ở danh sách này không phải là các lựa chọn thú vị, mà là những gì nó bộc lộ. Ví dụ, tất cả các mục được ghi là “China” đều được mô tả là “vận hành dưới sự quản lý của Trung Quốc”, nhưng đến năm 2026, đây là yếu tố đáng quan tâm không chỉ với các mục Trung Quốc mà cả với người dùng ở châu lục của tôi
    Cụm “do 1 cá nhân ở Đan Mạch vận hành” là một thông tin thú vị cho thấy bus factor, nhưng không thể giả định rằng các mục khác tốt hơn chỉ vì chúng không nói đến điểm đó. Có rất ít thông tin về người đứng sau DNS.Watch, ít hơn nhiều so với Thomas Steen Rasmussen, và có vẻ trong vài năm gần đây nó đã từng sập ít nhất một lần, nên đây là mối lo chính đáng
    Quad101 dường như có giới hạn khu vực sử dụng, và còn nhiều yếu tố không có trong danh sách này nhưng có thể quan trọng với người dùng, chẳng hạn như Gcore là một công ty AI

    • Việc “do 1 cá nhân ở Đan Mạch vận hành” thú vị ở khía cạnh giám sát tổ chức hơn là bus factor
      Khi nhiều người cùng tham gia vận hành, họ có thể giám sát lẫn nhau và nêu vấn đề nếu thấy điều gì bất thường, chẳng hạn như DNS resolver ghi log có chọn lọc hoặc can thiệp vào kết quả. Nếu một người vận hành tất cả thì không có ai kiềm chế người đó
      Bạn có thể nghĩ “người đó là người có nguyên tắc nên tuyệt đối sẽ không làm vậy”, nhưng sức ép từ cơ quan thực thi pháp luật có thể rất mạnh
    • Khoảng 2 năm trước tôi tự cấu hình resolver, và nó cứ thế chạy tốt. Chưa từng gặp vấn đề nào

  • Nếu dùng DNS chính thức của ISP, bạn có thể có được đường đi ngắn nhất có thể từ điểm handoff của ISP tới CDN hoặc trunk quốc tế. Ý là đừng dùng DNS phổ thông không biết cấu trúc của ISP
    ISP: tới Cloudflare 1ms
    Cloudflare: tới Cloudflare 10ms
    Tuy nhiên, lời khuyên này áp dụng cho những nước có luật quyền riêng tư tốt và không có giám sát nhà nước. Tức là không phải Mỹ

    • Nếu cần DNS không bị kiểm duyệt thì cách đó không ổn
    • Trên thực tế, dùng DNS chặn máy chủ quảng cáo có khả năng mang lại hiệu năng tổng thể tốt hơn
    • Tôi không biết những nước như vậy hiện nay có thật sự còn tồn tại không. Và đây không chỉ là vấn đề quyền riêng tư; hầu như mọi quốc gia đều muốn ngăn người dùng truy cập những nơi họ không muốn người dùng truy cập, và thường làm theo cách sơ sài như DNS mặc định của ISP chuyển bạn tới trang cảnh báo thay vì trang bạn định mở
      Vì vậy, dù đổi sang DNS như 8.8.8.8 không nhất thiết tăng quyền riêng tư, nó vẫn là bước lớn đầu tiên để cải thiện trải nghiệm duyệt web
    • Cloudflare, như đã biết rộng rãi, dùng anycast, nên dù truy cập từ đâu thì phản hồi DNS cũng giống nhau. Những con số được đưa ra khó có thể quy cho DNS
      Ngược lại, Cloudflare có thể rút ngắn truy vấn đệ quy đối với các dịch vụ của chính họ, nên có thể nhanh hơn ở bước phân giải tên; nếu cần, cũng có thể định tuyến theo vị trí bằng eDNS Client Subnet
    • Đổi DNS gần như không có tác dụng với quyền riêng tư. Người ta vẫn có thể đọc truy vấn DNS và SNI

  • Tôi cần lời khuyên về cách dùng DNS resolver cùng với Wi-Fi công cộng
    Nhiều Wi-Fi công cộng cần dùng DNS riêng của họ để có thể chuyển hướng tới màn hình chấp nhận điều khoản, và đôi khi còn yêu cầu xác nhận lại mỗi 30–60 phút
    Khi gặp sự cố, tôi nhận ra Internet bị đứng, ping google.com rồi chờ timeout, đoán xem có phải vấn đề của ISP không, rồi nhận ra có vẻ phiên Wi-Fi đã hết hạn, đổi DNS và xóa cache, sau đó truy cập một tên miền không dùng TLS, chấp nhận cổng, rồi lại đổi DNS về như cũ
    Chắc chắn phải có thứ gì đó quản lý được việc này

    • Nếu dùng macOS thì có thể giải quyết bằng /etc/resolver
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      Tôi từng dùng cách này khi các trang nội bộ của trường đại học chỉ phân giải được bằng nameserver của mạng. Tôi nghĩ nó cũng có thể áp dụng cho URL mà macOS dùng để phát hiện captive portal, lần tới đi quán cà phê tôi sẽ thử kiểm tra
    • Trên macOS và iOS, bạn có thể tạo profile chỉ định DNS server luôn được dùng. Nó cũng áp dụng cho Wi-Fi khác và dữ liệu di động
      https://doh.lvv.me/
      Tôi đã dùng cách này vài năm và chưa từng gặp vấn đề với hotspot công cộng
    • Chỉ cần nhập địa chỉ IP vào thanh địa chỉ là được. Thường thì họ chặn bắt toàn bộ lưu lượng cổng 80
    • Những việc như thế này nên được hệ điều hành xử lý như một phần của hỗ trợ captive portal. Tốt nhất là liên hệ nhà sản xuất hệ điều hành và báo lỗi

  • Dùng Unbound cục bộ như một máy chủ DoH. Gói Unbound của Alpine Linux được biên dịch kèm libnghttp2 cần cho listener DoH tích hợp, và như vậy là đủ để bật ECH
    Mỗi giờ dùng cron để cache trước tất cả các domain hay dùng. ISP sẽ không động vào các yêu cầu DNS của tôi, và nhân viên của họ còn kỳ quặc hơn tôi. Nếu bắt đầu lướt web bằng điện thoại, tôi sẽ tự dựng một máy chủ DoH công cộng. Chỉ mất vài phút, và khi debug các vấn đề kỳ lạ tôi còn có được log truy vấn của mình
    [1] - https://tls-ech.dev/

    • Tôi đã vận hành DoH, DoT, DoQ, TCP, UDP khoảng 3 năm nay bằng các instance powerdns, dnsdist, máy chủ đệ quy/thẩm quyền public tự quản
      Trước đây tôi dùng bind, unbound, dnsmasq nên phần cấu hình mất một chút thời gian. Nó rất ổn định, dùng được cả trên di động hay thiết bị cũ, và cũng có thể dùng làm resolver cho unbound, adguard/dnsproxy, resolve.conf cục bộ
    • Tôi tò mò vì sao lại cache trước. Nếu vì tốc độ thì nhiều lắm cũng chỉ 30–50ms không phải sao? Nếu TTL của máy chủ thẩm quyền ngắn hơn 60 phút thì có ép thành 3600 không cũng là điều tôi thắc mắc
      Tôi cũng tò mò là bạn audit kết nối của mọi website mình truy cập để gom cả các domain host asset rồi cache trước toàn bộ, hay chỉ domain chính của site — thứ ảnh hưởng nhiều nhất đến độ trễ cảm nhận — mới quan trọng
    • Unbound có prefetch để làm mới các bản ghi cache gần hết hạn, và cũng có khá nhiều tùy chọn tinh chỉnh liên quan đến cache và TTL. serve-expired dường như cũng hoạt động tốt
    • Tôi tò mò “mỗi giờ dùng cron để cache trước tất cả các domain hay dùng” trông cụ thể như thế nào. Có phải là một shell script truy vấn danh sách hostname không, và tiêu chí nào để xác định “domain đang dùng”?
    • Ở đây tôi cũng chạy Unbound. Tôi thích việc có thể dùng wildcard để chặn domain. Tôi dùng một danh sách chặn lớn, rồi đặt danh sách ngoại lệ cho phép ở phía trên
      Tôi cũng có một công cụ nhỏ để đơn giản hóa các đầu vào như ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com thành ads.acme.com
      Ngoài ra tôi có script tạo các biến thể của domain mình dùng. Ví dụ nếu domain hợp lệ là mybank.com thì chặn myb4nk.com, mibank.com, mybank.{mọi TLD khác} v.v.
      Tôi tạo ra hàng trăm nghìn biến thể như vậy và chặn tất cả trong Unbound. Tôi làm như thế sau khi ngân hàng gửi một ví dụ về website phishing trông cực kỳ thuyết phục
      Tôi đã dùng cấu hình này vài năm rồi, và một triệu domain bị chặn vẫn chạy tốt trên Pi 3 cũ. Với máy tính mạnh hơn, Unbound có lẽ xử lý được danh sách chặn hàng triệu, thậm chí có thể hàng chục triệu domain. Tôi vẫn chưa chuyển sang cách chỉ dùng danh sách cho phép
      Tôi cũng chặn toàn bộ domain Unicode. Những domain dùng ký tự Unicode trong tên sẽ không truy cập được, và tôi không bận tâm

  • Tôi đang dùng NextDNS và khá hài lòng. Có nhiều khả năng cấu hình, như bật danh sách lọc nào, ghi log ra sao, v.v.
    Nó ổn định và nhanh hầu như ở mọi nơi. Tự vận hành resolver trên cloud thì khó đạt được hơn, mà dù sao tôi cũng không muốn bảo trì

    • Tôi cũng dùng NextDNS rất ổn. Đặc biệt là sau vài năm mày mò Pi-hole rồi mệt vì bảo trì, tôi càng hài lòng hơn. Khi cần cũng dễ dùng cùng Mullvad VPN
    • Với tôi nó cũng khá tốt

  • Không hiểu vì sao chỉ có 29 cái
    Tác giả muốn nói rằng số resolver mở thực tế trên Internet ngày nay chỉ khoảng chừng đó sao
    Tôi thắc mắc làm sao có thể xét đến “quyền riêng tư” hay “bảo mật” của DNS mà lại không xét kèm SNI
    SNI cho phép bên thứ ba thấy người dùng đang muốn kết nối tới domain nào tại một địa chỉ công khai, và cũng cho phép họ cản trở kết nối đó
    DNS chỉ cho phép bên thứ ba thấy người dùng đang tra cứu địa chỉ công khai cho domain nào. Để liên kết lưu lượng không phải DNS với truy vấn này thì cần giả định về cách phần mềm đó hoạt động
    Vì vậy không có gì ngạc nhiên khi các công ty quảng cáo đang chi phối các trình duyệt web phổ biến muốn người dùng chọn DoH trong trình duyệt, hoặc trong hệ điều hành doanh nghiệp. Nếu gọi nó một cách đánh lừa là “private DNS”, bên thứ ba có thể tương quan truy vấn với lưu lượng không phải DNS của phần mềm chạy trong trình duyệt hoặc hệ điều hành doanh nghiệp hiệu quả hơn
    Những tuyên bố gây hiểu lầm như vậy có thể dẫn tới kiện tụng. Ví dụ, người dùng từng thắng kiện vì các tuyên bố gây hiểu lầm về “private browsing”

    • Con số 29 đó nghĩa là các dịch vụ mà nhiều người phần nào tin tưởng để giao phó truy vấn DNS. Ngoài ra, 29 dịch vụ đó công khai thông tin về thuộc tính dịch vụ
      Nếu đọc toàn bộ trang, cũng có liệt kê riêng các resolver DNS công cộng khác đáng nhắc tới
      Nếu muốn tìm phần đuôi dài các resolver DNS mở ít được biết đến thì có thể dùng Shodan. Tuy nhiên tôi không khuyến nghị tin tưởng những thứ tìm thấy trên Shodan đến mức giao phó việc sử dụng Internet của mình
      SNI đúng là một vấn đề quyền riêng tư Internet nói chung, nhưng không phải là thuộc tính của DNS. Nhìn theo hướng tích cực thì ECH đã được IETF thông qua và sẽ dần được cung cấp cho người dùng phổ thông
      — tác giả
    • Ngoài vài site “thử nghiệm”, ECH chưa được cung cấp rộng rãi cho người dùng web phổ thông
      Cũng không rõ chữ “you” trong câu trả lời của tác giả là chỉ ai
      Trong trường hợp của tôi, tôi chỉ dùng DNS từ xa khi định kỳ lấy dữ liệu DNS hàng loạt. Khi truy cập máy chủ HTTP, tôi không gửi yêu cầu DNS từ xa. Tôi đã có sẵn thông tin địa chỉ IP cần thiết, và cách này nhanh hơn, ổn định hơn
      Tôi nạp dữ liệu DNS hàng loạt từ nhiều nguồn vào bộ nhớ của proxy chuyển tiếp TLS cục bộ
      Người dùng đều khác nhau, và mỗi người cần tự suy nghĩ

  • Nếu là người dùng ở Canada, CIRA vận hành resolver công cộng qua IPv4, IPv6, DoH, DoT
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Tôi không rõ vì sao người Canada nên tin CIRA hơn các lựa chọn khác. Dù vậy, nhiều khả năng nó vẫn tốt hơn dùng DNS mặc định của ISP

  • DNScryptProxy duy trì một danh sách rất lớn các máy chủ DNS công cộng. Danh sách này cũng cho biết có hỗ trợ DNSSEC, lọc và ghi log hay không
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Sẽ rất hay nếu các trang như thế này cung cấp một bài kiểm tra so sánh tốc độ cơ bản dựa trên mạng cục bộ
    Có lẽ sẽ hữu ích nếu có thể so sánh thời gian phản hồi P90 và thời gian phản hồi trung vị cho các truy vấn ngẫu nhiên

    • Tôi là tác giả, và giờ đã thêm vào: https://evilbit.de/dns-resolver-guide2.html#speedtest
      Tuy nhiên chỉ hoạt động với DoH
    • Nếu clone repository này rồi sửa tên miền và resolver theo ý muốn, bạn có thể nhận được kết quả gần giống với thứ đang tìm
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • Tôi đang chạy một instance smokeping cục bộ cho mục đích này. Nó ping nhiều máy chủ DNS, DNS của ISP và một vài website lớn, rồi định kỳ cập nhật upstream của máy chủ DNS cục bộ theo kết quả đó
      Trong môi trường của tôi, các máy chủ DNS lớn đều nằm trong khoảng 5–6ms, nhưng không phải lúc nào cũng vậy. DNS của ISP cũng có trung bình tương tự, nhưng độ phân tán lớn và có các spike vọt lên tới 50ms. Dù lẽ ra đó phải là vị trí nhanh nhất

  • DNS là một chủ đề rất quan trọng đối với quyền riêng tư và bảo mật. Tôi cho rằng tốt hơn là host hạ tầng riêng thay vì chọn DNS công cộng
    Không cần một instance công cộng. Chỉ cần chạy ADGUARD, unbound, dnsmasq, dnsdist ở chế độ đệ quy trên router hoặc máy của bạn
    Bạn cũng có thể cấu hình các giới hạn và danh sách chặn theo nhu cầu

    • Dù vậy ISP vẫn có thể ghi lại mọi truy vấn