요약

  • RFC 1535는 루트가 붙지 않은 이름을 순차 검색의 재료로 취급하는 리졸버 클라이언트를 기록했다.Machine.Tech.ACES.COM의 사용자가UnivHost.University.EDU를 입력하면, 의도된 루트 형태의 이름이 시도되기 전에 세 개의 접미 부착 후보가 먼저 발생할 수 있었다.
  • 일단EDU.COM이 존재하여 자기 분기 아래에서 응답할 수 있게 되면 검색이 거기서 종료될 수 있었다. 이 결함은 단순한 와일드카드가 아니었다. 암묵적 완성이 검색 조직이 로컬에서 관리하는 네임스페이스 너머까지 확장된 것이다.
  • 제안된 교정은 암묵적 검색을 좁히고, 점이 포함된 이름을 루트 기준으로 먼저 시도하며, 추가적인 로컬 대안은 명시적으로 구성하도록 요구함으로써 유용한 약어를 보존했다. RFC 1535는 Informational 문서였으며, 배포 규모, 관측된 침해 사건, 현재 리졸버 동작 또는 인증된 엔드포인트 신원을 증명하지 않는다.

토큰 하나, 질의 네 개

사용자는 화면에 보이는 토큰 하나를 입력했다.RFC 1535가 기술한 리졸버는 이를 DNS 질의 네 개로 바꿀 수 있었다.

이 메모에서 검색을 수행하는 기계는Machine.Tech.ACES.COM이었다. 사용자는 마지막 루트 점 없이UnivHost.University.EDU를 입력했다. BSD BIND 계열의 검색 휴리스틱은 다음 순서로 시도할 수 있었다:

  1. UnivHost.University.EDU.Tech.ACES.COM.
  2. UnivHost.University.EDU.ACES.COM.
  3. UnivHost.University.EDU.COM.
  4. UnivHost.University.EDU.

처음 두 후보는 여전히 로컬 조직과 연관된 이름 아래에 있었다. 세 번째는 아니었다. 세 번째는.COM의 별도 등록 가능 분기인EDU.COM.아래에 있었다. 그러나 리졸버는 사용자의 입력 표기와 일치하는 루트 형태를 묻는 네 번째 질의에 앞서 이를 먼저 시도했다.

이 순서가 이야기의 핵심이다. 입력된 문자열만 담고 있는 로그는 사용자가 하나의 이름을 물었다고 기록할 것이다. 성공한 DNS 교환만 담고 있는 패킷 캡처는 리졸버가 다른 이름을 물었다고 기록할 것이다. 두 기록 모두 정확하지만 어느 쪽도 그 판단을 설명하지 못한다. 빠져 있는 것은 후보 생성기다: 그 검색 목록, 순서, 경계, 중지 규칙.

RFC 1535의 Datatracker 기록은 이 메모를 식별하며,RFC Editor 기록은 1993년 10월 Informational 지위를 보존한다.보관된 텍스트는 바이트 단위 교차 검증을 제공하고,정오표 표면은 수정 사항을 별도로 기록한다. 그러나 이 문서적 사실들 중 어느 것도 얼마나 많은 기계가 이 휴리스틱을 따랐는지, 현재의 리졸버가 어떻게 동작하는지 알려주지 않는다.

마지막 점은 범위 지시였다

DNS 이름은 로컬 맥락에 상대적으로 쓰일 수도 있고 글로벌 트리에 뿌리 내릴 수도 있다. 메모에서 논의된 관례에서, 끝의 점은 절대적인 정규화된 도메인 이름, 즉UnivHost.University.EDU.를 표시했다. 그 점이 없으면 같은 보이는 라벨들이 완성 대상인 부분 이름으로 취급될 수 있었다.

그 점은 목적지를 인증하지 않았다. 호스트를 누가 운영하는지, 응답이 최신인지, 애플리케이션이 안전하게 연결할지 증명하지 않았다. 더 좁은 통문법적 주장을 만들었을 뿐이다: 이 이름을 검색 기점에 상대적으로 해석하는 것을 멈추고 DNS 루트에서 시작하라.

이 구분은 보안 보고보다 앞선 것이었다.RFC 1034— 그지위 기록은 STD 13에 속한다 — 은 기점 또는 검색 목록에 대해 완성되는 상대 이름을 기술했다. 또한 사용자 인터페이스 해석이 구현체마다 달랐다는 점도 인정했다.RFC 1035와 그문서 기록은 짝을 이루는 리졸버, 메시지, 리소스 레코드 맥락을 제공한다. 이들은 기술적 어휘를 정의할 뿐, 이후 모든 인터페이스가 같은 검색 동작을 사용했다는 것을 증명하지 않는다.

따라서 RFC 1535에서 위험한 단계는 상대 이름이 존재했다는 사실이 아니었다. 상대 이름은 알려진 맥락 안에서 유용하다. 위험한 것은 소프트웨어가 검색하는 호스트의 전체 도메인에서 검색 범위를 추론한 뒤, 그 행정적 의미를 이해하지 못하는 접미사들을 따라 내려갈 수 있다는 점이었다.

접미사가 공동 관리의 증거는 아니다

문자열 처리기의 관점에서Tech.ACES.COM,ACES.COM,COM은 점점 짧아지는 접미사들이다. 그러나 권한의 관점에서 이들은 하나의 조직에 속한 서로 교환 가능한 세 층위가 아니다.

ACES.COM을 책임지는 관리자가Tech.ACES.COM이나ACES.COM을 로컬 약어에 추가하는 검색 규칙을 합리적으로 통제할 수 있다. 그러나 그 책임은.COM아래의 모든 가능한 이름까지는 확장되지 않는다. 휴리스틱이ACES를 제거하는 순간, 다음 후보는 사용자에게 어떤 지시도 받지 않았고 로컬 관리자의 위임도 받지 않은 운영자의 분기로 들어간다.

그래서 "무언가가 응답할 때까지 라벨을 줄여 나가며 붙이는" 방식은 단순히 비효율적인 알고리즘이 아니었다. 그것은 조용히 해석 권한을 재배분했다. 검색 조직이 맥락을 공급했지만, 무관한 공개 등록자가 첫 번째 성공한 완성을 공급할 수 있었다.

RFC 1535 기록은 이 문제를 널리 배포된 DNS 소프트웨어의 보안 문제로 부른다. 그 제목은 역사적으로 중요하지만, 측정된 설치 기반 보고서는 아니다. 한정된 사실은 저자들이 이 동작을 문서화하고 교정을 제안했다는 것이다. 그 제목을 오늘날의 수치로 바꿔서는 안 된다.

EDU.COM이 권한 이동을 보이게 만들었다

메모는EDU.COM이 등록되었고, 그 아래의 와일드카드 CNAME이something.edu.com형태의 이름에 대한 요청을 하나의 대상으로 보낼 수 있다고 보고했다. 이는harvard.edu.com으로 효과를 예시했다.

위의 후보 순서에서 사용자는edu.com을 입력하지 않았다. 리졸버가 검색하면서 그 접미 조합을 만들어낸 것이다. 세 번째 질의가 리소스 레코드를 반환하면, 중지 조건이 의도된 네 번째 루트 질의가 전송되는 것을 막을 수 있었다. 성공한 DNS 응답은 단순히 데이터를 공급한 것이 아니라, 원래 토큰의 어느 해석이 살아남는지를 선택했다.

와일드카드는 그 분기의 도달 범위를 증폭했지만 결함의 전부는 아니었다. 특정 레코드 하나로도 검색을 종료시킬 수 있었다. 더 깊은 실패는 로컬 권한 밖에서 암묵적으로 생성된 후보가 그럴듯한 루트 해석보다 앞서 경쟁하도록 허용한 것이다.

또한 이 예시는 탈취된 비밀번호나 완성된 연결을 증명하지 않는다. DNS 응답은 하나의 영수증일 뿐이다. TCP 연결, 인증서나 다른 엔드포인트 인증, 애플리케이션 프롬프트, 제출된 자격 증명, 사용자에게 보이는 결과는 서로 다른 영수증이다. RFC 1535는 사용자가 잘못된 곳으로 향할 수 있다고 경고했고 그렇게 일어날 수 있는 경로를 드러냈다. 그 결과로 생긴 사건들의 전수 조사를 제공하지는 않았다.

역사적인EDU.COM구성을 현재의 도메인에 투영해서는 안 된다. 이 글의 근거 경계는 출처의 1993년 보고에서 끝난다.

검색 순서는 실행 가능한 정책이었다

검색 목록은 종종 편의 설정으로 제시된다. 그러나 운영적으로 그것은 최소 네 가지 결정을 포함하는 프로그램이다:

  • 어떤 입력이 확장 대상인가;
  • 어떤 접미사가 붙을 수 있는가;
  • 어떤 순서로 후보가 시도되는가;
  • 어떤 응답이 연쇄를 종료하는가.

하나만 바꿔도 같은 사용자 토큰이 다르게 해석될 수 있다. 따라서 순서 없는 접미사 집합을 보여주는 구성 화면은 불완전한 증거다. 순서가 중요하다. 마찬가지로 부정 응답이 검색을 진행시키는지, 어떤 리소스 레코드든 중지에 충분한지, 캐시가 후보를 만족할 수 있는지, 루트 형태가 로컬 대안보다 먼저 시도되는지도 중요하다.

RFC 1123— 그호스트 요구사항 지위 기록과 함께 — 은 약어 기능을 선택 사항으로 취급했다. 완전한 이름을 입력하기 위한 관례를 요구하면서, 사용자가 입력한 이름에서 완전한 도메인 이름으로의 변환이 정확히 한 번, 적절한 맥락에서 일어나야 한다고 했다. 또한 관리자가 검색 목록을 비활성화할 수 있도록 허용했다. 이 점들이 중요한 이유는, 그렇지 않으면 여러 층이 같은 토큰을 확장할 수 있기 때문이다: 애플리케이션이 접미사를 붙일 수 있고, 라이브러리가 다시 검색할 수 있으며, 다운스트림 서비스가 결과를 재해석할 수 있다.

RFC 1123은 루트 트래픽에 대해 다른 제약을 두었다: 호스트는 부정 캐싱을 사용하거나, 비로컬 질의를 보내기 전 최소한의 내부 점 개수를 요구해야 했다. 그 규칙은 질의 부하를 제한했을 뿐, 사용자의 이름을 해석할 권리가 누구에게 있는지는 결정하지 않았다. 따라서 이는 로컬 경계와 후보 순서 규칙을 대체하는 것이 아니라 보완하는 것이었다.

"정확히 한 번"은 성능 지시가 아니다. 그것은 소유권을 확립한다. 이름 붙은 하나의 구성 요소가 하나의 검사 가능한 정책 아래에서 완성을 수행해야 한다. 두 개의 숨은 구성 요소가 모두 재작성할 수 있다면, 최종 질의는 어느 층이 선택했는지 더 이상 드러내지 못한다.

교정은 암묵적 권한을 좁혔다

RFC 1535의 최소 교정은 로컬 관리 경계를 매개변수화하는 것이었다. 암묵적 검색은 그 경계를 넘은 이후에는 호스트의 도메인을 계속 줄여 나가서는 안 되었다. 조직은 사실상 "이 접미사들은 내가 완성할 수 있다; 그 너머는 내 대신 후보를 만들지 마라"라고 말할 수 있었다.

메모는 BIND 4.9.2와 연관된 더 엄격한 동작도 기술했다. 암묵적 검색은 좁은 패턴으로 축소되었다: 점점 짧아지는 모든 접미사를 따라가는 대신 적절한 로컬 형태와 루트 형태를 시도한다. 점을 포함한 이름은 루트 기준으로 먼저 시도되어야 했다.

마지막 규칙은 과장하기 쉽다. 모든 애플리케이션에서 점이 있는 토큰이 완전하다고 명령한 것이 아니다. 조직들이 자기 네임스페이스 안에서 다단 약어를 사용하기도 했다. 변화는 우선순위와 권한의 문제였다: 완전해 보이는 점 이름에 루트 해석을 먼저 주고, 추가 대안은 명시적으로 이름을 붙이도록 요구하는 것이다.

명시적 구성이 오류를 불가능하게 하지는 않았다. 관리자는 잘못된 접미사나 안전하지 않은 순서를 구성할 수 있다. 그러나 그것은 책임 표면을 바꾸었다. 보편적인 숨은 휴리스틱이 로컬의, 검사 가능한 결정이 된 것이다. 구성은 검토되고, 버전 관리되고, 비활성화되고, 조직이 실제 관리하는 존으로 제한될 수 있었다.

편의는 실재했다 — 그리고 그 외부 효과도 그랬다

검색 목록이 존재한 이유는 유용했기 때문이다. 캠퍼스나 회사 안의 사람들은 짧은 서비스 이름을 입력할 수 있었다. 애플리케이션들은 글로벌로 보이는 이름이 일상화되기 전에 형성된 습관을 유지할 수 있었다. 모든 약어를 제거하는 것은 실제 마찰을 초래했을 것이다.

이득은 로컬 사용자에게 즉시 나타났다: 더 적은 입력과 익숙한 이름. 비용은 나중에, 그리고 종종 다른 곳에서 나타났다. 보안 팀은 예상치 못한 엔드포인트로의 연결을 조사할 수 있다. 외부 관리자는 자기 존을 향해 의도된 적 없는 트래픽을 받을 수 있다. 애플리케이션 소유자는 시작 문자열이 옳아 보이는 인증 사건에 직면할 수 있다. 이득과 비용의 이 분리는 확장적인 기본값을 선호하게 만든다.

RFC 1535의 수리가 주목받는 이유는 편의와 안전을 절대물로 선택하지 않았기 때문이다. 그것은 선택을 재배치했다. 로컬에서 의도된 약어는 남을 수 있었지만 그 접미사들은 명시적이어야 했다. 루트 기준의 점 이름은 우선권을 받았다. 리졸버가 공개 접미사를 탐색할 자유는 회수되었다.

이것은 Lu Heng의Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption의 최소 계약 규율과 닮았다: 공유 규칙을 좁게 유지하고, 로컬 변이는 로컬에 남기며, 미래의 선택을 조용히 보편화하는 대신 보이게 만든다. 이는 사후에 적용된 편집적 렌즈이며, RFC 저자들의 사적 의도에 대한 증거가 아니다.

성공한 응답은 의도된 신원이 아니었다

리졸버에는 중지 조건이 필요했다. 리소스 레코드는 "하나의 후보가 존재한다"고 말해 주었기 때문에 운영적으로 유용했다. 그러나 존재는 의도가 아니다.

추적 결과UnivHost.University.EDU.COM.이 CNAME을 반환했다고 가정해 보자. 그것은 그 시점에 그 후보에 대해 권위적이거나 캐시된 응답이 공급되었다는 것을 증명한다. 그것은 사용자가 그 후보를 의도했다는 것, 로컬 관리자가 그 생성을 승인했다는 것, 대상이 의도된 기관을 나타낸다는 것, 전송이 그곳에 도달했다는 것, 인증 검사가 통과했다는 것, 애플리케이션이 안전하게 완료되었다는 것을 증명하지 않는다.

Lu Heng의Running-Code Primacy가 여기서 유용한 이유는, RFC가 런타임 영수증이 아니라 조율과 진단의 산물이기 때문이다. 진짜 질문은 특정 구현체가 무엇을 생성했는지, 네트워크가 무엇을 관측했는지이다.현실 층위 규율은 입력된 토큰, 리졸버 정책, 후보 질의, DNS 응답, 선택된 엔드포인트, 애플리케이션 결과가 하나의 녹색 상태로 무너지는 것을 막는다.

가장 가까운 짝 문서들이 이 경계를 강화한다.RFC 1536— 별도의RFC Editor 기록으로 식별된다 — 은 트래픽, 재시도, 재귀, 캐싱과 관련된 구현 오류를 목록화했다.RFC 1537은 자체지위 기록과 함께 흔한 DNS 데이터 파일 실수를 다루었다. 이들은 운영 실패를 가독하게 만들려던 더 넓은 1993년 노력을 보여준다. 어느 쪽도 RFC 1535의 후보 생성 근거를 대체하지 못한다.

지속 가능한 산출물은 후보 대장이다

신뢰할 수 있는 리졸버 기록은 첫 번째 DNS 패킷 이전에 시작된다. 그것은 정확한 토큰(루트 점이 있었는지 포함), 호출한 애플리케이션, 검색을 사용하거나 우회하라는 요청, 리졸버 라이브러리와 그 구성 시점, 순서화된 접미사 목록, 로컬 관리 경계, 생성된 모든 후보, 검색을 진행시키거나 멈춘 규칙을 보존해야 한다.

각 후보에 대해 질의 시각, 전송, 응답 코드, 권위와 응답 데이터, 관련 CNAME, 결과가 캐시에서 왔는지를 보존해야 한다. 그런 다음 DNS 응답과는 별도로 선택된 정규 엔드포인트를 명명하고, 전송과 엔드포인트 인증을 기록하며, 애플리케이션 동작과 관측된 결과를 보존해야 한다.

비밀번호와 비밀 자료는 그 대장에 속하지 않는다. 한정된 지문, 목적지 신원, 승인 결과는 민감한 내용을 재현하지 않고 무슨 일이 있었는지 보여줄 수 있다.

RFC 1535의 오래된 교훈은 사용자가 문장부호 하나를 기억해야 한다는 것이 아니다. 보이지 않는 편의 층이 대안을 생성함으로써 권한을 획득할 수 있다는 것이다. 그 권한은 선언된 범위 안에서, 결정적 순서로, 검토 가능한 중지 조건과 함께, 사용자의 입력과 소프트웨어의 해석을 구분하는 근거가 있을 때만 정당하다.

출처