공용 DNS 리졸버 선택 가이드

이런 목록이나 새 서비스 발표를 볼 때마다 크게 감흥이 없고, 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/
몇 년째 이걸 쓰고 있고 공용 핫스팟에서 문제를 겪은 적이 없음

주소창에 그냥 IP 주소를 넣으면 됨. 보통은 80번 포트 트래픽을 전부 가로채고 있음

이런 건 운영체제가 캡티브 포털 지원의 일부로 처리해야 함. 운영체제 제작사에 연락해서 버그를 등록하는 게 좋겠음

로컬에서 Unbound를 DoH 서버로 사용함. Alpine Linux의 Unbound 패키지는 내장 DoH 리스너에 필요한 libnghttp2와 함께 컴파일되어 있고, 이 정도면 ECH를 켜기에 충분함
매시간 cron으로 자주 쓰는 모든 도메인을 미리 캐시함. ISP가 내 DNS 요청을 건드리지는 않을 것이고, 그 직원들이 나보다 더 이상한 사람들임. 휴대폰으로 웹을 보기 시작한다면 직접 공용 DoH 서버를 만들 것임. 몇 분이면 되고, 이상한 문제를 디버깅할 때 내 질의 로그도 얻을 수 있음
[1] - 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 포워드 프록시의 메모리에 적재해 둠
사용자는 모두 다르며, 각자 스스로 생각해야 함

이 용도로 로컬에서 smokeping 인스턴스를 돌리고 있음. 여러 DNS 서버와 ISP DNS, 주요 웹사이트 몇 곳에 ping을 보내고, 그 결과에 맞춰 로컬 DNS 서버의 업스트림을 주기적으로 갱신함
내 환경에서는 큰 DNS 서버들이 모두 5~6ms 범위지만 항상 그랬던 건 아님. ISP DNS도 평균은 비슷하지만 분산이 심하고 50ms까지 튀는 스파이크가 있음. 가장 빨라야 할 위치인데도 그렇음

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