나만의 DNS 리졸버.
아무도 옮길 생각을 하지 않는 로그 하나.

"나만의 DNS 서버"라는 문구 뒤에는 완전히 다른 두 종류의 머신이 숨어 있고, 거의 모든 튜토리얼은 잘못된 쪽을 만듭니다. 무엇이든 설치하기 전에 이것부터 결정하십시오. 프라이버시 도구와 남의 프라이버시 정책을 위한 프록시의 차이가 여기서 갈리기 때문입니다.

포워더 는 여러분의 쿼리를 받아 다른 리졸버 — 보통 Cloudflare, Google, Quad9 또는 여러분의 ISP — 로 넘긴 뒤, 돌아오는 것을 캐시합니다. 단순하고 빠르지만, 여러분의 쿼리 스트림 전체를 단일 제3자에게 넘겨줍니다. "이제 업스트림을 1.1.1.1로 설정하십시오"로 끝나는 가이드는 모두 이런 것을 만든 것입니다.

재귀 리졸버 는 그 일을 직접 합니다. mail.example.com을 찾기 위해 루트 서버에게 .com을 누가 운영하는지 묻고, .com 서버에게 example.com을 누가 운영하는지 물은 다음, example.com 자신의 네임서버에게 레코드를 묻습니다. 서로 다른 서너 곳의 운영자와 나누는 서너 번의 짧은 대화이며, 그 누구도 다른 곳에 대해서는 아무것도 듣지 못합니다. QNAME 최소화를 켜면 한 발 더 나아갑니다: 루트에게는 .com에 대해서만 묻고, .com 서버에게는 example.com에 대해서만 묻습니다. 전체 이름이 드러나는 대상은 정확히 한 당사자뿐입니다 — 그 이름을 호스팅하는 곳이며, 어차피 30밀리초 뒤에는 여러분의 연결을 받게 될 곳입니다.

오른쪽 두 열은 경쟁 관계가 아니라 — 같은 구성의 두 절반입니다. AdGuard Home이 53번 포트를 소유하고, 차단 목록을 적용하며, 암호화된 전송을 종단합니다. Unbound는 그 뒤 루프백에 앉아 실제 해석을 담당합니다. 어느 쪽도 상대의 일을 잘 해내지는 못하며, 이 체인 전체가 소비하는 RAM은 대략 100메가바이트 정도입니다.

이 페이지에서 딱 하나만 가져간다면 이것을 가져가십시오: 공개 DNS 제공업체로 포워딩하는 리졸버는 여러분의 DNS를 프라이빗하게 만든 것이 아닙니다. 로그를 한 홉 옮기고, 유지보수 목록에 서버 하나를 추가했을 뿐입니다. 재귀가 요점의 전부입니다.

Unbound는 NLnet Labs가 만든, 검증하고 재귀하며 캐시하는 리졸버입니다. 어디에나 패키지로 존재하며, 이미 인터넷의 상당 부분이 쓰고 있는 소프트웨어이고, 기본 상태에서 재귀 방식으로 동작합니다 — 이를 포워더로 바꾸려면 오히려 일부러 손을 대야 합니다. 어디서도 목록을 따로 받아오지 않고도 루트 서버의 위치를 알 수 있도록 루트 힌트 패키지와 함께 설치하십시오:

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

dns-root-data 패키지는 루트 힌트를 /usr/share/dns/root.hints에, DNSSEC 루트 신뢰 앵커를 /usr/share/dns/root.key에 설치하고, 일반적인 패키지 채널을 통해 둘 다 계속 최신 상태로 유지합니다. 지루하지만 이것이 이들을 얻는 올바른 방법입니다. cron 작업으로 URL에서 root.hints를 내려받는 방식은 결국 조용히 실패하는 방법입니다.

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

그 줄들 중 네 개가 진짜 일을 하고 있으며, 각각 한 문장씩 설명할 가치가 있습니다.

• 01access-control: 0.0.0.0/0 refuse — 인터넷에 대한 기본 답은 "아니오"입니다. 그 뒤에 오는 모든 것은 여러분이 일부러 적어 넣은 예외입니다. 이 한 줄이 방화벽이 나서기도 전에 2단계의 증폭 시나리오를 막아줍니다.
• 02qname-minimisation: yes — 루트 서버에게는 전체 호스트 이름이 아니라 .com에 대해서만 묻습니다. RFC 9156이며, 현재 Unbound에서는 기본적으로 켜져 있고, 재귀 리졸버가 도표에서 시사하는 것보다 덜 새는 이유입니다. 엄격 모드는 꺼 두십시오: 잘못 설정된 소수의 존이 여전히 이 모드에서 깨지기 때문입니다.
• 03refuse-any: yes — ANY 쿼리는 가능한 가장 작은 질문에 가능한 가장 큰 답을 돌려주는데, 이는 정확히 증폭 공격이 원하는 바입니다. 정당한 용도로는 이것이 전혀 필요하지 않습니다.
• 04serve-expired: yes — 권위 서버에 연결할 수 없을 때, 실패하는 대신 오래된 답을 내어주고 백그라운드에서 갱신합니다. 이 설정 덕분에 저 멀리서 일어난 장애가 집 안의 모두에게 인터넷이 끊긴 것처럼 보이는 일을 막을 수 있습니다.

두 개의 리스너를 눈여겨보십시오. 5335번 포트의 루프백은 다음 단계에서 AdGuard Home이 쓸 것이고, 10.8.0.1은 터널 주소로, 필터링 계층을 건너뛰기로 한다면 VPN상의 클라이언트가 Unbound에 직접 쿼리할 수 있게 해줍니다. 아직 WireGuard를 운영하고 있지 않다면 지금은 두 번째 인터페이스 줄을 빼두십시오 — Unbound는 서버에 존재하지 않는 주소로는 시작되지 않습니다.

시작한 뒤 제대로 동작하는지 증명하십시오:

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

첫 번째 답의 ad 플래그는 Unbound가 루트부터 레코드까지 서명 체인을 확인했고 그것이 유효했다는 뜻입니다. 두 번째 답의 SERVFAIL은 검증이 위변조된 답을 그대로 넘기지 않고 거부했다는 뜻입니다. 두 번째 쿼리가 주소를 반환한다면 검증이 켜져 있지 않은 것이므로 가장 먼저 신뢰 앵커를 확인해야 합니다.

아무도 닿을 수 없는 리졸버는 쓸모가 없고, 누구나 닿을 수 있는 리졸버는 2단계에서 다룬 실패 상태입니다. 좋은 답은 정확히 두 가지이며, 대부분의 사람은 결국 둘 다 씁니다 — 집과 노트북에서는 터널을, 휴대폰과 UDP가 막힌 네트워크에서는 암호화된 DNS를.

옵션 A — WireGuard를 통해. 둘 중 더 나은 쪽이며, 이 가이드가 계속 WireGuard 가이드를 가리키는 이유이기도 합니다. 53번 포트는 인터넷에 계속 보이지 않고, 쿼리 자체가 어떤 형태로도 신뢰할 수 없는 네트워크를 건너는 일이 없으며, 갱신할 인증서도 없습니다. VPS가 이미 여러분의 VPN 출구라면, 각 피어의 설정에 한 줄만 추가하면 됩니다:

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

사람들을 무는 미묘한 함정 하나: Linux에서 wg-quick은 resolvconf나 systemd-resolved를 통해 그 주소를 설정하는데, 둘 다 설치되어 있지 않으면 터널은 멀쩡히 올라오는데도 조용히 아무 일도 하지 않습니다. 터널이 올라온 뒤 resolvectl status로 확인하거나 /etc/resolv.conf를 직접 읽어 보십시오 — 터널은 멀쩡히 동작하는데 예전 리졸버가 여전히 설정되어 있는 상태야말로 이 작업 전체가 막으려던 바로 그 누출입니다.

옵션 B — DNS-over-TLS와 DNS-over-HTTPS. 기기가 항상 터널에 있을 수 없을 때 필요합니다. 둘 다 인증서로 인증되며, 이는 곧 호스트 이름이 필요하다는 뜻입니다: A 레코드를 VPS로 향하게 한 다음, AdGuard Home이 직접 인증서를 들고 있게 하거나 이미 TLS를 종단해 주는 리버스 프록시 뒤에 두십시오. 리스너는 DoT용 853/tcp와 DoH용 443/tcp입니다.

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

DoH 엔드포인트에는 추측할 수 없는 경로를 부여하십시오 — AdGuard Home에서는 이를 /dns-query/<random> 아래에서 제공할 수 있으며, 사람마다 다른 경로를 쓰면 다른 모두의 것은 그대로 둔 채 한 사람씩 접근을 취소할 수 있습니다. 엄밀한 의미의 인증은 아니지만, 공개 리스너가 몇 단계만 더 거친 오픈 리졸버가 되는 것은 막아줍니다.

곰곰이 생각해 볼 것은 라우터 행입니다. DHCP로 리졸버를 나눠주면 설정 화면조차 없는 기기를 포함해 집 안의 모든 기기를 한 번에 커버할 수 있습니다 — 하지만 그러면 라우터에서 VPS까지의 구간은 열린 인터넷을 가로지르는 평문 DNS가 되는데, 이는 애초에 여러분이 막으려던 바로 그것입니다. 라우터 자체에서 터널을 돌리거나, 마지막 구간이 암호화되지 않는다는 점을 받아들이고 재귀만으로도 얻는 이득이 있다고 여기십시오.

알아둘 만한 마지막 설정 하나: DNS-over-HTTPS가 켜진 브라우저는 터널 여부와 상관없이 자신만의 리졸버를 쓰고 시스템 설정을 조용히 무시합니다. Firefox와 Chrome 모두 일부 지역에서는 이를 기본으로 켜서 배포합니다. 브라우저도 여러분의 엔드포인트를 가리키도록 설정하거나, 운영체제를 따르도록 DoH를 꺼두십시오.

프라이빗 리졸버는 실질적인 개선이지, 망토가 아닙니다. 이를 망토처럼 파는 사람이 있다면 무언가를 팔고 있는 것입니다. 위의 모든 것을 마친 뒤에도 여전히 드러나는 것들의 목록은 다음과 같습니다. 남아 있는 노출의 형태를 아는 것이야말로 진짜 방어와 마음의 위안용 담요를 가르는 차이이기 때문입니다.

연결은 여전히 일어납니다. 조회 1밀리초 뒤, 여러분의 기기는 방금 알아낸 주소로 TCP 연결을 엽니다. 여러분의 회선을 지켜보는 누구든 그 주소를 보게 됩니다. 자신만의 IP를 쓰는 사이트라면 그 주소가 곧 그 사이트입니다. 암호화된 DNS는 질문을 없애 줄 뿐, 답까지 없애 주지는 않습니다.

TLS 핸드셰이크는 대개 그 사이트의 이름을 밝힙니다. Server Name Indication은 거의 모든 HTTPS 연결이 시작될 때 평문으로 전송되므로, 수동적 관찰자는 어차피 호스트 이름을 읽어낼 수 있습니다. Encrypted Client Hello가 이를 해결하지만 배포 상황은 고르지 않습니다 — 브라우저와 사이트 양쪽 모두 이를 지원하는 곳에서는 이름이 숨겨지고, 그렇지 않은 곳에서는 숨겨지지 않습니다. 켜져 있다고 지레짐작하지 마십시오.

이제 리졸버 운영자는 여러분이며, 여러분은 단 한 사람입니다. 여러분의 리졸버가 대화하는 모든 권위 서버는 자신의 존에 대해 묻는 단일 IP 주소를 보게 됩니다. 여러 존에 걸쳐, 그 IP는 뚜렷한 패턴을 가지게 되고, 그 패턴은 곧 한 가정입니다. 이것이 첫 장에서 다룬 익명 집합의 대가이며, 이를 무디게 하는 유일한 방법은 그 IP가 어떤 이름으로도 추적되지 않는 것 — 즉 KYC 없이 암호화폐로 결제한 VPS — 이며, 이상적으로는 여러분의 트래픽이 이미 나가고 있는 것과 같은 IP인 것입니다.

제공업체는 언제나처럼 패킷을 볼 수 있습니다. VPS는 누군가의 데이터센터 안, 누군가의 하드웨어 위에서 돌아갑니다. NordBastion은 고객 트래픽을 들여다보지 않으며 투명성 보고서와 워런트 카나리가 요청받았을 때 무슨 일이 일어날지를 설명해 주지만 — 그럼에도 정직한 구조적 사실은 여러분이 임대한 머신은 다른 누군가가 물리적으로 접근할 수 있는 머신이라는 것입니다. 직접 호스팅이 바꾸는 것은 제품 차원의 쿼리 로그도, 분석 파이프라인도, 개정될 수 있는 프라이버시 정책도 없다는 점입니다. 오직 여러분이 설정하고, 여러분이 일부러 고른 관할권에서, RAM에 캐시를 쥐고 있는 프로세스 하나가 있을 뿐입니다.

여러분이 실제로 산 것은, 정확히 말하면: 여러분에 대한 행동 데이터의 가장 풍부하고 가장 값싼 원천 하나가, 그것을 수집하는 것이 비즈니스 모델인 당사자에 의해 더 이상 수집되지 않는다는 것입니다. 좁은 주장이지만, 진짜입니다. 위협 모델이 Tor를 요구하는 상황에서는 이 페이지의 그 무엇도 Tor를 대신하지 못합니다 — 그리고 그럴 때는 아래의 어니언 서비스 가이드가 정직한 다음 읽을거리입니다.