VPN의 DNS가 잘못되었나요? 권한 서버 한 대가 오래된 것일 수 있습니다

VPN에 연결하면 호스트 이름 하나가 어제의 주소로, 또는 아무것도 아닌 곳으로 해석된다. 연결을 끊으면 다시 동작한다. 반사적으로는 터널이 밀어 넣은 리졸버를 의심하게 되지만, 더 흔한 원인은 존 업데이트를 받지 못하게 된 공개 네임 서버다. 새 경로가 캐시된 응답이 나온 권한과 다른 권한에 도달했을 뿐이다.

증상은 리졸버에 따라 달라진다

재귀 리졸버는 권한 서버가 알려준 내용을 반환한 뒤 그 응답을 TTL 동안 보관한다. 터널이 다른 리졸버를 밀어 넣거나, 기존 리졸버에 더는 도달할 수 없게 경로를 바꾸면 클라이언트는 다른 권한에 묻고 다른 응답을 받는다. 그 순간 도메인이 바뀐 것이 아니라, 도메인에 대한 당신의 시야가 바뀐 것이다.

그래서 같은 이름이 한 사무실에서는 되고 호텔에서는 실패하며, 로컬 캐시를 지우는 것이 때때로만 도움이 되는 것이다. 캐시를 지우면 질문이 다시 같은 권한으로 간다.

구분하는 시험은 공개된 각 서버에 대한 직접 질의다.

각 권한에 직접 질의하라

기억에 의존한 목록이 아니라 위임에서 시작하라. 상위에 NS 집합을 묻고, 그 집합의 각 이름에 필요한 레코드를 질의하라. 같은 이름을 서로 다른 권한에 두 번 질의하면 존이 일관적인지 즉시 알 수 있다.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

존 꼭대기의 NS 레코드에도 같은 일을 하라. 이전 후에는 상위 위임과 존 자체의 NS 집합이 어긋날 수 있기에, 다음으로 비교할 것은 SOA의 일련번호이고 크게 뒤처진 보조 서버는 응답 문제가 아니라 전송 문제다.

그 질의는 자기 책상에서만이 아니라 실패하는 네트워크에서 실행하라.

의도된 뷰와 깨진 뷰를 구분하라

일부 도메인은 지역이나 리졸버 그룹에 따라 의도적으로 다르게 응답하며, 분할 지평 구성은 기업 네트워크에서 흔하다.

문제는 그 차이가 문서화되어 있고 안정적인지다. 의도하지 않은 뷰는 모습이 달라, 한 권한에는 다른 서버가 결코 받지 못한 레코드가 있거나 모두가 공유하는 레코드가 빠져 있다. RFC 2182의 선택과 배포 지침은 권한 가용성을 공동 책임으로 다루는데, 여기서도 그것이 올바른 틀이다. 이중화는 공개된 모든 서버가 의도된 데이터로 응답할 수 있을 때만 존재하며, 53번 포트에서 연결을 받아들이기만 해서는 안 된다.

SERVFAIL로 응답하는 서버는 자신 있게 잘못 응답하는 서버보다 진단하기 쉽다.

이전은 캐시가 감추고 있던 것을 드러낸다

제공업체를 옮기는 동안 상위 위임과 존 자체의 NS 레코드라는 두 권한 위치가 바뀐다. 둘 다 갱신해야 하고, 둘 다 각자의 TTL 동안 캐시된다. 옛 서버가 계속 살아 있으면서 이전 존을 제공하면, 그 서버에 묻는 리졸버를 쓰는 클라이언트는 전환이 완료된 것처럼 보인 뒤에도 한참 동안 옛 응답을 받는다.

장수 캐시가 감추는 상태가 바로 이것이다. 일주일 내내 잘 동작하던 워크스테이션은 새 권한의 신선한 응답을 들고 있는 리졸버와 대화하고 있었고, 옛 서버는 다른 모두에게 오래된 데이터를 계속 나눠 주고 있었다.

노트북에서 리졸버를 바꾸면 그 노트북만 고쳐지고 다른 것은 아무것도 고쳐지지 않는다.

고칠 것은 존이지 리졸버가 아니다

어떤 서버가 그 존의 권한 서버여야 하는지 확인하고, 관리 존이나 위임을 고쳐 그 모두가 의도된 데이터를 제공하게 하고, 계획한 이중화를 유지하라. VPN 출구 하나가 이상한 응답을 받았다고 네임 서버를 삭제하면 가용성이 줄고 불일치는 그대로 남는다.

그다음 두 네트워크에서 직접 질의를 다시 실행하고 변경한 레코드의 TTL이 만료되기를 기다려라.

각 권한에서 응답이 안정적인지 확인하고, 의도된 뷰를 존 문서에 적어 두면 다음 차이를 분류하기 쉽다.