요약

  • RFC 3397은 DHCP 옵션 119에 순서가 있는 DNS 도메인 검색 목록을 할당하면서 두 개의 재구성 규칙을 겹겹이 적용했다: RFC 3396이 먼저 옵션 조각들을 연결하고, 이어서 RFC 1035 포인터가 완성된 집합 안에서 이름을 재구성했다.
  • 검색 목록은 DNSSEC보다 앞서 작동했다. 적대적이지만 수용된 접미사가 짧은 이름을 다른 도메인으로 돌릴 수 있었고, 그 도메인의 레코드는 정당하게 서명되어 있었기에, 사용자가 의도한 적 없는 질문에 대한 진본 답변이 만들어졌다.

녹색 자물쇠는 결코 전부가 아니었다. 리졸버가 DNS 응답을 검증하기 훨씬 전에, 질문에 넣을 완전한 도메인 이름(FQDN)을 무엇으로 할지 결정하는 무언가가 있어야 했다. 사용자가myhost같은 짧은 이름을 입력하면, 빠진 접미사는 정책이었다. RFC 3397은 DHCP 서버에 그 정책을 공급하는 표준적인 방법을 주었다.

2002년 11월에 Standards Track으로 공표된 RFC 3397은 DHCP 도메인 검색 옵션을 정의하고 코드 119를 할당했다. 그 역할은 좁았다: 호스트명을 해석할 때 사용할 순서가 있는 DNS 도메인 목록을 구성하는 것. DNS와 다른 이름 체계 사이에서 선택하는 것은 아니었다. 이 구분은 중요했다. RFC 2937이 이름 서비스의 우선순위를 정하는 별개의 옵션을 정의했기 때문이다. 옵션 119는 DNS 내부의 접미사만을 다스렸다.

전송 형식은 공간을 아껴야 했다. 그Searchstring은 인쇄 가능한 도메인의 나열이 아니라 RFC 1035 라벨 형식의 DNS 이름들의 연결이었다. 반복되는 접미사는 앞서 등장한 위치를 가리키는 2옥텟 압축 포인터로 대체될 수 있었다. 두 검색 도메인이 모두apple.com.으로 끝난다면, 두 번째는 그 라벨들을 다시 실을 필요가 없었다.

포인터의 주소 공간은 국소적이고 정확했다. 오프셋 0은 옵션 코드와 길이 옥텟을 제외한 옵션 119 데이터의 시작을 뜻했다. 포인터는 DNS 리퍼럴도, 네트워크 주소도, 다른 패킷으로의 링크도 아니었다. 클라이언트가 해석하던 그 하나의 논리적 옵션 데이터 블록 안에서 뒤쪽을 가리켰다.

그 블록이 물리적으로 한곳에 존재하지 않을 수도 있었다. RFC 3397은 같이 공표된 RFC 3396을 적용해, 긴 값이 옵션 119의 여러 인스턴스로 나뉘어 도착할 수 있게 했다. 수신자는 먼저 요구된 집계 순서대로 모든 데이터 부분을 연결한다. 그 다음에야 RFC 1035 압축 포인터를 따를 수 있다. 포인터가 조각 경계를 넘는 것은 허용되었다. 좌표계가 개별 DHCP 필드가 아니라 완성된 집합이기 때문이다.

RFC의 예시는 이 계층 구조를 보여준다.eng.apple.com.뒤에marketing.apple.com.을 인코딩하고 바이트를 세 개의 옵션 인스턴스에 나눠 담았다. 두 번째 이름은C004로 끝났는데,apple.com.이 시작되는 집합 오프셋 4를 가리키는 포인터다. 조각을 도착 즉시 해석하면 그 주소는 무의미해진다. 재조립은 최적화가 아니라 이름 지정의 전제 조건이었다.

종료 규칙은 불완전한 바이트 스트림이 발명된 도메인이 되는 것을 막았다. 모든 검색 이름은 길이 0의 루트 라벨 또는 유효한 2옥텟 포인터에 도달해야 했다. 집합이 이름 중간에서 끝나며 어느 종료자도 없다면, 클라이언트는 그 부분 이름을 버려야 했다. 라벨을 대부분 갖고 있다는 것은 나머지를 추측할 허가가 아니었다.

해독된 뒤, 이 목록은 불완전한 사용자 입력이 DNS 질문이 되는 방식을 바꿨다. RFC 3397은 RFC 1535와 RFC 1536의 리졸버 보안 지침을 따랐다. 검색 목록은 호스트 이름에서 추론되지 않고 명시적이어야 했다. 점을 포함한 문자열은 먼저 완전한 이름으로 시도하고, 실패한 뒤에만 로컬 검색 도메인을 붙여 시도해야 했다. 점이 전혀 없는 문자열은 즉시 검색 접미사를 받을 수 있었다.

그 순서가 통제면을 드러냈다. 사용자는 리졸버가myhost.bigco.com을 시도할 것을 기대하며myhost를 입력할 수 있다. 악의적 DHCP 서버는 대신roguedomain.com을 설치해 그 기기가myhost.roguedomain.com을 물어보게 만들 수 있다. 리다이렉션은 권위 있는 DNS 서버가 답하기 전에, 검증 리졸버가 서명을 살펴보기 전에 일어났다.

RFC 3397의 가장 날카로운 문장은 DNSSEC가 이 공격을 막지 못한다는 것이었다. 악의 도메인은 자기 레코드를 발표하고 올바르게 서명할 수 있었다. DNSSEC는 반환된 데이터가myhost.roguedomain.com에 대해 진본임을 입증할 수 있었다. 그러나myhost.roguedomain.com이 사용자, 관리자 또는 애플리케이션이 의도한 이름임은 입증하지 못했다.

이것은 암호학적 실패가 아니었다. 권한의 분리였다. DHCP 수용이 검색 목록이 기기에 들어오는지를 다스렸다. 리졸버 정책이 어느 접미사를 시도할지 다스렸다. DNS는 그 결과 이름의 레코드를 공급했다. DNSSEC는 그 레코드를 인증했다. 애플리케이션이 주소로 무엇을 할지 결정했다. 마지막 단계의 증거가 첫 단계를 소급해서 정당화할 수는 없었다.

RFC 3397은 공격자가 정당하지 않은 DNS 서버 옵션을 공급하는 것보다 접미사 조작이 더 유익하다고 보았다. 공격자는 겉보기에 이상한 리졸버나 위조된 답변이 필요 없었다. 공격자가 통제하는 도메인의 평범한 권위 있는 인프라가 리다이렉트된 질의에 답할 수 있었다. 모든 DNSSEC 검사를 통과하면서 의미상의 목적지는 한 단계 이전에 바뀌어 있었다.

따라서 완화책은 파싱뿐 아니라 출처를 다뤘다. RFC 1536이 기술한 리졸버 동작을 구현하라. DHCP가 수동으로 구성된 DNS 매개변수를 덮어쓰게 하지 마라. 적절한 곳에서는 옵션 119를 수용하기 전에 DHCP 인증을 요구하라. 각 조치는 무단 정책의 한 통로를 줄였지만, 어느 것도 운영자가 모든 영수증을 ‘보안’ 같은 한 단어로 접을 수 있게 하지 않았다.

인증 자체에도 한계가 있었다. RFC 3118은 DHCP 메시지를 인증할 수 있지만, 유효한 DHCP 자격 증명이 증명하는 것은 메시지가 수용된 주체에게서 왔다는 것이지, 그 접미사가 특정 사용자의 의도와 일치한다는 것이 아니었다. 수동 우선순위가 증명하는 것은 어느 구성이 이겼는지이지, 애플리케이션이 그 이름을 사용했는지가 아니었다. 패킷 수신은 전달을 증명했지 수용이 아니었다. DNSSEC는 답변의 진본성을 증명했지 질의의 출처가 아니었다.

이 때문에 운영 증거는 사슬을 보존해야 한다. 짧은 입력에서 시작하라. 활성화된 수동 및 학습된 검색 목록과 그 순서·출처를 기록하라. 옵션 119의 원시 인스턴스들과 RFC 3396 집합을 보존하라. 해독된 이름, 포인터 대상, 무효 이름 판정을 기록하라. 그런 다음 각 후보 FQDN, 실제 전송된 질의, DNSSEC 결과, 반환된 주소, 애플리케이션 연결을 보존하라.

이 계층들 없이는 성공한 조회가 모호하다. 옵션 119를 담은 캡처는 클라이언트가 그것을 수용했다는 것을 보여주지 않는다. 해독된 목록은 어느 접미사가 시도되었는지 보여주지 않는다. DNS 질의는 사용자의 원래 텍스트를 드러내지 않는다. 검증된 답변은 그 질의가 왜 그렇게 구성되었는지 보여주지 않는다. 그리고 주소를 담은 애플리케이션 로그에는 이름이 아예 남아 있지 않을 수 있다.

IANA BOOTP/DHCP 매개변수 레지스트리는 코드 119를 기록하며, 이는 조율된 할당을 확립하지 배포나 정확성을 확립하지 않는다. RFC Editor의 현재 검색은 RFC 3397에 대한 일치하는 정오표를 보고하지 않는다. 어느 사실도 구현이 조각을 압축 해제 전에 연결하는지, 미완성 이름을 거절하는지, 수동 우선순위를 존중하는지, 선택된 접미사를 기록하는지를 보여주는 실시간 증거가 아니다.

Lu Heng의 최소 초기 명세(Minimum Initial Specification) 원리는 이 문서의 절약을 설명한다. RFC 3397은 가장 작은 공유 전송 및 해독 계약을 정의했다: DNS 전용 목록 하나, 집합 기준 포인터 공간 하나, 명시적 종료. 로컬 인터페이스, 저장소, 리졸버 내부는 구현에 맡겼다. 조율은 서로 독립적인 기기들이 동의해야 하는 경계에서 일어났다.

Running-Code Primacy가 더 어려운 시험을 공급한다. 클라이언트에 압축 포인터가 절단면을 넘는, 분할된 옵션 인스턴스를 먹여라. 정확한 집합, 해독 순서, 거절된 비정상 꼬리, 후보 이름 순서, 내보낸 DNS 패킷을 관찰하라. 수동 우선순위와 DHCP 인증 상태를 바꿔라. 파서 시험만으로는 연결이 어디로 가는지를 결정하는 동작을 증명할 수 없다.

따라서 RFC 3397은 단순히 하나의 옵션이 아니라 하나의 질문의 역사다. 이것은 진본성이 다른 계층이 그 객체를 선택한 뒤에 이름 붙은 객체에 붙는다는 것을 보여준다. 서명된 답변은 완전히 참일 수 있다. 답되지 않은 질문은, 참이 되도록 허락된 이름을 누가 골랐는가이다.

출처