iPhone의 WireGuard DNS: 도메인은 검색 접미사일 뿐

리졸버 주소와 회사 도메인을 한 줄에 적으면 그 도메인의 이름만 터널 리졸버를 쓸 것이라고 기대합니다. Apple 클라이언트에서는 이제 모든 이름이 그곳으로 가고, 도메인의 짧은 이름도 확인됩니다. 이 줄은 두 가지 별개의 일을 하며, 그중 하나만 터널이 어떤 쿼리를 처리하는지에 관한 것입니다. 다른 하나는 입력 편의이며, 희망적인 읽기로 정책까지 승격되었습니다.

DNS 줄은 무엇으로 파싱되는가

클라이언트는 항목을 목록으로 읽고 각 항목을 모양에 따라 분류합니다. 주소처럼 보이는 것은 DNS 서버가 되고, 도메인처럼 보이는 것은 검색 접미사가 됩니다. 둘 다 터널 설정에 들어가지만 서로 다른 필드에 들어갑니다. 프라이빗 리졸버와 내부 도메인 하나를 운반하는 터널의 예시 줄은 이렇습니다.

DNS = 10.24.8.53, lab.internal.example

주소는 리졸버를 제공합니다. 도메인은 접미사를 제공하며, 클라이언트가 짧은 이름을 입력하면 시스템이 묻기 전에 나머지를 붙입니다. 둘 중 어느 것도 리졸버를 그 도메인으로 한정한다고 말하지 않으며, 사람들이 기대하지만 얻지 못하는 부분이 바로 그것입니다. 플랫폼에서 그 제한을 표현할 수 있는 필드는 하나뿐이며, 그것은 이 필드가 아닙니다.

Apple의 두 필드, 두 가지 다른 역할

Apple은 DNS 설정 객체에서 그 구분을 드러냅니다. 검색 도메인 목록은 단일 레이블 호스트 이름을 한정하는 데 쓰이는 목록으로 문서화되어 있으며, 호스트 이름만 입력하면 시스템이 각 접미사를 차례로 붙일 수 있습니다. 이것은 완성 규칙이며 라우팅 규칙이 아닙니다. 그 목록의 어떤 것도 어느 서버에 물을지 결정하지 않습니다.

일치 도메인 목록은 다른 속성입니다. 어떤 네임스페이스가 이 DNS 설정 집합을 쓰는지 결정하며, 빈 항목은 특정 접미사가 아니라 기본 도메인을 뜻합니다. 패킷 터널 설정 생성기 Apple 클라이언트에서는 그 모델을 따릅니다. 파싱된 검색 접미사를 검색 목록에 넣고, 서버가 있으면 일치 목록을 빈 문자열로 설정합니다. 결과는 시스템이 보내는 모든 것에 응답하는 터널 리졸버와 짧은 이름을 돕는 접미사입니다.

따라서 그 줄의 도메인은 네임스페이스 선택자가 아닙니다. 하나 더 추가해도 터널이 쓰는 쿼리가 좁아지지 않고, 제거해도 넓어지지 않습니다. 바뀌는 것은 짧은 이름이 몇 개 완성되는가뿐입니다.

왜 모든 이름이 여전히 터널 리졸버에 도달하는가

일치 항목이 비어 있으면 터널은 회사 도메인뿐 아니라 일반 이름의 후보 리졸버가 됩니다. 전체 터널 구성에서는 모든 트래픽이 어차피 터널 안에 있으므로 보통 거의 문제가 되지 않습니다. 분할 터널에서는 매우 중요합니다. 공용 이름이 이제 프라이빗 영역만 가진 리졸버로 확인될 수 있으며, 실패는 고장 난 VPN처럼 보이지만 실제로는 네임스페이스의 일부에만 응답하는 리졸버입니다. 터널은 정상이고 쿼리는 나가며 응답은 비어서 돌아옵니다.

두 가지 수정이 가능하며 서로 다른 결정입니다. 터널 리졸버를 공용 이름을 승인된 경로로 전달하는 완전한 리졸버로 만들거나, 도메인 목록이 아니라 클라이언트 구성을 바꿔 공용 이름을 그곳으로 보내는 것을 멈추십시오. 첫 번째는 모든 쿼리를 터널에 유지하고 상류를 신뢰합니다. 두 번째는 일부 쿼리를 로컬에 유지하고 터널이 꺼져 있는 동안 프라이빗 이름 확인이 중단될 수 있음을 받아들입니다.

분할 DNS에 실제로 필요한 것

네임스페이스로 범위가 정해진 리졸버 정책에는 그것을 표현할 수 있는 클라이언트가 필요합니다: Apple 플랫폼에서 도메인을 일치시키거나, 사용하는 제품의 동등한 설정을 사용하십시오. 서버와 접미사만 받는 구성 필드는 어떻게 구두점을 찍어도 그것을 표현할 수 없습니다. 프로필은 연결 시점의 힌트가 아니라 관리되는 구성을 설명하므로 정책을 담을 수 있습니다. 도메인, 서버, 그리고 그 도메인에 접근할 수 없을 때 무슨 일이 일어나야 하는지를 지정할 수 있습니다. 이것이 설정과 계약의 차이입니다.

관리되는 Apple 기기에서는 보통 도메인별 DNS 설정을 담은 구성 프로필을 통해 제공됩니다. 이것은 WireGuard 구성 파일과 다른 메커니즘이며, 둘은 클라이언트가 프로필을 존중할 때만 공존할 수 있습니다. 두 제품이 똑같이 동작한다고 가정하기 전에 클라이언트가 그 필드를 실제로 무엇이라고 부르는지 확인하십시오. Mac의 wg-quick 스크립트와 iPhone의 WireGuard 앱은 비슷한 줄을 읽고 서로 다른 계층을 통해 설치합니다.

설치된 설정을 읽으십시오, 구성 파일이 아니라

Mac에서는 시스템이 최종적으로 무엇을 갖게 되었는지 검사할 수 있으며, 이는 작성한 파일을 다시 읽는 것보다 유익합니다. 리졸버 목록은 어떤 서버가 어떤 도메인에 구성되었는지 보여 주고, 범위가 지정된 쿼리는 어느 쪽이 이겼는지 보여 줍니다. 줄을 망가뜨리는 클라이언트는 그것을 작성한 파일이 아니라 여기에서 보여 줍니다. iOS에는 동등한 명령줄이 없으므로 그곳의 증거는 결과, 즉 터널을 통해 확인되는 프라이빗 이름과, 그 응답이 어느 리졸버가 답했는지 드러내는 공용 이름입니다.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

이 두 명령은 현재 리졸버 구성과 활성 서비스의 DNS 서버를 출력합니다. 터널 리졸버가 도메인 제한 없는 기본 리졸버로 나타나면, 구성은 클라이언트가 요청한 것을 정확히 수행하는 것입니다. 메커니즘을 바꿔 고치십시오, 두 번째 접미사를 추가하고 동작이 바뀌기를 바라는 것이 아니라.