systemd-resolved에서는 질의 이름과 일치하는 링크별 routing domain 가운데 label 수가 가장 많은 항목이 우선합니다. 같은 최상위 domain이 여러 링크에 있으면 해당 링크의 DNS 서버들로 질의가 병렬 전송될 수 있습니다.
resolvectl status는 현재 전역·링크별 DNS 설정을 보여 주고 resolvectl monitor는 로컬 프로그램의 질의와 응답을 보여 줍니다. monitor 출력만으로 상위 DNS 서버로 실제 전송된 패킷이나 앱별 설정 소유자를 확정할 수는 없습니다.
회사 도메인 질의는 이름과 링크를 함께 봅니다
VPN에 연결한 뒤 db.corp.example만 예상하지 못한 응답을 받는다면 먼저 어떤 링크에 어떤 DNS 서버와 routing domain이 붙었는지 확인합니다. systemd-resolved의 라우팅 규칙은 이름이 route-only(~domain) 또는 search domain과 같거나 그 하위 이름에 해당하는지 비교합니다. 일치하는 항목이 여러 개면 label 수가 가장 많은, 즉 더 구체적인 routing domain을 고릅니다. 선택된 domain이 같은 링크가 복수라면 그 링크들의 DNS 서버에 동시에 질의할 수 있습니다. 따라서 ‘VPN DNS가 등록되어 있다’는 사실만으로 회사 이름이 VPN으로 간다고 결론 내릴 수 없습니다.
| 링크 | DNS 서버 예시 | routing domain | db.corp.example과의 관계 |
|---|---|---|---|
| 기본 링크 | 192.0.2.53 | ~corp.example | suffix 일치 |
| VPN 링크 | 198.51.100.53 | ~db.corp.example | 더 많은 label로 일치 |
| 게스트 링크 | 203.0.113.53 | ~example | 일치하지만 덜 구체적 |
예시 질의는 VPN의 더 긴 domain을 선택합니다
예시의 db.corp.example은 세 label로 된 ~db.corp.example뿐 아니라 ~corp.example, ~example에도 일치합니다. 이 가운데 가장 많은 label을 가진 ~db.corp.example이 최선의 일치이므로 VPN 링크의 DNS 서버가 선택 대상입니다. 반면 hr.corp.example에는 더 구체적인 domain이 맞지 않아 기본 링크의 ~corp.example이 선택됩니다. 비교할 때는 문자열 끝부분이 아니라 전체 label 경계를 봅니다.
설정 관찰과 실제 상위 패킷은 다른 증거입니다
- 먼저 해당 호스트가 systemd-resolved를 사용하고 있는지, 애플리케이션이 NSS·D-Bus·로컬 stub 중 어떤 경로로 질의하는지 확인합니다.
resolvectl status에서 링크 이름, DNS 서버, Domains, DefaultRoute 표시를 기록합니다. status는 현재 설정을 보여 줄 뿐, 설정 파일을 누가 관리하는지는 알려 주지 않습니다.- 완전한 이름을 사용해
resolvectl query db.corp.example를 수행하고 응답 주소·프로토콜 및 링크 관련 표시를 비교합니다. 짧은 이름은 search domain 보정이 개입할 수 있습니다. - 필요하면
resolvectl monitor로 로컬 요청·응답을 관찰합니다. 캐시에서 답했거나 DNSSEC 확인에 여러 거래가 쓰일 수 있어 monitor의 한 줄이 상위 서버에 보낸 패킷 하나와 일치하지 않을 수 있습니다. - 이 가상 상태와 실제 상태가 다르면 VPN 클라이언트나 NetworkManager 등 설정 소유자, 링크가 올라온 시점, 실제 resolver 경로를 확인합니다. 승인 없는 설정 변경은 진단에 포함하지 않습니다.
어떤 routing domain과도 일치하지 않는 이름은 default route 링크의 DNS 서버 및 전역 서버 쪽으로 보내질 수 있습니다. ~.은 모든 DNS 이름과 일치하므로 더 구체적인 domain이 없는 질의를 넓게 받습니다. 같은 ~.이 여러 링크에 있거나 global DNS가 함께 지정되면 결과를 한 인터페이스로 단정하지 않습니다. 로컬 합성 응답, /etc/hosts, 캐시 또는 mDNS가 답한 경우에도 상위 DNS 패킷이 보이지 않을 수 있습니다.
DNS 목록에 서버가 보여도 선택 증거는 아닙니다
첫 번째 흔한 오해는 VPN DNS 서버가 status에 있으니 모든 회사 이름이 그 서버로 간다고 생각하는 것입니다. 라우팅 domain이 질의 이름과 맞아야 합니다. 두 번째는 monitor에 응답이 찍혔으니 원격 DNS 서버가 답했다고 단정하는 것입니다. 공식 설명상 monitor는 로컬 클라이언트 요청·응답을 추적하며 캐시 응답을 포함할 수 있고 상위 서버 요청과 곧바로 연결되지 않습니다. 세 번째는 설정을 직접 resolvectl로 바꾸는 것입니다. 일시 설정을 만든 구성 주체와 충돌하거나 인터페이스 재연결 뒤 사라질 수 있으므로 먼저 관리자를 식별해야 합니다.
도메인을 긴 순서로 대조한 뒤 관찰 한계를 적습니다
실제 점검에서는 질의 이름을 오른쪽 label 경계에서 나누고 일치하는 routing domain을 가장 구체적인 것부터 적습니다. 그 다음 해당 domain을 가진 모든 링크와 DNS 서버를 연결합니다. 마지막에 status, query, monitor가 각각 어떤 근거를 제공하는지 구분해 기록하세요. 예를 들어 status는 설정 증거, query는 resolver를 통해 얻은 결과, monitor는 로컬 요청 흐름에 대한 관찰입니다. 이 세 자료를 상위 네트워크 캡처와 같은 증거로 취급하지 않아야 원인을 과장하지 않습니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 상태에서 ~corp.example은 링크 A, ~db.corp.example은 링크 B에 있습니다. db.corp.example을 질의할 때 어떤 routing domain이 더 구체적으로 일치하나요? resolvectl monitor가 원격 DNS 패킷 전송을 직접 증명하나요?
정답과 해설 확인
~db.corp.example이 더 구체적으로 일치해 링크 B의 DNS 서버가 선택 대상입니다. monitor는 로컬 클라이언트 질의와 응답을 보여 주지만, 원격 DNS 패킷 전송을 직접 증명하지는 않습니다.두 route-only domain 모두 이름의 suffix와 일치하지만 db.corp.example이 corp.example보다 label이 하나 더 많습니다. systemd-resolved는 label이 가장 많은 best match를 고릅니다. monitor는 로컬 resolver의 요청 흐름이며 캐시가 응답할 수 있어 상위 서버 요청과 일대일 대응하지 않습니다.