VPN DNS 보고서: 재현되려면 무엇을 담아야 하나

«DNS가 고장 났다»는 결론이며, 도우미가 행동할 수 있는 결론이 아닙니다. 보고서의 쓸모 있는 부분은 어떤 이름이, 어떤 리졸버를 거쳐, 어떤 응답을 받았는지 하는 실패의 모양입니다. 세 가지 세부 정보가 불만을 재현 가능한 것으로 바꾸며, 비공개 부분의 이름을 바꾸면 셋 다 안전하게 공유할 수 있습니다. 다음은 누군가 도울 수 있기 전에 VPN DNS 보고서가 갖춰야 할 최소한입니다.

이름의 분류이지 판결이 아님

이름 자체에서 시작해 공개, 내부, 짧은 이름, 완전 수식 이름, 또는 특정 접미사가 제공하는 이름 가운데 하나로 분류합니다. 공개 이름은 해석되는데 내부 이름이 실패하면 도달 가능성이 아니라 리졸버 선택의 문제입니다. 모든 이름이 실패하면 리졸버로 가는 경로의 문제이며, 이는 다른 증거를 가진 다른 조사입니다. 분류가 진단을 담고, 정확한 문자열은 가릴 수 있습니다.

실패에 터널이 켜져 있어야 하는지, 아니면 연결이 끊긴 뒤에 생기는지 적습니다. VPN이 활성일 때만 깨지는 이름은 링크별 설정을 시사하고, 연결이 끊긴 뒤 깨지는 이름은 남은 상태를 시사합니다. 보고서는 보통 이것을 빼놓고는 첫 제안이 왜 도움이 안 되는지 궁금해합니다.

리졸버 경로를 기록합니다

명시적으로 고른 서버로 보낸 질의와 애플리케이션의 일반 조회는 다른 실험이므로, 어느 쪽이 실패를 만들었는지 적으세요. 작동하는 서버로 보낸 수동 질의는 그 서버가 작동한다는 것만 증명합니다. 아래 명령은 시스템 경로와 직접 질의를 분리합니다.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

status 출력은 링크별 서버와 라우팅 도메인을 보여 주며, 이는 분할 DNS가 결정되는 곳입니다. getent 호출은 nsswitch 순서를 포함해 애플리케이션과 같은 경로를 따릅니다. 직접 질의는 둘 다 우회하고 서버 하나만 따로 시험합니다. 셋 중 무엇이 실패하고 무엇이 성공했는지 적으면, 읽는 사람은 더 이상 경로를 추측하지 않아도 됩니다.

통제된 비교를 적습니다

변수 하나를 바꾸고 무엇이 바뀌었는지 적습니다. 공개 이름은 해석되는데 내부 이름이 실패하는 것은 선택 문제이고, 모든 이름이 시간 초과되는 것은 경로 문제이며, 사설 이름이 공개 주소로 해석되는 것은 잘못된 리졸버로의 유출입니다. 그 셋 중 둘은 터널이 켜져 있는지와 아무 관련이 없습니다. 모든 질의가 고장 났다고 주장하는 보고서에는 보통 한 번도 실행되지 않은 비교가 들어 있습니다.

해석과 전달을 분리합니다. 이름이 해석되는데 사이트가 여전히 실패하면 DNS 단계는 성공한 것이므로 보고서는 그렇게 적어야 합니다, 다음 단계는 리졸버가 아니라 경로나 리스너이기 때문입니다. 이 하나의 구분만으로도 어떤 로그 발췌보다 자주 질문 한 차례를 아낍니다.

이름 공간은 가리고, 관계는 남깁니다

내부 이름은 대체물이 구조를 유지하는 한 바꿀 수 있습니다. 서로 다른 서버와 접미사마다 안정된 레이블을 붙이고, 그 대응표는 공유 사본 밖에 둡니다. 모든 내부 호스트를 같은 자리 표시자로 바꾸면 보고서에 필요한 증거가 바로 파괴됩니다, 한 접미사는 해석되고 다른 하나는 그렇지 않았다는 사실을 읽는 사람이 더는 볼 수 없기 때문입니다. 같은 규칙이 주소에도 적용되며, 접두사 관계는 유지하고 정책이 요구하면 호스트 비트를 바꿉니다.

기록은 검증된 채널로 보내고 진단에 결코 필요 없는 것은 빼세요. 비밀번호, 개인 키, 무관한 회사 이름은 DNS 질문의 일부가 아닙니다. 읽는 사람에게 필요한 것은 실패 분류, 리졸버 경로, 정확한 오류, 그리고 당신이 수행한 하나의 비교입니다.