VPN은 DNS를 암호화할까, 아니면 다음 홉만 암호화할까?

VPN 서버에서 암호화 DNS를 켜는 일은 흔히 누수를 막는 것으로 설명되지만, 그 설명은 어느 연결이 바뀌었는지를 감춥니다. 클라이언트에서 리졸버로 가는 홉과 리졸버에서 상류로 가는 홉은 소유자가 다른 별개의 연결입니다. 둘 중 하나를 암호화해도 다른 하나는 전혀 바뀌지 않습니다.

설정 파일을 건드리기 전에 각 단계에서 누가 쿼리를 받는지 적어 두세요.

두 가지 구성은 설정 화면에서 똑같아 보인다

첫 번째 구성에서는 기기가 직접 DNS over TLS를 실행하고, 터널은 그 연결을 선택한 리졸버까지 실어 나를 뿐입니다. TLS 세션은 리졸버에서 끝나므로 리졸버는 쿼리를 보지만 VPN 출구는 읽을 수 없는 암호문을 봅니다. 두 번째 구성에서는 기기가 일반 DNS를 터널을 통해 VPN 호스트의 포워더로 보내고, 그 포워더가 상류 리졸버로 자체 암호화 연결을 엽니다. 기능 목록에서는 둘 다 "VPN을 쓴 암호화 DNS"처럼 보이지만, 읽을 수 있는 쿼리를 서로 다른 건물에 둡니다.

차이는 철학적이 아니라 측정 가능합니다. 클라이언트에서 TLS 세션을 찾든 서버에서 찾든, 실제로 어느 구성인지 알게 됩니다.

바꾸기 전에 리졸버 사슬을 지도로 그려라

경로 위의 리졸버를 세고 각각의 역할을 이름 붙이세요. 전달 구성 요소는 요청을 다른 리졸버에 넘기고, 재귀 리졸버는 답을 찾는 일을 하며 권한 서버와 직접 대화할 수 있습니다. 이 역할들이 따로 정의된 것은 바로 이 때문이며, RFC 9076 리졸버 정의 — 상류 목적지가 하나만 존재한다고 가정하기 전에 읽어 볼 가치가 있습니다. 자체 재귀 리졸버를 돌리는 호스트에는 암호화할 단일 "상류"가 없으며, 이는 계획 전체를 무효로 만듭니다.

다음으로 클라이언트가 어떤 구성 요소를 쓰도록 설정되어 있는지 물으세요. VPN 프로필이 밀어 넣는 DNS 주소는 쿼리가 어디로 가는지를 알려 줄 뿐, 어떤 프로세스가 답하는지는 알려 주지 않습니다.

실패 동작도 기록해 두세요. 암호화된 상류에 도달할 수 없게 되면 포워더는 닫힌 상태로 실패하는지, 평문으로 되돌아가는지, 아니면 다른 리졸버로 되돌아가는지. 그 결정은 기록에 남아야 합니다. 터널이 가장 건강하지 않은 순간에 개인정보 보호 보장이 바뀌기 때문입니다.

어느 홉이 암호화되었는지 확인하라

클라이언트에서 시작해 853번 포트로 가는 TLS 세션이 있는지 확인하세요. 53번 포트로 올바르게 해석되는 쿼리는 암호화에 대해 아무것도 증명하지 않습니다.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

그다음 VPN 호스트로 옮겨 포워더가 연 아웃바운드 암호화 연결을 찾으세요. 소켓 표를 보면 상류 TLS 세션이 있는지, 어떤 프로세스가 그것을 소유하는지 알 수 있습니다:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

클라이언트에 TLS 세션이 있고 서버에 없다면 첫 번째 구성이며, 서버는 IP 계층에서 전달하는 쿼리를 읽을 수 없습니다. 서버에 TLS 세션이 있고 클라이언트가 터널 안에서 평범한 53번 포트 트래픽을 보인다면 두 번째 구성입니다. 앞으로 가는 홉은 보호되지만, 포워더는 기기가 묻는 모든 이름을 여전히 읽습니다. 그 두 번째 결과는 실패가 아니지만, 그것을 종단 간 암호화라고 부르는 것은 틀렸습니다.

소유자와 실패 동작을 기록하라

소유권이 무엇을 약속할 수 있는지를 결정합니다. 기기 소유자는 클라이언트 측 암호화 연결을 통제하고, VPN 관리자는 자기 포워더가 만드는 다음 연결을 통제합니다. 둘 다 운영하지 않는 사람은 경로를 설명할 수만 있습니다.

무엇이든 켜기 전에 내부 이름 체계를 확인하세요. 조직의 이름을 공개 리졸버로 보내는 것은 동등한 설계가 아니며, 네트워크 안에만 존재하는 split-horizon 영역은 상류에서 아예 해석되지 않습니다. 변경 후 내부 이름 하나와 공개 이름 하나를 시험하고, 그 결과를 설정 변경과 함께 보관하세요. 암호화 경로가 내부 호스트의 해석을 깨뜨린다면, 해결책은 더 넓은 터널이 아니라 범위가 한정된 리졸버 규칙입니다.

마지막으로 홉마다 문장 하나를 쓰세요. 어떤 구성 요소가 쿼리를 받았는지, 그 홉이 암호화되었는지, 누가 이름을 읽을 수 있는지. VPN 호스트에 대한 문장이 여전히 쿼리를 읽을 수 있다고 말한다면 문서도 그렇게 말해야 합니다. 그렇지 않다고 주장하는 도표는 명령을 한 번도 실행해 보지 않은 사람에게 신뢰를 얻기 때문입니다.