요약

  • RFC 3152는 IPv6 주소-이름 매핑을 위해IP6.ARPA를 선택하고, IAB 지침에 따라 위임을 요청했으며, 추가 위임을 IPv6 주소 할당 체계와 정렬했습니다. 그러나 이 문서 자체가 모든 역방향 존을 채우거나 모든 클라이언트를 갱신한 것은 아닙니다.
  • IP6.INT폐기 지정은 이것이 새로운 구현에는 부적합하며 질서 있게 단계적으로 퇴역해야 한다는 의미였습니다. 이후 2005년의 철회 일자는 표준 선택과 배포된 전환이 서로 다른 사건임을 확인해 줍니다.
  • 신뢰할 수 있는 이전 기록은 RFC 상태, 부모 및 자식 위임, PTR 데이터, 리졸버 접미사, 캐시, DNS 응답, 검증 및 애플리케이션 결과를 분리합니다. 역방향 응답은 인증된 호스트 신원이 아닙니다.

표준 결정은 마지막 쿼리가 이동하기 전에 도착했다

RFC 3152는 몇 페이지에 불과합니다. 그 간결함 자체가 이야기의 일부입니다. IPv6는 이미 IPv4의IN-ADDR.ARPA에 상응하는 주소 기반 DNS 트리가 필요했습니다. 이전 사양들은IP6.INT를 언급했습니다. 2001년까지 IAB는 기술 인프라 네임스페이스의 본거지로.ARPA를 선호했고, IETF 합의는IP6.ARPA로 수렴했습니다.

그래서 이 RFC는 세 가지 조치를 취했습니다. 역방향 트리가.ARPA아래 속하는 이유를 설명했고, 다섯 개의 이전 RFC에서IP6.INT참조를 폐기했으며, IANA에 IAB 지침에 따라IP6.ARPA위임을 요청했습니다. 그 지점 아래의 이름들은 IPv6 주소 할당의 계층 구조를 따르며 지역 인터넷 레지스트리로 이어져야 했습니다.

이 어느 것도 실행 중인 리졸버를 변경하는 것과는 같지 않았습니다. 문서는 폐기를 신중하게 정의했습니다. 기존 사용 방식은 새로운 구현에 부적합하며 질서 있게 단계적으로 퇴역할 가능성이 높다는 것이었습니다. 이 문서는IP6.INT가 사라졌다거나, 모든 라이브러리가 새 접미사를 출시했다거나, 할당된 모든 프리픽스가 이미 작동하는 PTR 데이터를 갖추었다고 선언하지 않았습니다.

이 간극은 실패가 아닙니다. 분산형 이전의 메커니즘입니다. 공통 목적지는 모든 참여자가 준비되기 전에 선택될 수 있고, 오래된 경로는 소프트웨어와 운영자가 이동할 수 있도록 충분히 오래 관찰 가능한 상태로 남습니다.

역방향 네임스페이스에는 여러 제어 평면이 있었다

"도메인을 위임한다"는 표현은 하나의 관리 스위치처럼 들릴 수 있습니다. RFC 3152는 사슬을 기술했습니다. IETF가 기술 합의를 제공했습니다. IAB는 인프라 네임스페이스에 대한 지침을 제공했습니다. IANA가 최상위 운영 역할을 보유했습니다. 지역 레지스트리들은 IPv6 주소 공간 위임에 따라 구역을 배정받았습니다. 트리 아래쪽의 운영자들은 자신의 역방향 존과 PTR 레코드를 통제했습니다.

RFC 3172는 한 달 뒤 이 설계를 더 명시적으로 만들었습니다. 이 문서는.ARPA를 제한된 용도의 인프라 도메인으로 기술하고 올바른 운영을 필수로 취급했습니다.IP6.ARPA는 IANA에 위임된 뒤 RIR 할당에 따라 세분화되었습니다. 이 계층 구조는 번호 공간의 권한 구조를 거울처럼 반영하기 위한 것이었습니다.

할당을 반영하는 것이 각 층을 동일하게 만들지는 않았습니다. 역방향 위임 없이 주소 할당이 존재할 수 있습니다. 자식이 lame인 상태에서 부모 참조가 존재할 수 있습니다. 자식이 권위 있는 응답을 하면서도 PTR 레코드를 포함하지 않을 수 있습니다. PTR 레코드가 가리키는 이름의 정방향 데이터가 다시 그 주소로 돌아오지 않을 수 있습니다. 각 관찰은 서로 다른 운영자와 시계에 속합니다.

그렇기 때문에 레지스트리 영수증은 DNS 추적의 대용품이 될 수 없습니다. 전자는 누가 블록이나 위임을 받았는지 말합니다. 후자는 특정 시각에 어떤 서버가 특정 쿼리에 응답했는지 말합니다. 애플리케이션 결과는 그보다 더 뒤에 있습니다.

트리의 이름과 트리 안의 데이터는 서로 다른 사실이었다

RFC 3596은 이후 안정된 IPv6 DNS 설계를 통합했습니다. IPv6 주소는 16진수 니블의 열이 되어, 각 니블이IP6.ARPA아래 역순으로 자체 라벨에 배치됩니다. PTR 쿼리는 그 주소 기반 오너 이름에 연관된 이름을 요구할 수 있습니다.

쿼리를 올바르게 구성한다는 것은 소프트웨어가 의도한 네임스페이스에 물었다는 것만 증명합니다. 부모 위임이 존재한다거나, 관련 RIR과 자식 위임이 최신이라거나, 응답이 존재한다는 것은 증명하지 않습니다. 유효한 쿼리는 참조, NXDOMAIN, 타임아웃, SERVFAIL, 서명되지 않은 응답, 검증된 응답 또는 오래된 캐시 결과로 끝날 수 있습니다.

PTR 응답조차 존 운영자가 저장한 진술입니다. 호스트의 신원, 소유권 또는 권한의 증명서가 아닙니다. 도달 가능성을 증명하지 않으며, 반환된 이름의 정방향 조회가 같은 주소로 되돌아온다는 것도 증명하지 않습니다. 일부 애플리케이션은 정방향 확인된 역방향 DNS를 수행하고, 다른 애플리케이션은 문자열을 표시하기만 합니다. 어느 쪽 동작도 RFC 3152가 제공하는 바가 아닙니다.

따라서 이 이전에는 서로 직교하는 두 차원이 있었습니다. 소프트웨어는 새 루트 아래에 물어야 했습니다. 운영자는 그 아래에 위임과 데이터를 제공해야 했습니다. 한쪽이 앞서고 다른 쪽이 뒤처질 수 있었습니다.

"질서 있게"는 동등성을 선언하지 않으면서 중복을 허용했다

깔끔한 역사 다이어그램은IP6.INT에서IP6.ARPA로 화살표를 그릴 수 있습니다. 실제 이전은 두 개의 시계에 가깝습니다. 새 소프트웨어는 새 접미사를 선호하면서 오래된 버전은 계속 구 접미사를 쿼리할 수 있습니다. 운영자는 양쪽 트리를 임시로 지원할 수 있습니다. 리졸버 캐시는 권위 있는 데이터가 변경된 뒤에도 긍정 또는 부정 응답을 유지할 수 있습니다.

중복은 조정 비용을 줄이지만, 증거도 복잡하게 만듭니다. 애플리케이션이 조용히 폴백한다면, 표시된 성공적인 이름이 어느 트리에서 왔는지 드러내지 않습니다. 두 트리에 서로 다른 PTR 데이터가 있다면, 양쪽에서의 성공이 응답을 동등하게 만들지는 않습니다. 새로 만들어진 위임 이후에도 부정 캐싱이 남아 있다면, 권위 있는 변경은 올바르면서 클라이언트는 여전히 부재를 관찰할 수 있습니다.

그러므로 유용한 전환 기록에는 정확한 쿼리 이름, 리졸버, 캐시 상태, 참조 체인, 권위 있는 서버, 응답 코드, 응답, TTL 및 검증 상태가 포함됩니다. 접미사를 선택한 라이브러리 또는 애플리케이션 버전도 기록되어야 합니다. 그런 영수증이 없다면 "역방향 DNS가 작동했다"는 표현이 실제로 작동한 이전의 부분을 가려 버립니다.

이후 연표가 그 간격을 확인해 줍니다. 2003년의 RFC 3596은IP6.ARPA를 표준 트랙 IPv6 DNS 사양에 통합하면서 RFC 1886과 3152를 대체했습니다. RFC 4159는 2005년 9월 1일부터 표준에 적합한 IPv6 구현은IP6.INT를 더 이상 사용해서는 안 되며, RIR들은 자신들의 커뮤니티와 협력해 등록 지원을 중단하도록 작업하라고 권고했습니다. 2001년의 결정은 실제였고, 운영상의 철회는 여전히 추가 단계를 필요로 했습니다.

메모를 대체하는 것은 그 결과를 보존했다

RFC 메타데이터 라벨은 운영상의 판정으로 오독될 수 있습니다. RFC 3596이 RFC 3152를 "대체"한 것은 이전 IPv6 DNS 사양과 네임스페이스 변경을 결합했기 때문입니다. 이것은IP6.ARPA를 은퇴시키지 않았습니다. 선택된 트리는 이후 통합 표준의 일부가 되었습니다.

주변 설계도 계속 진화했습니다. RFC 3363은 A6과 비트스트링 라벨 메커니즘을 실험적 상태로 옮기고 AAAA 레코드를 선호했습니다. RFC 5855는 나중에 IPv4와 IPv6 역방향 존에 안정적인 네임서버 명명 체계를 부여했습니다. RFC 9121은.INT에서 제거된 역사적 인프라 도메인 중IP6.INT를 기록했습니다.

이 후속 문서들은 하나의 완벽한 결정이라는 이야기로 압축되어서는 안 됩니다. 이들은 서로 다른 유지보수 표면, 즉 쿼리 형식, 부모 네임스페이스, 레코드 설계, 서버 명명, 그리고 폐기된 트리의 퇴역을 보여줍니다. 어떤 문서는 그 규칙이 다른 곳에 흡수되었기 때문에 대체될 수 있습니다. 위임을 도입한 RFC가 더 이상 지배 사양이 아니더라도 네임스페이스는 여전히 현행일 수 있습니다.

"새로운 위협 없음"은 역방향 DNS를 신원 시스템으로 만들지 않았다

RFC 3152는 위조된 주소-이름 매핑이 IPv4에서 이미 악용되었음을 언급하고,IP6.ARPA의 위임이 새로운 위협을 만들지 않는다고 밝혔습니다. 이 좁은 주장은 네임스페이스 루트의 변경에 관한 것입니다. PTR 데이터가 신뢰할 수 있다거나, 역방향 이름이 사용자, 호스트 또는 서비스를 승인할 수 있다고 말하지 않습니다.

RFC 3596은 이 경계를 더 직접적으로 밝혔습니다. DNS 정보는 적절한 보안 기법이 사용되지 않는 한 안전하지 않은 것으로 취급되어야 하며, IPv6 확장은 새로운 보안 문제를 만들지도 기존 문제를 해결하지도 않는다는 것입니다. DNSSEC 검증은 신뢰 체인에 상대적으로 DNS 데이터를 인증할 수 있습니다. 그럼에도 PTR 이름에 애플리케이션이 부여하는 인간적 의미, 엔드포인트의 현재 보유 관계, 또는 조치할 권한을 증명하지는 못합니다.

따라서 보안 검토는 이 결합을 보존해야 합니다. 응답이 검증되었는가? 어느 존이 서명했는가? 애플리케이션이 정방향 검사를 수행했는가? 결과가 단순히 기록되었는가, 아니면 접근에 영향을 주었는가? 그럴듯하게 보이는 역방향 이름에서 신뢰를 부여하는 정책은 RFC 3152가 제공한 증거를 훨씬 넘어서는 것입니다.

이전 상태에 대한 최종 발언권은 실행 중인 코드에 있었다

부모 위임이 올바르고 프리픽스 보유자가 유효한 PTR을 게시했다고 가정해 봅시다. 한 개의 오래된 라이브러리는 계속IP6.INT를 쿼리하고 아무것도 받지 못합니다. 다른 라이브러리는IP6.ARPA에 물지만 자식 위임 이전의 부정 캐시 항목을 유지합니다. 세 번째는 새 응답을 받아 표시합니다. 세 사례의 표준 입장은 동일하지만, 관찰된 결과는 그렇지 않습니다.

실행 코드 우위가 BCP를 뒤집지는 않습니다. RFC 3152는 의도된 루트와 위임 모델에 관해 권위적입니다. 실행은 특정 쿼리가 그 루트를 사용했는지, 의도된 권위에 도달했는지, 기대한 데이터를 얻었는지, 그리고 주장된 대로 애플리케이션에 영향을 주었는지를 알려 줍니다.

현실의 층이 중요한 이유는 정확히 이 이전이 자발적이고 분산되어 있기 때문입니다. 작은 초기 사양, 즉 인프라 루트를 선택하고 위임을 요청하며 주소 할당과 정렬하고 오래된 이름을 폐기한다는 것은, 하나의 동기화된 글로벌 릴리스를 요구하지 않으면서 공통 방향을 만들었습니다. 그 경제성이 이동을 가능하게 했습니다. 동시에 정직한 영수증을 없어서는 안 될 것으로 만들었습니다.

오래된 교훈은 DNS 트리의 이름 바꾸기가 쉽다는 것이 아닙니다. 조정은 허구가 아니면서 수렴보다 앞서 있을 수 있다는 것입니다.IP6.ARPA는 모든 리졸버가 사용하기 전에도 올바를 수 있었고,IP6.INT는 마지막 운영 흔적이 사라지기 전에도 폐기 상태일 수 있었습니다.

출처