VPN을 통한 NXDOMAIN은 터널 장애가 아닙니다

실패한 조회 하나를 터널이 무너졌다는 증거로 읽는 것은 유혹적이며, 특히 그 이름이 십 분 전에는 동작했다면 더욱 그렇습니다. 응답은 다른 말을 합니다. NXDOMAIN은 리졸버가 질의한 이름이 존재하지 않는다고 선언한 완료된 DNS 트랜잭션이며, 고장 난 터널은 보통 침묵, 타임아웃 또는 잘못된 서버에 대한 확인 시도를 만들어 냅니다. wireshark 없이 하는 이 주장의 형태는 질의 하나, 응답자 하나, 응답 코드 하나이며, 구성 변경 전에 이 세 가지를 기록해 둘 가치가 있습니다.

응답이 실제로 증명하는 것

DNS는 클라이언트가 흔히 하나의 실패로 합쳐 버리는 결과들을 구분합니다. 존재하지 않는 이름은 NXDOMAIN 코드가 붙은 부정 응답을 만들고, 존재하지만 요청한 유형의 레코드가 없는 이름은 빈 응답 섹션이 있는 성공 응답을 만듭니다. 둘 다 애플리케이션에는 쓸모없어 보이며, 이름이 잘못되었다는 뜻인 것은 둘 중 하나뿐입니다.

그 차이가 수리를 어디에 두어야 하는지를 결정합니다. A 레코드가 있는 호스트에서 AAAA 레코드가 빠진 것은 호스트가 빠진 것이 아니며, 그것을 쫓아 인증서를 다시 발급하거나 터널을 다시 만드는 것은 유일하게 있던 단서를 낭비합니다. 이 구분은 후속 조치의 형태도 정합니다: 이름 문제는 존에서 고치고, 유형 문제는 올바른 레코드를 요청하거나 주소 체계가 그냥 없다는 것을 받아들여 고칩니다.

신화: 사설 이름이 없다는 것은 터널이 실패했다는 뜻이다

이 신화가 살아남는 것은 두 사건이 너무 자주 함께 오기 때문입니다. 클라이언트가 VPN에 연결하고, 운영 체제는 이미 신뢰하던 리졸버를 유지하며, 이제 필요한 내부 이름은 사설 존을 들어 본 적 없는 서버에 질의됩니다. 그 서버는 정직하고 부정적으로 응답합니다. 터널은 패킷을 나르고 있으며, 응답은 응답자가 제공하지 않는 이름 공간에 대한 것일 뿐입니다.

분할 지평 구성은 이것을 일상으로 만듭니다: 같은 존 이름이 공개 측과 내부 측에 서로 다른 내용으로 존재하고, 사설 레코드를 아는 것은 내부 리졸버뿐입니다. 따라서 권위 있어 보이는 부정 응답을 얻는 것은 어느 리졸버가 응답했는지에 대한 증거이며, 인터페이스 상태에 대한 증거가 아닙니다.

결과를 좌우하는 구성 세부 사항이 둘 있습니다. 터널은 내부 리졸버를 밀어 넣거나 선택해야 하며, 클라이언트는 그 선택을 조회하는 이름에 적용해야 합니다. 입력한 레코드와 조금 다른 접미사를 지정하는 도메인별 규칙은 질의를 공개 경로로 보내고, 응답은 올바르지만 쓸모없게 됩니다.

올바른 이름으로 올바른 리졸버에 물으십시오

판정을 기록하기 전에 응답자를 기록하십시오. 어느 서버가 응답했는지 보여 주지 않는 조회는 정책 문제와 이름 공간 문제를 구별할 수 없고, 둘의 수정은 서로 무관합니다.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

처음 두 줄은 로컬 리졸버가 무엇을 결정했고 누구에게 물을지를 보여 줍니다. +search 조회는 애플리케이션이 검색 접미사를 붙일 때 하는 일을 재현하며, 이것은 진단 도구에 입력한 질의가 아니라 실제 질의인 경우가 많습니다. 마지막 줄은 클라이언트 정책을 우회해 내부 서버에 직접 물으며, 이것이 성공하는데 일반 조회가 실패한다면 존은 정상이고 질의 라우팅은 정상이 아닙니다.

부정 캐싱은 수정 후의 지연을 설명합니다

부정 응답은 설계상 캐시되며, RFC 2308은 부정 캐시의 수명이 존의 권한 레코드에서 어떻게 유도되는지 설명합니다. 따라서 레코드나 리졸버 규칙을 고쳐도 클라이언트에 즉시 반영된다는 보장이 없고, 캐시된 응답을 계속 돌려주는 조회를 다시 시도해도 새로운 것은 아무것도 증명하지 못합니다. 다른 응답자, 다른 이름 또는 비운 캐시만이 새 증거를 만듭니다.

로컬 캐시를 비우고, 그다음 같은 응답자에게 같은 질의를 반복하십시오. 로컬 리졸버 서비스를 쓰는 시스템에서는 그것이 명령 하나이며, 다른 시스템에서는 서비스 재시작이나 플랫폼 도구이며, 구체적인 도구보다 그 뒤에 동일한 테스트를 반복하는 것이 더 중요합니다.

이름과 경로를 분리하십시오

이름이 예상한 사설 주소로 확인되면 DNS는 주제로서 끝나고 다음 질문은 애플리케이션 경로가 됩니다. 조회에는 응답하지만 연결을 거부하는 호스트는 다른 문제가 있으며, 올바른 응답 뒤에도 리졸버를 계속 조정하는 것은 사건이 무관한 변경 세 개를 얻는 방식입니다. 둘이 일치한다고 가정하기 전에 확인된 주소를 서비스가 실제로 수신하는 주소와 비교하십시오.

기록을 남기십시오: 질의, 응답자, 코드, 확인된 주소입니다. 그 기록은 나중 보고서를 검증 가능하게 만드는 것이며, 진단과 느려 보였던 터널에 관한 이야기 사이의 차이입니다.