하나의 어댑터에 있는 두 DNS 서버는 네임스페이스를 나누지 않는다

하나의 어댑터에 두 리졸버를 나열하는 것은 한 도메인을 한 서버로, 다른 도메인을 다른 서버로 보내는 방법처럼 보이지만, 리졸버 목록의 어떤 것도 그렇게 동작하지 않습니다. Windows는 이름으로 확인하며, 어느 서버에 물을지에 대한 결정은 정렬된 주소 목록이 아니라 정책 개체에서 나옵니다. 대체해야 할 사고 모델은 대기열입니다. 도메인 A를 위한 첫 번째 서버니 도메인 B를 위한 두 번째 서버니 하는 것은 없습니다. 네임스페이스마다 서버를 명시적으로 지정하는 규칙 집합이 있고, 그 규칙이 존재하면 어댑터 목록은 더 이상 흥미롭지 않습니다.

신화: 두 주소가 두 도메인을 나눈다

이 믿음이 남는 이유는 한 서버가 모든 것에 응답하고 두 번째가 단순한 대체일 때 우연히 동작하기 때문입니다. 클라이언트가 첫 번째 서버에 질의하고, 그 서버가 전달하거나 재귀 조회하며, 응답이 도착하지만, 어느 리졸버가 실제로 영역을 보유했는지는 아무도 알아채지 못합니다. 두 네임스페이스가 서로 전달 없이 분리된 사설 영역에 존재하는 순간 환상은 깨집니다. 그때 첫 번째 서버는 이름이 존재하지 않는다고 권위 있게 응답하기 때문입니다. 첫 번째 서버의 부정 응답은 대체를 작동시키지 않습니다. 클라이언트가 실패가 아니라 확정적인 응답을 받았기 때문입니다.

정렬된 목록에는 도메인 개념이 없으므로 의도를 표현할 수 없습니다. 목록이 실제로 제어하는 것은 어느 서버를 먼저 묻고 어느 것을 두 번째로 시도하는지이며, 두 답변 모두 모든 이름에 동일하게 적용됩니다.

Windows가 선택에 실제로 사용하는 것

이름 확인 정책 테이블은 이름을 구성된 네임스페이스와 일치시키고 그 일치에 대한 서버와 옵션을 선택합니다. 규칙은 로컬에서 구성하거나 그룹 정책으로 배포하거나 VPN 프로필로 제공할 수 있으며, 적용되는 정책은 단일 목록이 아니라 조합입니다. 그래서 첫 진단은 항상 적용 상태입니다. 로컬에서 만든 규칙이 관리 정책에 지면 구성이 암시하는 것과 전혀 다르게 동작하는 실험실이 됩니다. 규칙은 구체성으로도 일치하므로 넓은 네임스페이스 항목이 좁은 항목을 구성된 항목 목록에서는 보이지 않는 방식으로 가릴 수 있습니다. 적용 순서를 읽는 것만이 어느 규칙이 이기는지 확인하는 유일한 방법입니다.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

첫 번째 명령은 머신에 구성된 것을 나열하고, 두 번째는 클라이언트가 실제로 적용할 것을 다른 곳에서 온 항목까지 포함해 보여 줍니다. 적용 출력에 관리되는 네임스페이스가 있으면 변경을 요청할 올바른 곳은 그 정책의 소유자이지 로컬 규칙 목록이 아닙니다. 두 명령 모두 상태를 읽기만 하므로 누군가 변경에 동의하기 전에 실행해도 손해가 없습니다.

네임스페이스마다 규칙 하나, 개체를 보관하십시오

적용 상태를 이해한 뒤 네임스페이스마다 규칙 하나를 만들고 각 명령이 반환하는 개체를 보관하십시오. 표시 이름은 사람을 위한 레이블이며, 반환된 개체의 고유 식별자가 나중에 신뢰할 수 있는 삭제 대상입니다. 두 식별자를 네임스페이스와 리졸버를 기록하는 같은 변경 노트에 적으십시오. 만든 세션이 정리하는 세션과 같지 않기 때문입니다.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

앞의 점은 접미사 일치를 뜻하므로 규칙은 app.svc.internal.example와 그 아래의 모든 것을 포함합니다. 여기 있는 두 주소는 이 실험실 자체의 라우팅 계획에 속하며, 규칙은 영역을 만들지 않고, 경로를 설치하지 않으며, 결국 연결하는 애플리케이션을 허가하지도 않습니다. 그리고 Add-DnsClientNrptRule 참조에는 어떤 매개 변수가 무엇을 하는지 정확히 문서화되어 있습니다.

이 명령들이 하지 않는 일에 주목하십시오: 머신 전체에 적용되며 VPN 세션으로 범위가 제한되지 않습니다. 또한 창을 닫아도 유지됩니다. 이것을 잊는 실험실은 터널이 사라진 뒤 정책을 남깁니다.

클라이언트가 서버를 선택했음을 증명하십시오

특정 서버에 이름을 아는지 묻는 것은 그 서버가 응답할 수 있음을 증명할 뿐, 클라이언트가 그 서버를 선택했다는 주장과 같지 않습니다. 중요한 테스트는 일반 클라이언트 경로로 실제 이름을 확인한 뒤 어느 리졸버가 처리했는지 확인하는 것이며, 이상적으로는 경로를 제공하는 터널이 켜져 있을 때 수행합니다. 터널이 내려가 있으면 올바르게 범위가 지정된 규칙도 도달할 수 없는 서버를 가리키며, 이는 정책이 아니라 라우팅 문제입니다. 나중에 둘을 구분할 수 있도록 두 상태를 모두 테스트하십시오.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

규칙이 존재하기 전 기간의 캐시된 응답과 자체 암호화 DNS로 시스템 리졸버를 완전히 우회하는 애플리케이션을 주시하십시오. 검색 접미사는 또 다른 별개 기능입니다. 규칙은 전체 이름에 대해 리졸버를 선택할 수 있지만, Windows에 맨 호스트 이름을 그 네임스페이스로 확장하도록 가르치지는 않습니다.

만든 것만 정확히 제거하십시오

정리는 실험실이 교훈적인 이야기가 되는 지점입니다. 머신의 모든 규칙을 삭제하는 것은 빠르지만 다른 누군가가 의존하는 정책을 제거하므로, 규칙을 만들 때 기록한 식별자를 사용하고, 이후 적용 상태를 다시 읽어 머신이 시작한 곳으로 돌아왔는지 확인하십시오. 만든 세션이 사라졌다면 변경 노트가 식별자가 존재하는 유일한 곳입니다. 그래서 첫 명령을 실행하기 전에 적어 두는 것이지, 후가 아닙니다.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

실험실이 아니라 배포라면 수명 문제가 규칙만큼 중요합니다. VPN 프로필은 네임스페이스 규칙을 실을 수 있고, 연결 후에도 유지할지 선택할 수 있습니다. 리졸버에 도달할 수 없을 때 유지되는 규칙은 클라이언트가 죽은 서버를 선호하게 만들고, 연결 범위 규칙은 터널과 함께 사라집니다. 이 동작 중 서비스에 필요한 것이 무엇인지 결정하고, 규칙 소유자를 표시하고, 권한 분할을 누군가의 실험실 기억이 아니라 프로필 옆에 문서화해 두십시오.