VPN과 함께 쓰는 TLS 기반 DNS: 어느 부분이 보호되는가

TLS 기반 DNS는 클라이언트와 클라이언트가 고른 리졸버 사이의 교환을 암호화하지만, 리졸버는 여전히 이름을 읽는다. 이 문장이 DoT와 VPN을 둘러싼 혼란의 대부분을 정리해 준다. 암호화된 질의가 어느 경로로 가는지는 터널이 정하고, 리졸버는 무엇을 물었는지를 여전히 알게 된다. 어느 쪽도 다른 쪽을 대신하지 않으며, 어느 쪽도 다른 쪽을 불필요하게 만들지 않는다.

네 가지 점검이 지금 갖춘 구성이 실제로 생각하는 그 구성인지 판정한다.

점검 1: 암호화가 덮는 범위

DoT는 DNS 교환을 TLS로 감싸므로, 경로 위의 관찰자는 질의 안의 이름이 아니라 주소와 포트로 향하는 연결을 본다. 리졸버 자신이 복호화해서 응답한다. HTTPS 기반 DNS와 비교해 보라. 둘 다 암호화하지만 서로 다른 전송을 쓰기 때문에, 웹 트래픽을 허용하는 네트워크가 DoT 연결까지 자동으로 허용하지는 않는다.

이 차이는 캡티브 포털이나 필터링하는 중간 장비가 443을 허용하고 853을 막을 때 중요하다. 그곳에서 동작한 도구가 다른 쪽도 동작한다는 증거는 아니다.

점검 2: 질의가 지나는 경로

경로는 클라이언트 정책의 문제다. DoT 리졸버에는 터널 안으로도, 밖으로도, 네트워크에 따라 바뀌는 경로로도 도달할 수 있다. 어느 쪽이 일어나는지는 경로와 클라이언트가 자기 DNS 소켓을 보호하는지에 달려 있다. 모든 트래픽을 붙잡는 터널은 보통 질의도 함께 가져가며, 리졸버 주소가 무엇을 말하든 마찬가지다.

시험에서 제삼자 리졸버 주소가 보인다고 우회를 증명하는 것은 아니고, 암호화가 보인다고 의도한 수신자임이 증명되지도 않는다. 리졸버와 경로를 따로 읽고, 그 짝이 설계한 것인지 판단하라.

점검 3: 내부 이름

내부 이름을 공개하는 조직에는 그 레코드를 보관하는 리졸버가 필요하다. 공용 DoT 서비스는 여러분의 사설 이름 공간을 알지 못하며, 클라이언트를 그쪽으로 돌리면 그 이름들은 반드시 실패한다. 관리되는 기기에서 누군가 암호화 DNS를 켤 때 가장 흔한 실무상의 퇴행이 이것이다.

내부 접미사에는 내부 리졸버를 남기고 정책이 요구하면 그 구간을 암호화하라. 공용 제공자로 대체하는 대신에.

점검 4: 실패할 때의 동작

도달 가능한 리졸버가 없는 엄격한 리졸버 설정은 터널이 올라간 채로 이름 해석 실패를 만든다. 키나 인증서를 건드리는 대신 플랫폼 모드와 문서화된 대체 동작을 보라.

평문 DNS를 조용히 쓰는 대체 동작은 편의가 아니라 정책 결정이다. 실패가 보이게 할지, 더 약한 무엇으로 떨어뜨릴지 정하고 그 답을 적어 두라.

인증서를 믿고 응답을 믿지 말라

서비스에 대해 문서화된 제공자 호스트 이름과 검증 구성을 쓰라. 낯선 리졸버가 응답하게 하려고 TLS 검증을 끄면 검증되지 않은 종단점으로 가는 암호화 채널이 생긴다. 이것은 대체한 평문 질의보다 한 가지 점에서 더 나쁘다. 안전해 보인다는 것이다. DNS over TLS 규격은 그 검증 뒤에 있는 인증 기대를 밝힌다.

인증할 수 없는 리졸버의 응답은 결과가 아니라 주장이다.

이것이 설명하지 않는 것

DoT는 리졸버에게서 이름을 숨기지 않고, 연결의 목적지 주소를 네트워크에서 숨기지 않으며, 질의가 터널을 지났는지도 정하지 않는다. 이들은 세 가지 별개의 질문이고 세 가지 별개의 답이 있다.

리졸버 신원, 전송 경로, 내부 이름 정책을 세 줄로 적어 두라. 다음에 받을 DNS 질문은 그중 하나일 것이다.