요약

  • RFC 3425는 DNS 오피코드 1, 즉 IQUERY를 영구 은퇴시키고, 이를 받은 네임 서버가Not Implemented로 답해야 한다고 정했다. 이 응답은 작업에 대한 것이었지, 어떤 이름의 존재에 대한 것이 아니었다.
  • 역방향 DNS는 위임된 네임스페이스 안의 명시적 PTR 레코드를 통해 살아남았다. IQUERY 거부, NXDOMAIN, NODATA, PTR 응답, DNSSEC 검증 결과는 서로 다른 권한을 가진 서로 다른 접수 증표다.

이름이 판정되기 전에 메시지가 실패했다

오래된 진단 도구가 오피코드 1을 담은 DNS 패킷을 보내는 장면을 상상해 보라. 서버는NOTIMP로 답한다. 대시보드는 이를 "역방향 이름 없음"으로 바꿔 번역한다. 그 문장은 간결해 보이지만, 프로토콜이 분리해 둔 두 결정을 하나로 합쳐 버린다.

첫 번째 결정은 서버가 IQUERY를 수행하는가 하는 것이다. 두 번째는 DNS 네임스페이스가 특정 오너 이름과 레코드 타입에 대해 무엇을 말하는가 하는 것이다. 2002년 11월에 발표된RFC 3425는 첫 번째 경로를 닫았다. IQUERY를 폐기(obsolete)로 만들고, RFC 1035의 관련 텍스트를 대체하며, 해당 오피코드가 도착하면 서버가Not Implemented를 반환하도록 지시했다.

그것은 은퇴한 작업에 대한 성공적인 표준 응답이다. 서버는 이름을 검색했을 필요가 없다. NXDOMAIN을 반환한 것도 아니다. 명시적 PTR 레코드의 부재를 증명한 것도 아니다. 서버는 더 이상 회선에 있을 자격이 없는 질문을 식별했을 뿐이다.

IQUERY는 데이터베이스를 뒤집으려 했다

RFC 1035의 원래 메커니즘은 역방향 DNS 트리에 PTR 오너 이름을 물어보지 않았다. 요청자는 응답 섹션에 리소스 레코드 값을 놓고, 접촉한 서버에게 질문 섹션에 일치하는 타입·이름·클래스 튜플을 반환해 달라고 요청했다.

이 구조 때문에 서버의 로컬 데이터베이스가 검색 표면이 되었다. 일반적으로 답하려면 서버는 자신의 레코드를 훑거나 값을 키로 하는 별도의 인덱스를 유지해야 했다. RFC 1035는 이미 그 작업을 잠재적으로 고된 것으로 묘사했다. RFC 3425는 운영적 귀결을 더 선명하게 했다. 수백만 개의 이름에 대해 권한을 가진 서버는 값비싼 검색과 비정상적으로 큰 응답에 직면할 수 있었다.

이 문서는 말해 주는 예를 들었다. 하나의 대형 제공자의 네임서버에 위임된 모든 도메인을 묻는다면 수만 개의 튜플이 나올 수 있다는 것이다. 이 질문은 단순히 "거꾸로"였을 뿐 아니라, 압축된 입력을 거대한 열거로 바꾸고, 운영자가 거의 쓰지 않는 코드를 가동시키며, 이름을 일괄 노출할 수 있었다.

접촉된 한 서버는 질문을 다음으로 넘길 수 없었다

보통의 DNS 해석은 네임스페이스로부터 권한을 얻는다. 리졸버가 아직 답을 갖고 있지 않다면, referral이 해당 이름을 책임지는 서버 쪽으로 리졸버를 이동시킬 수 있다. IQUERY에는 그 유용한 방향이 없었다. 그 답은 이를 받은 특정 서버의 내용물에 의존했다.

어떤 값이 다른 곳에 존재하면서도 접촉된 서버는 그것에 대해 아무것도 모를 수 있다. 서버는 관련 데이터를 들고 있으면서도 작업을 거부할 수 있다. 두 서버는 로컬 데이터베이스가 다르기 때문에 합법적으로 서로 다른 역검색 결과를 낼 수 있었다. 결과는 "이 값과 연관된 모든 이름"에 대한 전역적 진술로 쓰기에 부적합했다.

이것이 역(inverse)이라는 단어가 가린 권한 경계다. 한 노드에서의 데이터베이스 반전은 위임된 역방향 네임스페이스에서의 조회와 같은 것이 아니다.

PTR이 역방향 질문을 명시적으로 만들었다

운영적 대안은 이미 익숙한 것이었다. 역방향 매핑을 평범한 DNS 데이터로 인코딩하는 것이다. IPv4 주소 옥텟은in-addr.arpa아래 표현되며, 클라이언트는 정확한 오너 이름에서 PTR 레코드를 요청한다.RFC 1033,RFC 1034, RFC 1035가 그 주변의 DNS 모델을 문서화하고,RFC 2317은 /24보다 작은 주소 블록에는 마법 같은 데이터베이스 반전이 아니라 명시적인 위임 장치가 필요함을 보여 준다.

이것은 역방향 DNS를 완전하거나 무결하게 만든 것은 아니다. 질문을 라우팅 가능하고 행정적으로 범위가 정해진 것으로 만들었을 뿐이다. PTR 응답은 오너 이름, 위임 경로, 응답 권한, TTL, 그리고 배포된 곳에서는 DNSSEC 검증과 결부될 수 있다. 레코드의 부재는 다른 작업의 거부에서 추론하는 대신 DNS의 부정응답 장치로 표현될 수 있다.

하나의 라벨을 공유하면 안 되는 네 가지 응답

NOTIMP는 응답자가 요청된 작업을 구현하지 않았음을 말한다. NXDOMAIN은 조회된 오너 이름이 관련 DNS 의미론 안에서 존재하지 않음을 말한다. NODATA는 존재하는 이름에 요청된 타입이 없음을 묘사한다. 타임아웃은 관찰 창이 닫히기 전에 수용 가능한 응답이 도착하지 않았음을 말한다.

이 상태들은 서로 다른 다음 행동으로 이어진다. IQUERY에 대한NOTIMP이후에는 진단 클라이언트가 적절한 PTR 질문을 구성해야 한다. NXDOMAIN 이후에는 권한과 부정 캐싱 맥락을 보존해야 한다. 검증 실패 이후에는 결과를 조용히 평범한 부재로 재라벨링해서는 안 된다. 타임아웃 이후에는 전송과 재시도 증거를 보존해야 한다.

RFC 8020은 이후 리졸버가 권위 있는 NXDOMAIN을 사용하는 방식을 다듬었다. 그러나 오피코드 거부를 NXDOMAIN으로 바꾸지는 않았다.RFC 8499는 현대 DNS 용어를 정확하게 유지하는 데 도움을 준다. 이 구분은 절차적·증거적이며, 화장품적인 것이 아니다.

은퇴는 번호를 보존했다

RFC 3425는 오피코드 1의 정의를 "IQUERY (obsolete)"로 바꾸고 영구 은퇴를 요청했다.IANA DNS Parameters 레지스트리와RFC 6895가 그 역사를 보존한다.

영구 은퇴는 미할당 빈 공간과 같지 않다. 번호를 재사용하면 오래된 패킷이 모호해진다. 은퇴된 의미를 담은 것인가, 새 의미를 담은 것인가? 예약은 해석자를 그 충돌로부터 보호한다. 그것은 부정적 능력, 즉 새 프로토콜 작업이 주장해서는 안 되는 무엇을 기록한다.

레지스트리 상태가 모든 오래된 파서가 사라졌음을 증명하지도 않는다. 명세, 구현, 구성, 수신 패킷, 관찰된 응답은 여전히 별개의 계층이다. 레지스트리는 의도된 의미를 진술하고, 패킷 캡처와 구현 기록은 특정 경계에서 무엇이 일어났는지를 진술한다.

DNSSEC는 네임스페이스 데이터를 인증할 수 있었지만, 임의의 반전을 구하지는 못했다

RFC 3425는 DNSSEC로 IQUERY 응답을 보호하는 것이 온더플라이 서명 없이는 극히 어렵다고 관찰했다. 이는 질문의 구조에서 비롯된다. 이 질문은 명명된 오너의 기존 RRset을 검색하라는 것이 아니라, 서버에게 잠재적으로 거대한 역방향 인덱스 결과를 합성하도록 요구했다.

RFC 4033,RFC 4034,RFC 4035는 DNSSEC의 아키텍처, 레코드, 검증 동작을 명시적 DNS 데이터를 중심으로 정의한다. 서명된 PTR 데이터나 인증된 부정은 그 네임스페이스 안의 결론을 지지할 수 있다. IQUERY에 대한NOTIMP응답은 DNS 메시지로 도착했다는 이유만으로 그 결론을 물려받지 않는다.

인증은 여전히 신원에는 미치지 못한다. 검증된 PTR은 서명된 존이 검증 시점과 정책 상태에서 매핑을 주장했음을 증명한다. 그것 자체로 주소 할당, 호스트 통제, forward-confirmed 역방향 DNS, 도달 가능성, 애플리케이션 인증, 서비스 성공을 증명하지는 않는다.

유용한 거부

프로토콜은 성공적인 답을 자주 기리고 있다. RFC 3425는 다른 종류의 성공을 보존했다. 폐기된 질문을 거부하면서 명시적 네임스페이스를 그대로 이용 가능하게 유지한 것이다. 그 거부는 서버 자원을 보호하고, 잘 쓰이지 않는 열거 코드를 통한 노출을 줄였으며, 역방향 조회를 더 명확한 행정적 소유자를 가진 경로로 밀어 넣었다.

오래 지속될 교훈은 오류가 비밀리에 답이라는 것이 아니다. 오류에는 주어가 있다는 것이다.NOTIMP는 작업에 대해 말한다. NXDOMAIN은 이름에 대해 말한다. PTR RRset은 오너 이름의 데이터에 대해 말한다. DNSSEC는 그 데이터의 검증 또는 부정에 대해 말한다. 좋은 운영은 그 주어들을 온전하게 유지한다.

출처와 한계

1차 기록은RFC Editor HTML,일반 텍스트,RFC Editor 정보 페이지,IETF Datatracker 문서 페이지, 그이력과참고문헌, 그리고RFC Editor 정오표 검색에 보존되어 있다. DNS 맥락은RFC 1033,RFC 1034,RFC 1035,RFC 2317,RFC 6895,RFC 8499,RFC 4033,RFC 4034,RFC 4035,RFC 8020및IANA DNS Parameters 레지스트리에서 나온다. 기호적 명세와 관찰된 작업의 분리는 Lu Heng의현실 계층과running code as primary에세이를 따른다.

이 출처들은 프로토콜 역사와 정의된 의미론을 지지한다. 그것들은 현재 배포 인구조사, 특정 취약 서버의 지명, 측정된 공격, 완전한 PTR 커버리지, 호스트 신원, 도달 가능성, 권한 부여, 애플리케이션 결과를 제공하지 않는다.