DNS 레코드를 고쳤는데 NXDOMAIN이 남는 이유: 음수 캐시와 SOA TTL

NXDOMAIN과 NODATA는 무엇이 다른가요?

NXDOMAIN은 이름의 부재를, NODATA는 유효한 이름에 요청한 유형의 레코드가 없음을 뜻합니다.

RFC 2308의 응답 구분에서 NODATA는 별도 응답 코드가 아니라 응답 내용으로 판별하는 범주입니다. NXDOMAIN을 볼 때는 응답이 가리키는 이름을, NODATA를 볼 때는 이름과 요청한 레코드 유형을 함께 살펴보세요. 화면에 원하는 주소가 없다는 인상만으로는 둘을 구분하기 어렵죠.

운영 검토에서는 먼저 실제 응답이 어느 쪽인지 표시하는 방법을 제안합니다. 수정한 이름과 조회한 이름, 기대한 유형과 요청한 유형을 나란히 읽는 것이 출발점이죠.

수정한 뒤에도 부재 응답을 따로 확인해야 하나요?

음수 캐시는 이름이나 요청 유형의 레코드가 없다는 응답을 보관하므로 수정 뒤 조회에서도 검토할 대상입니다.

캐시는 존재하는 주소만 떠올리기 쉽지만, 여기서 살펴보는 대상은 없다는 응답을 보관한 음수 캐시입니다. 따라서 수정 후 같은 부재 응답을 보았다는 이유만으로 변경 실패라고 결론 내리지 마세요. 현재 읽은 응답을 먼저 구분해 보는 순서죠.

이후 내용은 특정 제품의 진단 절차가 아닌 운영 편집 제안이죠. 수정 내역과 조회 결과를 별도로 읽고, 캐시가 원인이라는 판단도 비교 전에는 열어 두는 편이 좋습니다.

음수 캐시의 TTL은 어디에서 정하나요?

음수 응답의 SOA TTL은 SOA TTL과 SOA.MINIMUM 중 작은 값이며 캐시에서는 감소합니다.

이 기준은 RFC 2308의 음수 응답 캐시 설명에서 확인할 수 있습니다. 설정값 하나만 보고 모든 조회의 복구 시점을 정하는 대신, 실제 응답에서 읽은 TTL을 조회 시각과 함께 확인하면 좋죠.

운영 메모에는 설정에서 확인한 값과 응답에서 읽은 값을 구분해 적는 방식을 제안합니다. 서로 다른 시각의 숫자를 같은 조건의 결과처럼 비교하지 않기 위한 구분이죠. 남은 TTL 하나를 전체 서비스의 복구 약속으로 바꿀 수는 없죠.

권한 서버와 재귀 리졸버의 응답은 어떻게 비교하나요?

같은 이름과 레코드 유형을 조회 대상으로 고정하고 권한 서버와 재귀 리졸버의 응답을 나란히 읽어 보세요.

여기서는 DNS 캐시 운영 검토 방법을 제안합니다. 조회 대상, 응답을 받은 서버, 조회 시각을 먼저 확인한 뒤 응답 종류와 TTL을 비교합니다. 이름이나 유형이 다르면 서로 다른 질문의 답을 비교하는 셈이죠.

권한 서버 쪽에서 기대한 결과를 확인했더라도 다른 경로까지 확인 완료로 적지 않는 편이 좋습니다. 반대로 재귀 리졸버 한 곳의 부재 응답만으로 수정 자체가 실패했다고 적지도 마세요. 두 응답에서 무엇이 같은지, 무엇이 다른지부터 문장으로 남깁니다.

복구 후에도 조회 결과가 다르면 무엇을 확인하나요?

조회한 이름과 유형, 응답 서버와 시각을 다시 맞춘 뒤 응답 종류와 TTL의 차이를 확인하는 순서입니다.

아래는 비교 결과를 읽는 운영 검토 제안입니다. 실제 측정 결과나 모든 환경에 적용하는 확정 진단표는 아니에요.

확인 메모의 결론도 관찰한 범위에 맞춰야 하죠. 기대한 응답을 확인한 경로와 아직 부재 응답이 남은 경로를 구분합니다. 모든 DNS 오류를 이 글의 음수 캐시 사례로 묶지는 않습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)