요약

  • A6는 별도로 관리되는 DNS 조각들로 IPv6 주소를 조립할 수 있게 했다. 일부 리넘버링 편집을 줄여주었지만, 체인의 모든 연결 고리를 또 하나의 조회, 캐시 상태, 실패 가능성, 행정적 의존성으로 만들었다.
  • RFC 3363은 A6와 이진 레이블을 Proposed Standard에서 Experimental로 옮기고 프로덕션에는 AAAA를 권장했다. 이 상태 변경은 권고 범위를 좁혔을 뿐, 이미 배포된 코드나 영역 데이터를 다시 쓰지는 않았다.

변할 수도 있는 주소를 저장하는 매력적인 방법이 있다. 주소 전체를 한곳에 두지 않는 것이다. 안정적인 호스트 부분은 호스트 근처에 두고, 공급자 프리픽스는 공급자가 교체할 수 있는 곳에 둔다. 그리고 누군가 묻는 순간 리졸버가 조각들을 조합하게 한다.

이것이 RFC 2874에서 정의된 A6 레코드의 독특한 약속이었다. IPv6 프리픽스와 로컬 식별자가 서로 다른 주기로 바뀔 수 있다는 행정적 사실과 DNS 데이터를 정렬한 것이다. 빠른 리넘버링을 위해 상위 프리픽스를 모든 리프 레코드를 편집하지 않고 교체할 수 있었다. 멀티호밍을 위해서는 같은 메커니즘이 여러 프리픽스 관계를 표현할 수 있었다. 설계 관점에서 이것은 128비트 전체를 담는 AAAA 레코드보다 더 일반적이었다.

그 비용은 주소가 답이 되어야 하는 시점에 나타났다. 리졸버가 반드시 하나의 레코드를 읽고 멈출 수 있는 것은 아니었다. 프리픽스 이름을 따라 다른 레코드로, 어쩌면 또 다른 레코드로 이동해야 했다. 각 단계는 독립적인 권위 질의를 요구할 수 있었다. 각 결과에는 자체적인 캐시 상태, 수명, 운영자, 부재 가능성이 있었다.

RFC 3363은 이 의존성 그래프를 표준 결정으로 만들었다. 2002년 8월 Informational 문서로 발행되어 RFC 2673과 RFC 2874를 갱신하고 두 규격 모두를 Proposed Standard에서 Experimental로 옮겼다. DNSEXT와 NGTRANS 커뮤니티에서 인식된 합의를 기록했다: AAAA가 프로덕션에 더 적합하다는 것, A6는 더 나은 이해가 필요한 흥미로운 특성을 지녔다는 것, 그리고 그 이점이 비용과 위험을 상회하는지 아직 아무도 모른다는 것이었다.

이 문구가 중요하다. 이것은 조합 기능에 가치가 없다는 판정이 아니었다. 함께 발행된 RFC 3364는 A6의 실제 장점을 설명하는 데 상당한 분량을 할애했다. A6는 조회 시점에 정적 AAAA 레코드로는 재현할 수 없는 방식으로, 사전 경고 없이 바뀔 수 있는 프리픽스를 가진 주소를 표현할 수 있었다. 사전 처리로 AAAA 영역 데이터를 재생성할 수 있었지만, 그렇게 하면 같은 의존성 정보가 외부 프로비저닝 시스템으로 옮겨갈 뿐이었다.

RFC 3363은 질의가 거쳐야 하는 경로에 초점을 맞췄다. 필요한 답들이 이미 캐시에 있지 않다면, N링크 A6 체인은 대략 N에 비례하는 시간이 걸린다고 추론했다. 각 하위 질의가 실패 확률을 지니므로, 실패 확률 역시 대략 N과 함께 증가했다. 이것들은 아키텍처적 추정이지 전역적 측정이 아니었다. 이 문서는 지연 시간 센서스를 발행하거나 보편적인 배수를 주장하지 않았다.

행정 경계는 질의 수만큼 중요했다. 가장 흥미로운 A6 구성 일부는 리프 영역 밖으로, 다른 조직이 통제하는 영역을 향했다. DNS는 그러한 포인터를 담을 수 있다. 문제는 유지 관리였다. 글루와 역방향 포인터에 대한 경험은, 완전한 복구를 한 운영자가 통제할 수 없는 조직 간 참조는 종종 나쁘게 노화된다는 것을 보여주었다.

따라서 체인은 모든 로컬 편집에서는 정확하면서도 전역적으로는 실패할 수 있었다. 호스트 관리자는 접미사를 유지했다. 공급자는 프리픽스를 공표했다. 제3자는 또 다른 위임을 관리했다. 리졸버는 상호 일관된 시간적 스냅샷이 필요했다. 오래된 캐시 하나만으로도, 어떤 레코드도 통상적으로 유효하지 않은 것은 아닌데도 한 관찰자가 다른 관찰자와 다른 주소를 조립할 수 있었다.

AAAA는 다른 트레이드오프를 선택했다. 전체 IPv6 주소가 하나의 리소스 레코드에 담겼다. 리넘버링은 더 많은 레코드 변경을 요구할 수 있었고, 자동화는 여전히 중요했다. 그러나 조회 의존성은 눈에 보이게 한정되어 있었다. RFC 3363은 RFC 1886을 표준 트랙에 두고 발전시키되, RFC 2874를 Experimental로 옮길 것을 권고했다. RFC 3596은 나중에 AAAA와 IP6.ARPA 모델을 규격화하여 통상적인 프로덕션 참조가 되었다.

역방향 트리는 두 번째 교정을 공급했다. RFC 2673은 RFC 1035 이후 처음의 새로운 DNS 레이블 유형인 이진 레이블을 도입했다. 이 메커니즘은 1비트 레이블들을 비트 문자열로 묶을 수 있었고, 역방향 매핑을 위한 기술적으로 압축된 형식을 대표했다. 배포는 더 가혹한 교훈을 가르쳤다: 새 레이블 형식을 지원하지 않는 서버는 이를 담은 질의를 형식이 잘못된 것으로 거부할 수 있었다.

RFC 3363은 16진수 텍스트 레이블이 당시 예상되던 역방향 위임 구조를 표현할 수 있다고 결론 내렸다. 이진 레이블 역시 Experimental로 옮겼다. 역방향 트리에서의 DNAME의 의도된 사용은 조각화된 A6와 함께 폐기 권고(deprecated)되었다. 역방향 트리 루트라는 별개의 문제는 범위 밖이었으며, 이미 RFC 3152에서 처리된 바 있었다.

이것은 뺄셈으로 수행된 표준화 작업이었다. 두 문서가 Proposed Standard에 이르렀지만, 배포 논의는 운영적 증거가 충분히 강해지기 전에 그 신규성이 호환성 면을 확대한다는 것을 드러냈다. 대응은 작업을 지우는 것이 아니었다. Experimental 상태는 선호되는 프로덕션 경로에서 제거하면서 연구용으로 작업을 보존했다.

그러나 이 상태 조치를 과대평가해서는 안 된다. 문서는 다른 문서의 공식 트랙을 변경할 수 있다. 그러나 리졸버 속으로 들어가 코드를 제거할 수는 없다. 영역을 다시 쓰거나, 캐시를 비우거나, 조직 간 포인터를 복구하거나, 어떤 운영자가 AAAA로 이전했다는 것을 증명할 수도 없다. 표준 상태, 구현 지원, 공표된 레코드, 실제 질의 결과는 여전히 별개의 사실들이다.

같은 분리가 AAAA가 승리 신화가 되는 것도 막는다. 하나의 전체 레코드는 직렬 주소 조립을 피하지만, 신선한 프로비저닝, 올바른 역방향 데이터, DNSSEC 검증, 도달 가능한 라우팅, 작동하는 서비스를 보장하지는 않는다. RFC 4472는 AAAA가 통상적인 표현이 된 이후에도 많은 IPv6 DNS 운영 문제들을 정리했다. 더 단순한 의존성 구조는 한 부류의 불확실성을 줄였을 뿐, 운영 자체를 폐지하지는 않았다.

RFC 3597은 유용한 인접 교훈을 더한다. DNS 소프트웨어는 프로토콜 확장이 항상 즉각적인 의미론적 이해를 요구하지 않도록 알려지지 않은 리소스 레코드 유형을 다루는 메커니즘이 필요하다. 그러나 알려지지 않은 유형의 일반적 처리와 새로운 레이블 구문에 대한 지원은 서로 다른 호환성 면이다. 서버는 낯선 레코드 데이터는 옮기면서도 낯선 이름 인코딩은 거부할 수 있다.

현재 IANA DNS 파라미터 레지스트리는 식별자와 상태를 기록한다. 그것은 내구성 있는 조정 산출물이다. 그러나 어떤 리졸버 버전이 한때 A6를 지원했는지, 어떤 영역이 그것을 공표했는지, 레코드가 강등 이후 얼마나 남아 있었는지, 사용자들이 무엇을 관찰했는지는 드러내지 않는다. 현재의 레지스트리 행은 역사적 배포 흔적이 아니다.

Lu Heng의 두 에세이가 공개된 분석 프레임을 제공한다. 「Minimum Initial Specification」은 공통 계층이 호환성에 필요한 결정론적 구조만을 담고, 이후의 채택은 코드를 실행하는 참여자들에게 맡겨야 한다고 주장한다. A6는 더 많은 동적 조합을 공유 해석 경로에 놓았고, AAAA는 더 많은 리넘버링 작업을 프로비저닝과 운영자에게 남겼다. 「On Reality Layers」는 표준 강등이 순간적인 운영 사건으로 오해되는 것을 막는다. 문서가 먼저 바뀌었다. 코드, 영역, 캐시, 결과는 서로 다른 시계로 바뀔 수 있었다.

역사적 교훈은 우아함이 의심스럽다는 것이 아니다. 조합 가능성(composability)은 신뢰성을 소비한다는 것이다. 구성 요소는 독립적으로 변경될 수 있을 때 가치 있다. 그러나 최종 답이 모든 구성 요소, 관리자, 질의가 동시에 사용 가능해야만 존재할 수 있다면, 그 같은 독립성이 위험이 된다.

RFC 3363은 규율 있는 후퇴를 수행했다. 아이디어를 실험으로 남겨두고, 프로덕션 권고를 좁혔으며, 실행 중인 시스템이 채택을 결정하게 하였다. 주소는 여전히 조각으로 조립될 수 있었다. 다만 프로덕션 DNS는 더 이상 모든 추가 조각이 공짜라고 가장할 필요가 없었다.

출처