VPN이 DNS를 고친 걸까요, 아니면 캐시된 응답을 재사용한 걸까요?

터널이 올라온 뒤 몇 초 만에 페이지를 여는 것은 티켓이 보통 그렇게 말하지만 DNS가 이제 작동한다는 증거가 아닙니다. 그 관찰에서 조회가 필요했던 것은 아무것도 없었는데, 이름은 변경 전에 이미 확인되었고 터널이 건드리지 않은 캐시에서 재사용되었을 수 있습니다. 두 가지 다른 테스트가 같은 화면을 만듭니다.

변경에 공을 돌리기 전에 각 테스트가 실제로 무엇을 시험했는지 비교하세요.

페이지 로드는 조회가 아닙니다

애플리케이션과 리졸버 사이의 모든 계층은 수명 동안 응답을 기억할 수 있습니다. 운영체제는 하나를 보관하고, 브라우저는 자체 캐시를 보관하며, 오래 지속되는 연결을 가진 애플리케이션은 세션 중에 더 이상 아무것도 확인하지 않을 수 있습니다. 따라서 터널 변경 후 성공한 로드는 라우팅이 아니라 기억의 시연일 수 있습니다. 실패가 없다는 것이 조회가 있다는 뜻은 아닙니다.

이 구분은 다음에 무엇을 테스트해야 하는지를 바꿉니다. 새 리졸버가 응답한다는 것을 보여 주는 것이 목표라면, 비우지 않은 캐시에서 제공될 수 없는 조회가 필요합니다.

캐시된 성공을 이전에 접근할 수 없던 서버가 복구되었다는 증거로 읽는 것은 거짓 전제로 사건을 닫기 때문에 이 실수의 가장 비싼 형태입니다.

결론을 내리기 전에 캐시를 세어 보세요

꼽을 만한 네 가지는 애플리케이션 자체의 확인, 운영체제의 클라이언트 캐시, 브라우저의 내부 상태, 그리고 조회가 마침내 도달하는 재귀 리졸버입니다. 각각 별도의 수명과 별도의 비우는 방법이 있습니다. 하나를 비우고 다른 하나를 테스트하는 것이 사람들이 비우기가 아무것도 하지 않았다고 결론 내리는 방식입니다. 비우기 명령 하나로 문제가 해결되는 경우는 없습니다.

부정 응답도 캐시됩니다. 없다고 보고된 이름은 네트워크가 수정된 뒤에도 없을 수 있으며, 이는 고장 난 터널로 읽히지만 실제로는 아직 만료되지 않은 TTL입니다. DNS 사양은 이 데이터를 어떻게 보관하고 재사용해야 하는지 설명합니다.

인상이 아니라 사건을 기록하세요

무엇이 바뀌었는지, 즉 레코드, 리졸버로 가는 경로, 클라이언트 설정 중 어느 것인지 적으세요. 레코드 편집은 자체 일정에 따라 전파되고, 경로 변경은 재연결 시 적용되며, 브라우저 설정은 그 브라우저에만 적용됩니다. 이들을 하나의 전후 비교로 묶으면 아무도 감사할 수 없는 타임라인이 만들어집니다.

시간, 사용한 리졸버, 받은 응답을 응답이 부정인 경우도 포함해 적으세요. 그것은 다른 사람이 확인할 수 있는 사실입니다.

같은 방식으로 비교를 두 번 하세요

테스트하려는 캐시를 비우고, 원래 관찰을 유지한 다음, 가능한 한 많은 기억을 우회하는 방식으로 조회하세요. 리졸버를 명시적으로 지정하면 그 리졸버가 무엇을 아는지 알 수 있지만, 애플리케이션이 어떤 리졸버를 선택했을지는 알 수 없습니다.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Windows에서는 클라이언트 캐시 비우기가 DNS 클라이언트 캐시를 비울 뿐 다른 것은 하지 않습니다. 브라우저의 개인 상태를 설명하지 않고 업스트림 서버를 비우지도 않으므로, 그것에 기반한 테스트는 좁게만 해석할 수 있습니다. 결과를 보고할 때마다 어떤 캐시를 비웠는지 말하세요.

그런 다음 새 요청과 의도한 리졸버 정책을 활성화한 상태로 실제 애플리케이션을 다시 테스트하세요. 다른 정책에서 생성된 결과는 이전되지 않습니다.