# 공용 DNS 리졸버 선택 가이드

> Clean Markdown view of GeekNews topic #30914. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30914](https://news.hada.io/topic?id=30914)
- GeekNews Markdown: [https://news.hada.io/topic/30914.md](https://news.hada.io/topic/30914.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-29T07:41:13+09:00
- Updated: 2026-06-29T07:41:13+09:00
- Original source: [evilbit.de](https://evilbit.de/dns-resolver-guide.html)
- Points: 1
- Comments: 1

## Topic Body

- 공용 DNS 리졸버는 단순 속도보다 **개인정보 보호, 필터링, 관할권, 운영 주체, 암호화 전송**을 함께 봐야 하며, 이 가이드는 30개 글로벌 서비스를 요구사항별로 비교함
- 선택 도구는 DoH·DoT·DoQ·DNSCrypt, **DNSSEC 검증**, IPv6, 관할권, 운영자 유형, EDNS Client Subnet을 하드 필터로 쓰고 목적별 우선순위를 점수화함
- 브라우저 기반 **DoH 지연시간 테스트**는 현재 위치에서의 상대적 속도를 보여주지만, TLS/HTTP 오버헤드가 포함되고 평문 DNS 전용 리졸버는 측정하지 못함
- 암호화 DNS는 중간자의 감청·변조를 줄이지만, 선택한 **리졸버 제공자**는 조회 도메인을 볼 수 있어 무로그 정책과 oblivious 설계까지 고려해야 함
- 실무 선택에서는 DNSSEC, ECS의 속도-프라이버시 교환, DoQ 성능, DNSCrypt 특성, 트래픽 분석 한계, 표준 준수 차이, 관할권과 중앙화 위험을 함께 따져야 함

---

### 선택 도구가 비교하는 기준
- 공용 DNS 리졸버는 사용자가 중요하게 보는 조건을 체크해 찾는 방식으로 비교함
- **하드 필터**로 쓰이는 조건
  - 암호화 전송: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
  - DNSSEC 검증 지원
  - IPv6 리졸버 주소 제공
  - 운영자 관할권
  - 운영자 유형: 비영리·커뮤니티·공익, 상업, 전체
  - EDNS Client Subnet(ECS): 사용 안 함, 사용함, 상관없음
- **우선순위 점수화**에 들어가는 항목
  - 최대 개인정보 보호와 무로그 또는 최소 로그
  - 악성코드·피싱 차단
  - 광고·트래커 차단
  - 자녀 보호와 성인 콘텐츠 차단
  - 게시된 DNS 응답을 그대로 반환하는 무필터링
  - 계정을 통한 사용자 지정 차단 목록·규칙
  - 글로벌 Anycast 기반 저지연 속도
  - 비상업 운영자

### 현재 위치 기준 DoH 속도 테스트
- 내장 테스트는 브라우저에서 각 **DoH 지원 리졸버**까지의 왕복 시간을 측정함
- 평문 DNS만 지원하는 리졸버는 이 방식으로 테스트할 수 없음
- 결과는 상대적 참고값이며 TLS와 HTTP 오버헤드가 포함되므로 여러 번 실행하는 것이 전제임
- 브라우저가 각 리졸버에 직접 질의하기 때문에 사용자의 **IP 주소가 해당 리졸버에 노출**됨
- 테스트 구현은 Silviu Stroe의 오픈소스 [DNS Speed Test](https://dnsspeedtest.online/)에서 아이디어를 얻었지만 독립 구현이며, 페이지가 HTTPS로 제공될 때만 실행됨

### 성능과 암호화 전송의 차이
- **DoH와 DoT** 같은 암호화 전송은 질의당 지연시간을 추가하지만, 전체 페이지 로드 시간은 평문 DNS와 가까운 경우가 많고 DoH 오버헤드도 실제 환경에서 작게 나타남
- 손실이 있거나 지연시간이 높은 링크에서는 평문 Do53이 여전히 유리함
- 성능은 제공자와 지역에 따라 달라지므로 가장 빠른 리졸버는 사용자의 위치에 좌우됨
- 암호화 DNS의 대규모 종단 간 측정에서는 평문 DNS보다 질의가 전송 중 가로채이거나 변경될 가능성이 훨씬 낮고 오버헤드는 작았음
- 다만 해당 연구에서 DoT 제공자의 약 **25%가 유효하지 않은 TLS 인증서**를 제공했으므로 운영 품질이 좋은 제공자를 고르는 것이 중요함

### 개인정보 보호의 실제 한계
- 암호화 DNS는 네트워크에서 질의를 숨기지만, 선택한 **리졸버 제공자**는 조회한 모든 도메인을 볼 수 있음
- 이 점이 문제라면 무로그 운영자를 고르거나, 프록시가 신원과 질의를 분리하는 **ODoH** 같은 oblivious 설계를 고려해야 함
- Cloudflare와 Apple은 ODoH를 배포한 사례임
- 암호화 DNS만으로 방문 사이트가 완전히 숨겨지지는 않음
  - DoH를 사용해도 트래픽 분석으로 방문 도메인을 높은 정확도로 식별할 수 있음
  - 표준 EDNS 패딩도 이를 완전히 막지 못함
  - 이 위협 모델이 해당된다면 패딩에만 의존하지 말고 Tor나 oblivious 설계를 함께 써야 함

### DNSSEC, ECS, 관할권
- **DNSSEC 검증**을 수행하는 리졸버만 위조된 레코드로부터 보호함
- Google, Cloudflare, Quad9은 DNSSEC를 검증하며, 첫 루트 키 KSK 롤오버를 사용자 장애 없이 처리함
- 무결성이 중요하면 DNSSEC 검증을 필수 조건으로 봐야 함
- **EDNS Client Subnet(ECS)** 은 더 나은 지리적 라우팅을 위해 IP 일부를 CDN에 보냄
  - Google과 OpenDNS는 더 정밀한 CDN 매핑을 위해 ECS를 보냄
  - Cloudflare와 표준 Quad9은 프라이버시를 위해 ECS를 끔
- 운영자의 법적 소재지는 강제 가능 조치와 로그에 영향을 줌
- 소수 제공자가 전 세계 재귀 DNS 트래픽의 큰 비중을 처리하고 있음
- 미국 NSA는 외부 리졸버가 내부 DNS 필터링과 검사를 우회한다고 경고했으므로, 편의성과 통제 사이의 균형을 따져야 함

### DoQ와 DNSCrypt
- 2022년 DoQ 측정에서는 **DNS-over-QUIC**이 응답 시간에서 DoT와 DoH를 모두 앞섰음
- 다만 QUIC의 주소 검증 제한 때문에 핸드셰이크의 약 **40%가 느려졌음**
- 클라이언트와 리졸버가 모두 지원한다면 DoQ가 선호할 암호화 옵션임
  - 지원 예시: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, 중국 주요 서비스들
- **DNSCrypt**는 DoH, DoT, DoQ보다 오래된 암호화 옵션이며 버전 2는 2013년에 나옴
- DNSCrypt는 리졸버의 사전 공유 공개키로 첫 패킷부터 암호화하므로 평문 호스트명 조회와 인증기관 의존성이 없음
- 2019년의 Anonymized DNS 모드는 클라이언트 IP도 숨김
- 비교 대상 중 DNSCrypt 제공자는 Quad9, OpenDNS, AdGuard, NextDNS, Control D, Yandex임
- 신뢰할 만한 사용량 수치는 부족하며, [APNIC Labs](https://stats.labs.apnic.net/edns) 같은 대규모 측정은 DoH와 DoT를 추적하지만 DNSCrypt는 추적하지 않음

### 리졸버 구현 품질과 운영 데이터
- 2023년 Extended DNS Errors 연구에서 주요 리졸버들은 진단 오류 보고가 테스트 사례의 **94%에서 불일치**했음
- Cloudflare는 해당 연구에서 가장 정밀한 오류 보고를 보였음
- 리졸버별 구현 품질과 표준 준수 차이는 문제 해결과 신뢰성에 영향을 줌
- 참고 가능한 운영·커뮤니티 데이터
  - ICANN [Identifier Technology Health Indicators](https://ithi.research.icann.org/): DNSSEC 검증 리졸버 비율과 리졸버 집중도 추적
  - DNS-OARC [workshop talks](https://www.youtube.com/DNS-OARC)와 [past-event archive](https://indico.dns-oarc.net/): 암호화 DNS, 리졸버 성능, 측정 관련 운영자·연구자 발표
  - APNIC Labs [measurements](https://labs.apnic.net/measurements/): 국가별 DNSSEC 검증률, 공용 리졸버 사용, DoH·DoT 채택 데이터

### 소규모·커뮤니티·지역 리졸버
- 비교표 밖에도 취미, 커뮤니티, 국가별 특화 리졸버가 있으며, 사용 전 현재 상태와 정책을 확인해야 함
- 유럽 항목은 [European Alternatives](https://european-alternatives.eu/category/public-dns)에 정리되어 있음
- 강한 검열이나 제재가 있는 지역의 리졸버는 현지 콘텐츠 규칙을 적용하거나 지리적 차단 우회를 위해 운영될 수 있으므로 더 주의가 필요함
- 예시 서비스
  - [DNS4all](https://dns4all.eu/): 중립성과 성능을 중시하는 유럽 무필터링 리졸버
  - [BlahDNS](https://blahdns.com/): 소규모 지역 서버에서 운영되는 오픈소스 취미 광고 차단 프로젝트, DoH·DoT·DoQ 지원
  - [LibreDNS](https://libredns.gr/): LibreOps의 커뮤니티 리졸버, 광고 차단과 무로그 정책, DoH·DoT 지원
  - [Dismail.de](https://dismail.de/): 개인정보 보호 중심 독일 커뮤니티 리졸버, 무로그, DoH·DoT 지원
  - [IIJ Public DNS](https://public.dns.iij.jp/): Internet Initiative Japan의 공개 DoH·DoT 리졸버, 아동 성착취물 도메인 차단
  - [DNS for Family](https://dnsforfamily.com/): 성인물, 도박, 악성코드, 광고·트래커, 안전 검색을 포함한 가족 필터링 DoH
- 피해야 할 레거시 또는 중단 서비스로 Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu, Norton ConnectSafe가 언급됨

## Comments



### Comment 60650

- Author: neo
- Created: 2026-06-29T07:41:14+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48702273) 
- 이런 목록이나 새 서비스 발표를 볼 때마다 크게 감흥이 없고, Hacker News에서도 의외로 비슷한 반응이 많아 보임  
  25년 가까이 직접 **프록시 DNS 서비스**를 운영해 왔고, 세 가지 소프트웨어 묶음을 여섯 운영체제에서 써 봤는데, 필터 탭의 항목들은 전부 직접 할 수 있고 실제로 하고 있음  
  이 목록은 선택지가 흥미롭다기보다 드러나는 점이 흥미로움. 예를 들어 ‘China’로 표시된 항목은 모두 ‘중국 규제하에 운영’이라고 되어 있는데, 2026년에는 중국 항목뿐 아니라 내 대륙의 사용자에게도 신경 쓰이는 요소임  
  ‘덴마크의 개인 1명이 운영’이라는 문구는 **버스 팩터**를 드러내는 흥미로운 정보지만, 다른 항목들이 그 점을 말하지 않는다고 더 낫다고 가정할 수는 없음. DNS.Watch 뒤에 누가 있는지는 Thomas Steen Rasmussen보다 훨씬 정보가 적고, 최근 몇 년 사이 최소 한 번은 내려간 듯하니 정당한 우려임  
  Quad101은 이용 가능 지역 제한이 있어 보이고, Gcore는 AI 회사라는 점처럼 이 목록에 없지만 사용자에게 중요할 수 있는 요소도 많음
  - ‘덴마크의 개인 1명이 운영’이라는 건 버스 팩터보다 **조직적 감시** 측면에서 더 흥미로움  
    운영에 여러 사람이 관여하면 서로 감시하고, DNS 리졸버가 선택적 로깅을 하거나 결과에 개입하는 등 이상한 일이 보이면 문제를 제기할 수 있음. 한 사람이 전부 운영하면 그 사람을 제지할 사람이 없음  
    “그 사람은 원칙 있는 사람이니 절대 그러지 않을 것”이라고 생각할 수도 있지만, 법 집행기관의 압박은 강력할 수 있음
  - 2년쯤 전에 직접 **리졸버**를 구성했는데 그냥 잘 돌아감. 한 번도 문제가 없었음

- ISP의 공식 DNS를 쓰면 ISP 핸드오프 지점에서 CDN이나 해외 트렁크까지 가능한 **최단 경로**를 얻을 수 있음. ISP 구조를 모르는 범용 DNS를 쓰지 말라는 얘기임  
  ISP: Cloudflare까지 1ms  
  Cloudflare: Cloudflare까지 10ms  
  단, 이 조언은 프라이버시 법이 좋고 국가 감시가 없는 나라에 해당함. 즉 미국은 아님
  - 검열 없는 DNS가 필요하다면 그 방법은 좋지 않음
  - 실제로는 **광고 서버를 차단하는 DNS**를 쓰는 편이 전체 성능이 더 나을 가능성이 큼
  - 그런 나라들이 지금도 실제로 존재하긴 하는지 모르겠음. 그리고 이건 프라이버시만의 문제가 아니라, 거의 모든 국가는 사용자가 접근하지 않길 바라는 곳에 접근하지 못하게 하려 들고, 대개는 ISP 기본 DNS가 원래 열려던 사이트 대신 경고 페이지로 보내는 식의 허술한 방식임  
    그래서 8.8.8.8 같은 DNS로 바꾸는 것이 프라이버시를 반드시 높이지는 않더라도, **브라우징 경험 개선**의 첫 번째 큰 단계가 됨
  - Cloudflare는 잘 알려진 대로 **애니캐스트**를 쓰기 때문에 어디서 오든 DNS 응답은 같음. 제시한 숫자는 DNS 때문이라고 보기 어려움  
    오히려 Cloudflare는 자사 서비스에 대해 재귀 조회를 단축할 수 있어 이름 해석 단계에서 빨라질 수 있고, 필요하다면 eDNS 클라이언트 서브넷으로 위치 기반 라우팅도 가능함
  - DNS를 바꿔도 프라이버시에는 거의 효과가 없음. 여전히 **DNS 질의와 SNI**를 읽을 수 있기 때문임

- 공용 와이파이에서 DNS 리졸버를 함께 쓰는 방법에 조언이 필요함  
  많은 공용 와이파이는 자체 DNS를 써야 약관 동의 화면으로 리다이렉트할 수 있고, 30~60분마다 재승인을 요구하기도 함  
  문제가 생기면 인터넷이 멈춘 걸 알아차리고, google.com에 ping을 날려 타임아웃을 기다리고, ISP 문제인지 추측하다가 와이파이 세션이 만료된 것 같다고 깨닫고, DNS를 바꾸고 캐시를 비운 뒤, TLS가 아닌 도메인에 접속하고, 게이트를 승인하고, 다시 DNS를 되돌려야 함  
  분명 이런 걸 관리해 주는 무언가가 있어야 함
  - macOS라면 `/etc/resolver`로 해결할 수 있을지도 모름  
    `sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'`  
    대학 내부 사이트가 네트워크 네임서버로만 해석될 때 이 방식을 썼음. macOS가 **캡티브 포털** 감지에 쓰는 URL에도 적용될 수 있겠다는 생각이 들었고, 다음에 카페에 가면 확인해 봐야 함
  - macOS와 iOS에서는 항상 사용할 DNS 서버를 지정하는 **프로파일**을 만들 수 있음. 다른 와이파이와 모바일 데이터에서도 적용됨  
    [https://doh.lvv.me/](<https://doh.lvv.me/>)  
    몇 년째 이걸 쓰고 있고 공용 핫스팟에서 문제를 겪은 적이 없음
  - 주소창에 그냥 IP 주소를 넣으면 됨. 보통은 **80번 포트 트래픽**을 전부 가로채고 있음
  - 이런 건 운영체제가 **캡티브 포털 지원**의 일부로 처리해야 함. 운영체제 제작사에 연락해서 버그를 등록하는 게 좋겠음

- 로컬에서 Unbound를 **DoH 서버**로 사용함. Alpine Linux의 Unbound 패키지는 내장 DoH 리스너에 필요한 `libnghttp2`와 함께 컴파일되어 있고, 이 정도면 ECH를 켜기에 충분함  
  매시간 cron으로 자주 쓰는 모든 도메인을 미리 캐시함. ISP가 내 DNS 요청을 건드리지는 않을 것이고, 그 직원들이 나보다 더 이상한 사람들임. 휴대폰으로 웹을 보기 시작한다면 직접 공용 DoH 서버를 만들 것임. 몇 분이면 되고, 이상한 문제를 디버깅할 때 내 **질의 로그**도 얻을 수 있음  
  [1] - [https://tls-ech.dev/](<https://tls-ech.dev/>)
  - 약 3년째 자체 public `powerdns`, `dnsdist`, 재귀/권한 서버 인스턴스로 DoH, DoT, DoQ, TCP, UDP를 운영 중임  
    이전에는 `bind`, `unbound`, `dnsmasq`를 썼기 때문에 설정에는 시간이 좀 걸렸음. 매우 안정적이고, 모바일이나 구형 기기에서도 쓸 수 있으며 `unbound`, `adguard/dnsproxy`, 로컬 `resolve.conf`의 리졸버로도 사용 가능함
  - 왜 미리 캐시하는지 궁금함. 속도 때문이라면 많아야 30~50ms 아닌가? 권한 서버의 TTL이 60분보다 짧으면 3600으로 강제하는지 궁금함  
    방문하는 모든 웹사이트의 연결을 감사해서 자산을 호스팅하는 도메인까지 모아 전부 미리 캐시하는지, 아니면 체감 지연에 가장 큰 영향을 주는 메인 사이트 도메인만 중요한지도 궁금함
  - Unbound에는 만료가 가까운 캐시 레코드를 갱신하는 **prefetch**가 있고, 캐시와 TTL 관련 조정 옵션도 여럿 있음. `serve-expired`도 잘 동작하는 듯했음
  - “매시간 cron으로 자주 쓰는 모든 도메인을 미리 캐시한다”는 게 어떤 형태인지 궁금함. 호스트명 목록을 질의하는 셸 스크립트인지, 그리고 “사용하는 도메인”의 기준이 무엇인지 궁금함
  - 여기서도 Unbound를 돌리고 있음. 도메인 차단에 **와일드카드**를 쓸 수 있는 점이 좋음. 큰 차단 목록을 쓰고, 그 위에 예외 허용 목록을 둠  
    `ayt7.ads.acme.com`, `afi6.ads.acme.com`, `foi5.ads.acme.com` 같은 입력을 `ads.acme.com`으로 단순화하는 작은 도구도 있음  
    또 사용하는 도메인의 변형을 생성하는 스크립트를 둠. 예를 들어 정상 도메인이 `mybank.com`이면 `myb4nk.com`, `mibank.com`, `mybank.{다른 모든 TLD}` 등을 차단함  
    이런 변형을 수십만 개 생성해서 모두 Unbound에서 차단함. 은행에서 매우 그럴듯한 피싱 사이트 예시를 보내온 뒤 이렇게 만들었음  
    몇 년째 이 구성을 쓰고 있고, **백만 개 차단 도메인**도 오래된 Pi 3에서 잘 돌아감. 더 강력한 컴퓨터라면 Unbound가 수백만, 어쩌면 수천만 도메인의 차단 목록도 처리할 수 있을 것임. 아직 허용 목록 전용 방식으로 옮기지는 않았음  
    유니코드 도메인도 전부 차단함. 이름에 유니코드 문자를 쓰는 도메인은 접속할 수 없고, 신경 쓰지 않음

- NextDNS를 만족하며 쓰고 있음. 어떤 필터 목록을 켤지, 로깅을 어떻게 할지 등 **설정 가능성**이 많음  
  거의 어디서든 안정적이고 빠름. 클라우드에서 직접 리졸버를 운영하면 달성하기 더 어렵고, 어차피 유지보수하고 싶지 않음
  - 나도 NextDNS를 잘 쓰고 있음. 특히 Pi-hole을 몇 년 만지다가 유지보수에 지친 뒤 더 만족함. 필요할 때 **Mullvad VPN**과도 쉽게 함께 쓸 수 있음
  - 나한테도 꽤 괜찮았음

- 왜 29개뿐인지 모르겠음  
  작성자가 오늘날 인터넷의 개방형 리졸버 실제 개수가 이 정도라고 말하는 건가  
  DNS의 “프라이버시”나 “보안”을 고려하면서 어떻게 **SNI**를 함께 고려하지 않을 수 있는지 의문임  
  SNI는 사용자가 어떤 도메인 이름에 공개된 주소로 연결하려는지 제3자가 볼 수 있게 하고, 그런 연결을 방해할 수도 있게 함  
  DNS는 사용자가 어떤 도메인 이름에 공개된 주소를 조회하는지만 제3자가 볼 수 있게 함. DNS가 아닌 트래픽을 이 질의와 연결하려면 해당 소프트웨어가 어떻게 동작하는지에 대한 가정이 필요함  
  그래서 인기 웹브라우저를 지배하는 광고 회사들이 사용자가 브라우저 안에서, 또는 기업용 운영체제에서 DoH를 선택하길 원하는 건 놀랍지 않음. 이를 기만적으로 “private DNS”라고 부르면, 제3자가 브라우저나 기업용 운영체제에서 실행되는 소프트웨어의 비-DNS 트래픽과 질의를 더 효과적으로 상관분석할 수 있음  
  이런 기만적 주장 때문에 소송을 당할 수도 있음. 예를 들어 “private browsing”에 대한 기만적 주장으로는 사용자가 소송에서 이긴 적이 있음
  - 그 29개는 많은 사람이 DNS 질의를 맡겨도 된다고 어느 정도 신뢰하는 서비스들이라는 뜻임. 또한 그 29개는 서비스 속성에 대한 정보를 공개함  
    전체 페이지를 읽으면 언급할 만한 다른 공용 DNS 리졸버도 따로 나열되어 있음  
    알려지지 않은 긴 꼬리의 개방형 DNS 리졸버는 Shodan을 쓰면 됨. 다만 Shodan에서 찾은 것을 인터넷 사용을 맡길 만큼 신뢰하라고 권하고 싶지는 않음  
    SNI는 일반적인 인터넷 프라이버시 문제인 건 맞지만 DNS의 속성은 아님. 긍정적으로 보면 **ECH**가 IETF를 통과했고, 일반 사용자에게도 천천히 제공될 것임  
    — 작성자
  - ECH는 몇몇 “테스트” 사이트를 제외하면 일반 웹 사용자에게 널리 제공되지 않음  
    작성자 답변의 “you”가 누구를 가리키는지도 명확하지 않음  
    내 경우 원격 DNS는 대량 DNS 데이터를 주기적으로 가져올 때만 씀. HTTP 서버에 접근할 때는 원격 DNS 요청을 하지 않음. 필요한 IP 주소 정보를 이미 가지고 있고, 이 방식이 더 빠르고 안정적임  
    여러 출처에서 얻은 **대량 DNS 데이터**를 로컬 TLS 포워드 프록시의 메모리에 적재해 둠  
    사용자는 모두 다르며, 각자 스스로 생각해야 함

- 캐나다 사용자라면 CIRA가 IPv4, IPv6, DoH, DoT를 통한 **공용 리졸버**를 운영함  
  [https://www.cira.ca/en/canadian-shield/configure/summary-cir...](<https://www.cira.ca/en/canadian-shield/configure/summary-cira-canadian-shield-dns-resolver-addresses/>)
  - 캐나다인이 왜 다른 대안보다 CIRA를 더 신뢰해야 하는지 모르겠음. 그래도 기본 ISP DNS를 쓰는 것보다는 나을 가능성이 큼

- DNScryptProxy는 공용 DNS 서버의 방대한 목록을 유지함. DNSSEC, 필터링, 로깅 지원 여부도 표시함  
  [https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...](<https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-resolvers.md>)

- 이런 사이트가 로컬 네트워크 기준의 기본 **속도 비교 테스트**를 제공하면 좋겠음  
  무작위 조회에 대한 P90 응답 시간과 중앙값 응답 시간을 비교해 볼 수 있으면 좋을 듯함
  - 작성자인데, 이제 추가했음: [https://evilbit.de/dns-resolver-guide2.html#speedtest](<https://evilbit.de/dns-resolver-guide2.html#speedtest>)  
    다만 DoH에서만 동작함
  - 이 저장소를 클론한 뒤 도메인 이름과 리졸버를 원하는 대로 수정하면 찾는 것과 비슷한 결과를 얻을 수 있음  
    [1] - [https://github.com/cleanbrowsing/dnsperftest](<https://github.com/cleanbrowsing/dnsperftest>)
  - 이 용도로 로컬에서 **smokeping** 인스턴스를 돌리고 있음. 여러 DNS 서버와 ISP DNS, 주요 웹사이트 몇 곳에 ping을 보내고, 그 결과에 맞춰 로컬 DNS 서버의 업스트림을 주기적으로 갱신함  
    내 환경에서는 큰 DNS 서버들이 모두 5~6ms 범위지만 항상 그랬던 건 아님. ISP DNS도 평균은 비슷하지만 분산이 심하고 50ms까지 튀는 스파이크가 있음. 가장 빨라야 할 위치인데도 그렇음

- DNS는 프라이버시와 보안에 매우 중요한 주제임. 공용 DNS를 고르기보다 **자체 인프라**를 호스팅하는 편이 낫다고 봄  
  공용 인스턴스가 필요하지 않음. 라우터나 머신에서 ADGUARD, `unbound`, `dnsmasq`, `dnsdist`를 재귀 모드로 돌리면 됨  
  필요에 맞춰 제한과 차단 목록도 설정할 수 있음
  - 그래도 ISP는 모든 질의를 기록할 수 있음