RFC 3123: DNS 프리픽스 목록은 접근 정책이 아니었다

요약

RFC 3123은 부정 비트를 포함하여 IPv4와 IPv6 프리픽스에 대한 순서가 있는 DNS 표현을 정의했지만, 부정, 빈 목록, 여러 레코드, 익숙하지 않은 주소 패밀리가 무엇을 의미하는지는 각 애플리케이션이 정의하도록 요구했다.
유효하거나 인증된 APL 레코드는 특정 바이트가 DNS 이름 아래 게시되었다는 근거였다. 이는 프리픽스 통제, 정책 권한, 접근 제어 시스템에의 설치, 강제 집행, 또는 성공적인 서비스 결과를 증명하지 못했다.

DNS는 목록을 받았지만 그 목적을 받지는 않았다

2001년 무렵, DNS는 오래전부터 호스트 이름만의 전화번호부가 아니었다. 자원 레코드 기계는 메일 경로, 네임서버 위임, 기타 인프라 정보를 게시할 수 있었다. RFC 1101은 조직 네트워크를 기술하는 방식을 제안한 바 있었고, 오래된 BIND 설치 환경은 영역 데이터 접근을 제한하기 위한 주소 범위의 약한 출처로 TXT 레코드를 사용하기도 했다. 이러한 실무들은 같은 문제를 공유했다. 주소 범위는 유용한 데이터였지만, 그 표현과 운영상 의미가 종종 얽혀 있었다.

RFC 3123은 이 둘을 분리했다. 2001년 6월 실험적(Experimental) 문서로 공개된 이 문서는 자원 레코드 유형 42를 APL, 즉 Address Prefix List에 할당했다. 각 항목은 주소 패밀리 식별자, 프리픽스 길이, 부정 플래그, 길이, 주소 패밀리 의존적인 바이트 문자열을 담았다. 패밀리 1과 2는 IPv4와 IPv6를 뜻했고, 같은 레코드가 둘 다를 담을 수 있었다.

이것은 정책 헌법이 아니라 작은 공용 언어였다. 문서 자체가 이례적으로 명확하게 그렇게 말했다. APL은 목록에 대한 어떤 구체적 의미도 정의하지 않으면서 프레임워크를 정의했다. 가능한 용도로는 조직의 주소 범위 게시, 클래스리스 역방향 DNS 영역 기술, 접근 제어용 자료 제공이 포함되었다. 그러나 그 예시들 중 어느 것도 애플리케이션을 표준화하지 않았고, 어떤 구현의 존재도 암시하지 않았다.

이 절제가 중요하다. DNS 소유자 이름, 유형 코드, 잘 구성된 페이로드는 표현이 어디에서 발견되었는지 확립할 수 있다. 그러나 연산자를 묶을 자격이 있는 주체, 애플리케이션이 적용하는 결정 규칙, 강제 지점이 실제로 취한 조치는 식별할 수 없다.

느낌표는 판단 이전에 문법이었다

APL의 와이어 포맷에는 N이라는 한 비트 필드가 포함되어 있었다. 영역 파일 문법에서 이는 항목이!로 시작하는지를 기록했다. 그 표식을 곧바로 "거부", "제외", "승인되지 않음"으로 읽고 싶은 유혹이 있다. 그러나 RFC 3123은 그 지름길을 거부했다. 부정된 항목의 정확한 의미론은 애플리케이션 사양이 명시해야 했다.

경계에서도 마찬가지였다. 빈 RDATA는 합법적이고 빈 목록을 나타냈지만, 빈 목록이 무엇을 하는지는 애플리케이션이 밝혀야 했다. 아무도 아님을 뜻하는가, 모두를 뜻하는가, 의견 없음인가, 다른 규칙을 상속하는가, 아니면 안전하게 실패(fail closed)하는가? 레코드 자체는 답할 수 없었다. RRset은 여러 APL 레코드를 담을 수 있었지만, 그 결합 해석 역시 다시 애플리케이션의 결정이었다.

주소 패밀리의 진화조차 추측이 아니라 명시적으로 남겨졌다. 애플리케이션은 기대하는 패밀리를 명명하고, 그 외의 또는 미지의 패밀리를 어떻게 다루는지 정의해야 했다. 무시하기, 레코드를 거부하기, 미래 구현을 위해 보존하기는 서로 다른 운영 선택이다. 필드를 이해하는 파서가 이들 중 하나를 선택했다는 뜻은 아니다.

따라서 RFC 3123은 중요한 경계를 지켰다. 공유 문법은 상호운용 가능한 독자가 로컬에서 검증할 수 있는 것만 담아야 한다. 미래의 정책을 문장부호 하나에 몰래 실어서는 안 된다.

순서와 반복은 잡음이 아니라 근거였다

DNS 서버와 리졸버에는 APL 데이터를 정리하지 말라는 지시가 내려졌다. 중복 항목은 허용되었고 병합해서는 안 되었다. 항목은 순서를 유지해야 했고, 재배열하거나 집계해서는 안 되었다. 목록을 수학적 집합으로 가정하면 이 요구는 비효율로만 보인다. 그러나 RFC 3123은 그런 가정을 하지 않았다. 미래의 애플리케이션이 순서나 반복에 의미를 부여할 수 있었기 때문이다.

이 규칙은 그것을 이해한다고 가장하지 않으면서 게시자의 진술을 보존했다. 서버는 순서가 있는 표현을 전송했고, 애플리케이션이 그 표현을 해석했다. 중간자가 두 항목을 병합하거나 정렬하거나 인접 프리픽스를 결합하면, 그 중간자가 의미를 알도록 허가받은 적 없는 정책을 바꿀 수 있었다.

다만 바이트 수준에서 RFC 3123은 한 종류의 정규화를 요구했다. 뒤에 붙는 0 옥텟은 프리픽스 정보를 담지 않으므로 주소 부분에서 생략해야 했다. 이는 의미적으로 동등한 IPv4 또는 IPv6 프리픽스에 단일 와이어 인코딩을 부여하는 것으로, 당시 인용된 DNSSEC 정규화 모델에 중요했다. 정준 바이트는 비교와 서명의 문제를 해결한다. 그러나 서명된 목록의 의미를 해결하지는 못한다.

여기에 결정적 표현과 재량적 결과의 구분이 있다. 정규화는 두 검증자가 어떤 데이터가 서명되었는지에 동의하게 해 준다. 그러나 어느 검증자에게도 그 항목이 접근을 허가하는지, 할당을 공고하는지, 역방향 영역을 기술하는지, 아무 효과도 없는지를 말해 주지 않는다.

보안은 진술을 보호할 수는 있지만 완성할 수는 없었다

RFC 3123은 DNS 정보가 참조된 DNSSEC 또는 TSIG 기법으로 보호되지 않는 한 안전하지 않은 것으로 간주해야 한다고 경고했다. 또한 토폴로지 게시가 유용한 정보를 노출할 수 있고, APL 데이터로 접근 제어 목록을 구성하는 행위 자체가 보안을 해칠 수 있다고 경고했다.

이 두 경고는 서로 다른 방향을 가리킨다. 출처와 무결성이 중요한 이유는 프리픽스 목록을 바꾸는 공격자가 의존하는 애플리케이션이 보는 것을 바꿀 수 있기 때문이다. 그러나 진위성은 권한 부여가 아니다. DNSSEC는 데이터가 서명된 DNS 체인을 거쳤고 변경되지 않았음을 보여 줄 수 있다. TSIG는 구성된 당사자들 사이의 DNS 메시지나 트랜잭션을 인증할 수 있다. 그러나 어느 쪽도 영역 운영자가 방화벽 규칙을 설정할 권한이 있었는지, 애플리케이션이 현재 레코드를 사용했는지, 패킷이 나중에 통과했는지를 결정하지 않는다.

운영 체인이 성립하려면 더 많은 접수 증명이 필요하다. 조회된 소유자 이름과 RRset, 검증 상태와 시각, 애플리케이션 사양과 버전, 그 애플리케이션을 선택한 로컬 구성, 컴파일된 정책, 강제 지점의 확인 응답, 관찰된 트래픽 결과가 그렇다. 첫 레코드에서 마지막 결과로 건너뛰면 게시된 데이터가 상상 속 통제로 변한다.

역사적 유혹은 이해할 수 있었다. DNS는 이미 분산되어 있고 캐시되며 행정적으로 위임되어 있었다. 프리픽스 자료를 게시하기 위해 이를 재사용하는 것은 경제적이었다. 그러나 진술의 배포는 결정 권한의 배포가 아니다. 영역 관리자는 바이트를 게시할 수 있다. 그 바이트가 자기 시스템을 지배하는지는 여전히 다른 운영자가 결정한다.

유형 42는 배포를 증명하지 못했다

RFC의 예시는 생생하다. 조직의 주소 범위, 클래스리스 역방향 영역, 영역 전송 제한, 멀티캐스트 범위가 그것이다. 이들은 예시 이름 아래의 설명적 레코드일 뿐이다. 문서는 이들이 해당 애플리케이션을 지정하지 않으며, APL 기반 애플리케이션이 존재했거나 존재할 것임을 암시하지 않는다고 명시적으로 말한다.

실험적(Experimental) 지위 역시 배포 접수 증명을 갖지 못한다. 이는 2001년 당시 문서의 표준 범주를 기록한 것일 뿐이다. 나중에 공개된 RFC 3597은 DNS 구현이 미지의 자원 레코드 유형을 어떻게 다루는지를 기술하여, 새 유형이 이를 이해하지 못하는 소프트웨어를 어떻게 통과할 수 있는지 설명하는 데 도움을 준다. 그러나 APL이 어떤 특정 네트워크에서 사용되었거나, 무시되었거나, 성공했음을 보여 주지는 않는다. 이후 RFC 4034의 DNSSEC 규칙 역시 서명된 레코드 처리를 명확히 할 뿐 APL에 보편적 의미론을 부여하지 않는다.

책임 있는 역사는 따라서 출처가 확립하는 지점에서 멈춘다. RFC 3123은 순서, 중복, 패밀리 식별, 압축된 프리픽스 바이트를 신중히 보존하는 확장 가능한 컨테이너를 만들었다. 애플리케이션 의미는 그 컨테이너 바깥에 남겨 두었다. 채택, 운영 가치, 실패에 대한 어떤 주장이든 별도의 구현 또는 배포 근거가 필요하다.

남는 교훈은 좁은 공통 계층이었다

APL은 입헌적 절제의 축소 연습으로 읽힐 수 있다. 공통 포맷은 목록을 손상 없이 교환할 만큼만 지정했다. 미래의 애플리케이션은 자신만의 소유자 이름 규약, 빈 목록 동작, RRset 결합, 패밀리 정책, 부정 의미론을 자유롭게 정의할 수 있었다. 운영자 역시 그 애플리케이션을 채택하거나 채택하지 않을 자유를 유지했다.

이 설계는 위험을 없애지 않았다. 대신 위험의 위치를 보이게 했다. 레코드는 진위적이면서도 낡았을 수 있다. 애플리케이션은 사양이 있으면서도 로컬에서 잘못 구성되었을 수 있다. 컴파일된 ACL은 설치되었으면서도 잘못된 인터페이스에 붙어 있을 수 있다. 강제 지점이 이를 수락하는 동안 트래픽이 다른 경로를 따를 수 있다. 각 전환마다 고유한 관찰이 필요했다.

가장 쉬운 역사적 오류는 모든 단계가 같은 프리픽스를 다루기 때문에 체인을 하나로 뭉개는 것이다. DNS 속의 프리픽스, 애플리케이션 모델 속의 프리픽스, ACL 속의 프리픽스, 패킷이 일치시키는 프리픽스, 인시던트 보고서에서 언급되는 프리픽스는 서로 다른 권한과 시간에 속하면서 텍스트상으로는 동일할 수 있다.

RFC 3123의 조용한 성과는 DNS에게 네트워크를 지배하게 만든 것이 아니었다. DNS에게 주소 프리픽스 자료를 운반할 정확한 방법을 주면서, 레코드 자체가 지배자가 아님을 인정한 것이다.

프리픽스 목록은 아직 접근 정책이 아니었다: RFC 3123

왜 중요한가

요약

DNS는 목록을 받았지만 그 목적을 받지는 않았다

느낌표는 판단 이전에 문법이었다

순서와 반복은 잡음이 아니라 근거였다

보안은 진술을 보호할 수는 있지만 완성할 수는 없었다

유형 42는 배포를 증명하지 못했다

남는 교훈은 좁은 공통 계층이었다

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

Strategic Circle 브리핑

Leadership Alliance 브리핑

요약

DNS는 목록을 받았지만 그 목적을 받지는 않았다

느낌표는 판단 이전에 문법이었다

순서와 반복은 잡음이 아니라 근거였다

보안은 진술을 보호할 수는 있지만 완성할 수는 없었다

유형 42는 배포를 증명하지 못했다

남는 교훈은 좁은 공통 계층이었다

출처

프로필 심층 컨텍스트

Strategic Circle

Leadership Alliance

추천 읽을거리