DNS 리졸버 로그와 VPN 연결 로그: 각각 무엇을 보관하는가
리졸버는 답하도록 요청받은 이름을 기록하고, VPN은 자체 구현에서 터널 이벤트를 기록한다. 하나의 보존 정책이 다른 하나를 포괄하지는 않는다.
DNS 리졸버 로그와 VPN 연결 로그는 둘 다 네트워크 기록이고, 둘 다 유용하며, 서로 대체할 수 없다. 리졸버는 답하도록 요청받은 이름을 받는다. VPN 종단점은 터널 연결을 처리하고, 그 구현이 기록하기로 선택한 내용을 기록한다. 두 로그는 같은 건물에 있고, 같은 팀이 운영하며, 같은 개인정보 고지의 적용을 받을 수 있지만, 서로 다른 식별자와 서로 다른 보존 기간을 가진 서로 다른 사건을 기술한다. 하나를 다른 하나처럼 읽는 것이 바로 조사가 옆길로 새는 방식이다.
두 개의 로그, 두 개의 사건
리졸버 항목은 이름 지정에 관한 질문에 답한다. 이 클라이언트가 이 시각에 이 이름을 요청했고, 답은 이것이었다. VPN 항목은 연결성에 관한 질문에 답한다. 이 피어가 터널을 수립하거나 잃었고, 이 주소를 할당받았으며, 사라지기 전에 대략 이만큼의 데이터를 전송했다. 둘 다 HTTPS 세션 내부에서 사용자가 무엇을 했는지에 대한 기록이 아니고, 어느 것도 다른 하나를 대신하지 않는다.
이 구분은 약속에 실제적인 결과를 가져온다. VPN 사업자가 터널 활동을 기록하지 않는다는 진술은 그가 제공하는 리졸버에 대해 아무것도 말하지 않으며, 리졸버의 보존 정책은 누가 터널에 접속했는지에 대해 아무것도 말하지 않는다. 모든 주장은 자기 운영자와 자기 시스템에 속한다.
어느 로그를 읽기 전에 먼저 질의의 경로를 따라가라
질의는 경로가 실제로 그 리졸버에 물을 때만 리졸버에 도달한다. 애플리케이션은 운영체제의 리졸버를 쓸 수도, 자체 암호화 DNS 클라이언트를 실행할 수도, 캐시된 답을 읽고 아무것도 보내지 않을 수도 있다. 따라서 아무것도 보여주지 않는 리졸버 로그는 그 이름이 한 번도 쓰이지 않았다는 증거가 아니라, 이 리졸버에 묻지 않았다는 증거다.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager
마지막 명령은 로컬 리졸버 자체의 저널을 읽는데, 이는 상위 서버의 로그와 같지 않다. 질의가 DNS over HTTPS를 통해 사업자에게 나간다면, 로컬 스텁에는 아무것도 보이지 않는데 사업자에게는 완전한 기록이 있을 수 있고, 그 사업자는 다른 정책을 가진 다른 운영자다.
각 기록이 보여줄 수 있는 것과 없는 것
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
둘을 연결하는 것이 실제 작업이며, 연결이 항상 가능한 것은 아니다. 클라이언트 주소를 기록하는 리졸버는 알려진 풀에서 주소를 할당하는 VPN과 비교할 수 있고, 그 비교는 질의된 이름과 터널 사이에 그럴듯한 연결을 만들어 내지만, 그것은 두 기록 사이의 연결일 뿐 사람에 대한 기록은 아니다.
암호화 DNS는 전송을 바꿀 뿐 종단점에서의 가시성을 바꾸지 않는다. 리졸버는 자기가 답하는 질문을 여전히 받는다. RFC 8484가 분명히 밝히는 바이며, 그 리졸버에서의 보존은 프로토콜의 속성이 아니라 정책 결정이다.
분할 DNS와 캐시가 이야기를 흐리는 지점
리졸버가 여러 개인 것은 정상이다. 분할 DNS 설계는 내부 이름을 내부 서버로, 나머지 전부를 공용 서버로 보내므로, 한 번의 조사가 결합하도록 의도된 적 없는 두 로그와 비교하도록 의도된 적 없는 두 보존 설정을 다룰 수 있다. 둘 다에서 질의가 보인다는 것은 설계가 작동한다는 증거이지 유출의 증거가 아니다.
캐시는 반대 방향으로 작용한다. 인기 있는 이름은 몇 시간 동안 캐시에서 답할 수 있어서, 리졸버 기록에는 첫 질의만 남고 그 뒤로는 아무것도 없지만, 사용자의 애플리케이션은 같은 이름을 아무 문제 없이 계속 해석한다. 특정 시점 이후 항목이 없다고 해서 그 시점 이후에 아무도 그 이름을 쓰지 않았다는 뜻은 아니다.
배경 트래픽이 세 번째 왜곡이다. 부팅 시 텔레메트리 이름을 해석하는 휴대전화, 검색 제안 도메인을 해석하는 브라우저, 매시간 접속하는 업데이터는 모두 리졸버 로그에서 정말로 신경 쓰는 이름 옆에 나타난다. 그 로그의 양은 관심이 아니고, 질의를 세는 것은 방문을 세는 것이 아니다. 리졸버 로그는 질문의 기록이고, 질문은 만들기 쉽다.
보존에 관한 질문은 따로 하라
시스템마다 세 가지를 물어라. 누가 수집하는가, 무엇이 수집되는가, 그리고 얼마나 오래 보관되는가. 그다음 누가 그것을 읽을 수 있고 어떤 절차를 따르는지 물어라. DNS over HTTPS에 관한 RFC 8484의 논의는 암호화된 전송이 종단점을 없애지 않는다는 좋은 상기이며, 운영자 자신의 문서만이 그 종단점이 무엇을 보관하는지에 대한 신뢰할 수 있는 진술이다.
개인정보에 관한 주장이 “VPN”에 대해 제기될 때는 받아들이기 전에 구성 요소로 나눠라. 터널 운영자, 터널이 제공하는 리졸버, 그 질의가 도달하는 상위 리졸버, 그리고 기기 위의 애플리케이션이다. 각각 자기 답이 있고, 하나에 대해 정확한 주장이 네 가지를 모두 포괄하는 것처럼 습관적으로 반복된다.
문제 해결에는 같은 분할을 써라. 어느 애플리케이션이 질의를 했고 어느 리졸버가 답했는지 확인한 다음, 그 사건을 실제로 소유한 로그를 보라. 다른 로그에서 추측하면 일 분을 아끼고 오후를 잃는다.