VPN 클라이언트의 DNS 레코드: 소유자, TTL, 정리는 별개의 문제

노트북이 연결되어 VPN 주소를 받지만, 다른 시스템이 조회하는 이름은 여전히 어제의 사무실 주소를 가리킵니다. 실패한 것은 없이, 주소는 할당되었고, 레코드는 갱신되지 않았으며, 캐시는 아직 오래된 응답을 들고 있습니다. 이는 소유자가 각각 다른 세 개의 객체이며, 그중 VPN에 속하는 것은 하나뿐입니다. 게시를 계획한다는 것은 이름을 누가 쓰는지, 어떤 인터페이스가 참여하는지, 오래된 데이터가 언제 사라지는지를 정하는 일입니다.

증상: 잘못된 주소를 따라가는 이름

장치에서는 터널이 올라가 있고 VPN 주소가 응답합니다. 동료의 워크스테이션에서는 같은 호스트 이름이 장치가 더 이상 보유하지 않은 사설 주소로 확인되므로, 이동한 머신을 향한 연결이 시간 초과됩니다. 레코드는 권위가 있으면서 틀렸고, 이는 없는 것보다 나쁩니다. 모두가 그것을 믿고 아무도 연결할 수 없습니다.

반대의 경우는 더 조용하며, 레코드가 사라지고 이름이 아예 확인되지 않습니다. 두 결과 모두 같은 설계 공백에서 나오며, TTL을 낮춰서 고쳐지는 것은 없습니다. 캐시 수명을 줄이면 잘못된 응답이 얼마나 오래 살아남는지가 바뀔 뿐, 기록되는지 여부는 바뀌지 않습니다.

어떤 객체가 오래되었는지 묻는 것부터 시작하십시오. VPN이 할당한 주소, 영역의 레코드, 리졸버 캐시의 응답은 수명과 소유자가 다릅니다.

세 객체, 세 소유자

VPN은 주소 할당을 소유하며, DHCP 교환이 노트북에 도달하지 않아도 내부 풀에서 주소를 내줄 수 있습니다. DNS 영역은 레코드를 소유하며, 그 보안 모델이 누가 만들거나 수정할 수 있는지를 정합니다. 리졸버 캐시는 읽는 사람이 지금 사용하는 사본을 소유하며, 장치가 하는 어떤 일도 거기에 닿을 수 없습니다.

하나의 구성 요소가 셋을 모두 한다고 가정하는 지점에서 설계가 무너집니다. 관리되는 범위에서 온 것처럼 보이는 주소가 DHCP 서버가 등록을 수행했음을 증명하지 않고, 등록이 성공했다고 해서 읽는 사람이 캐시를 갱신했음이 증명되지 않습니다.

누가 레코드를 갱신할 수 있는가

Active Directory와 통합되고 보안 동적 업데이트를 사용하는 영역에서는 권한이 레코드 자체에 있습니다. DHCP 서비스 계정이 만든 레코드는 노트북의 컴퓨터 계정으로 쓸 수 없을 수 있고, 나중에 소유 모델을 바꾸는 것은 전환이지 스위치가 아닙니다. 그래서 소유권 충돌은 모든 클라이언트 측 설정을 넘어 살아남습니다.

Microsoft의 동적 업데이트 지침은 도메인에 가입한 하이브리드 엔드포인트에 대해 클라이언트 측 등록을 권장합니다. 그것을 받아들이는 것은 기존 레코드를 의도적으로 이전하는 일이며, VPN 어댑터의 확인란을 표시하고 옛 소유자가 물러나기를 바라는 것이 아닙니다.

DHCP 서비스가 다른 장치 클래스를 위해 등록해야 한다면, 그 역할에 지원되는 자격 증명과 권한 모델을 부여하십시오. 정방향과 역방향 레코드는 흔히 서로 다른 구성 요소가 유지하며 둘 중 하나를 잊기 때문에 같은 계획에 두십시오.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

첫 번째 명령은 장치가 자신이 보유한다고 생각하는 주소와 연결이 그것을 등록하도록 설정되었는지를 보여 줍니다. 두 번째와 세 번째는 클라이언트가 확인하는 것과 영역이 실제로 저장하는 것을 비교하며, 캐시 문제와 권위 측 문제를 구분합니다.

세 개의 시계, 하나가 아님

게시와 갱신은 권한 있는 갱신자가 주소가 바뀌었다고 알리는 첫 번째 시계입니다. 캐시 TTL은 두 번째로, 리졸버가 받은 응답을 얼마나 보관할 수 있는지입니다. 권위 측 정리는 세 번째로, 오래된 레코드가 등록 과정이나 노화와 스캐빈징으로 제거되는 방식입니다.

이 시계들은 독립적이며, 그것을 혼동하면 작동하지 않는 수정이 나옵니다. 하나의 변경은 나머지 둘에 보이지 않습니다. 짧은 TTL은 캐시된 응답의 수명을 줄일 뿐 갱신 권한을 주지 않습니다. 스캐빈징은 갱신되지 않은 레코드를 제거하며, 올바른 소유자가 쓰지 않은 레코드를 고칠 수는 없습니다.

TTL은 읽는 사람이 변경을 얼마나 빨리 봐야 하는지로 정하고, 스캐빈징은 버려진 장치가 이름을 얼마나 유지해야 하는지로 정하십시오. 두 숫자 중 어느 것도 누가 레코드를 쓸 수 있는지를 정하지 않으며, 어떤 TTL 값도 주소 할당을 DNS 관리 권한으로 바꾸지 않습니다.

이동하는 장치를 위한 게시 계획

어떤 인터페이스가 등록에 참여하는지 정하십시오. 가정용 Wi-Fi 주소, VPN 주소, 오래된 사무실 주소는 서로 다른 대상에게 쓰이며, 모두 게시하면 유용성이 다른 여러 응답을 가진 이름이 됩니다. 의도한 읽는 사람이 실제로 닿을 수 있는 인터페이스만 등록하십시오.

안정적인 컴퓨터 이름을 정체성으로 유지하고 주소는 그 속성으로 다루십시오. 장치에 필요한 도메인 검색 레코드를 보존하고, 권한 변경으로 해결될 중복 레코드 문제를 풀기 위해 등록을 전면 비활성화하지 마십시오.

할당자, 갱신자, 정리 소유자를 하나의 레코드에 적고 의도한 읽는 사람을 명시하십시오. 이름이 다시 잘못된 주소를 가리키면, 그 레코드가 조사를 처음부터 다시 시작하는 대신 셋 중 무엇을 먼저 살펴야 하는지 알려 줍니다.