요약

  • RFC 5855는 IPv4와 IPv6 리버스 존에 전용 네임서버 네임스페이스와 부모 존 글루 레코드를 부여하여, 두 서비스를 서로 다른 서버 세트로 운영할 수 있게 했습니다.
  • 이 RFC는 그 분리를 요구하지는 않습니다. 운영자 선택은 IANA 기능에 맡겨져 있습니다. 이름이 다르다는 것만으로 경로, 사이트 또는 장애 노출이 다르다는 것을 증명하지 못합니다.

리버스 조회는 주소에서 시작하지만, 리졸버가 해당 리버스 존의 권한 있는 네임서버를 찾기 전까지는 주소에 연결된 이름에 도달할 수 없습니다. 이 발견 단계에는 자체적인 의존성이 있습니다. 리졸버가 존의 네임서버 주소를 찾지 못하면, PTR 레코드를 요청하기도 전에 실패할 수 있습니다.

RFC 5855,Nameservers for IPv4 and IPv6 Reverse Zones의 배후에는 바로 이 실용적 문제가 있었습니다. 2010년 5월에 Best Current Practice로 발표된 이 RFC는 Joe Abley와 Terry Manderson이 공동 집필했습니다. 이 RFC는 작성 당시 존재하던 구성을 기록하고 있습니다. 루트 서버의 일부가 IN-ADDR.ARPA를 서비스했고, IP6.ARPA는 APNIC, ARIN, ICANN, LACNIC, RIPE NCC가 운영하는 시스템이 서비스하고 있었습니다.

이 제안은 각 리버스 존에 자체적인 안정적인 네임서버 네임스페이스를 부여했습니다. IPv4 서버는 IN-ADDR-SERVERS.ARPA 아래에, IPv6 서버는 IP6-SERVERS.ARPA 아래에 이름이 지정됩니다. 부모인 ARPA 존은 이 이름들에 도달하는 데 필요한 IPv4와 IPv6 글루 레코드를 갖게 됩니다. 이렇게 하면 리졸버의 첫 단계가 부모 referral을 이미 제공하는 존 안에서 이루어지며, IPv6 리버스 서버의 주소를 다른 재귀 조회를 통해 발견해야 하는 상황을 피할 수 있습니다.

이것이 중요한 이유는, 네임서버 referral은 리졸버가 그 경로를 따라 계속 나아갈 수 있을 때만 유용하기 때문입니다. RFC의 쿼리 예시는 이전의 IP6.ARPA 위임이 추가 구역(additional-section) 글루 없이 도착할 수 있었음을 보여줍니다. 그 경우 리졸버는 리버스 존을 조회하기 전에 나열된 네임서버 중 하나를 먼저 찾아야 했습니다. RFC 5855의 전용 이름과 ARPA 글루는 이 의존성을 명시적으로 만들고 운영하기 쉽게 합니다. 변경 사항은 서류상으로는 작지만, 모든 리버스 조회가 통과해야 하는 경로에 영향을 미칩니다.

이 RFC는 인코딩 비용도 운영적 세부 사항으로 다루었습니다. 부록은 과거의 IPv6 리버스 존 서버 이름과 제안된 이름을 비교합니다. 인코딩된 NS 이름 레이블은 전자의 예시에서 74바이트, 후자에서 39바이트를 차지합니다. 이는 와이어 형식 비교일 뿐, 지연 시간이나 실패한 조회의 실측 감소가 아닙니다. 이 설계는 자주 조회되는 referral에서 반복되는 접미사를 DNS가 압축할 수 있게 하면서, 서버 주소 경로를 더 명확하게 만듭니다.

이 이름들은 또한 더 강한 분리를 허용하기 위한 것이었습니다. RFC 5855는 IPv4와 IPv6 리버스 존을 서로 다른 두 네임서버 세트에 위임할 수 있다고 하며, 이는 한 주소 계열의 장애가 다른 계열의 조회에 피해를 주는 것을 방지하는 데 도움이 됩니다. 그러나 이 RFC는 그 세트들이 서로 다른 운영자, 사이트, 트랜짓 제공자 또는 상위 경로를 사용하도록 요구하지는 않습니다. RFC는 오히려 네임서버 네임스페이스와 그에 대응하는 리버스 존이 각 주소 계열 내에서 운명을 공유할 수 있다고까지 명시합니다. 별도의 레이블은 시스템이 활용할 수 있는 선택이지, 두 개의 물리적 또는 라우팅 장애가 서로 독립적으로 유지될 것이라는 보장이 아닙니다.

이 문서는 남은 선택권을 누가 가지고 있는지에 대해 이례적으로 직설적입니다. IANA 섹션은 새로운 위임과 글루를 기록합니다. 운영자의 선택은 RFC의 범위 밖이며,IETF–ICANN 양해각서에 따른 IANA 기능이라고 명시합니다. 따라서 RFC 5855는 기술적 표면과 인계 지점을 지정할 뿐, 표준의 설계를 각 서버를 누가 운영했는지 또는 그 서버들이 실제로 얼마나 독립적이었는지에 대한 주장으로 바꾸지 않습니다.

Manderson의 역할은 이 경계의 양쪽에서 모두 문서화되어 있습니다. 그는 이 RFC를 공동 집필했고, IETF Datatracker는 자신의 RFC 목록에 이 문서를 포함하고 있습니다. 이후의RSSAC 역사 문서는 그가 2013년에 ICANN의 DNS 운영 부서 관리를 맡았고, 2014년에 그 팀이 ICANN IT로 이동하여 DNS Engineering이 되었다고 기록합니다.ICANN 인터뷰는 그를 이 부서의 디렉터로 지목합니다. 이 기록들은 운영 경험을 입증할 뿐, Manderson이 혼자서 RFC의 운영자를 설계하거나 선택하거나 배치했다는 것을 입증하지는 않습니다.

이 한계가 오히려 이 RFC를 근거로서 더 유용하게 만듭니다. 이 RFC는 프로토콜이 이름을 지정할 수 있는 것과 운영 구성이 결정해야 하는 것을 분리합니다. IPv4와 IPv6 리버스 DNS가 실제로 독립적으로 실패하는지 알아내려면, 엔지니어는 표준 속의 두 접미사가 아니라 실제 NS 세트, 글루, 호스팅, 경로 및 응답 동작이 필요합니다.

출처