요약

  • IQUERY는 평소의 DNS 메시지를 뒤집었다. Answer 섹션에 리소스 레코드를 담고, 그 레코드에 일치하는 소유자 이름을 Question 섹션으로 반환하도록 서버에 요구했다.
  • DNS가 이름 트리를 따라 위임했지 임의의 레코드 값 기준으로 위임하지 않았기 때문에, 이 연산은 질의된 서버가 알고 있는 이름만 밝힐 수 있었다. 따라서 로컬 결과가 정확하더라도 전역적으로는 불완전할 수 있었다.
  • 전수 스캔, 보조 인덱스, 어색한 캐싱, 거대한 응답, 공개 위험이 그 불확실성을 비싸게 만들었고, IN-ADDR.ARPA 아래의 PTR은 주소 역방향 조회를 평범한 위임된 이름 질의로 전환했다.

질문은 답변 안에서 시작되었다

질문 칸은 비어 있지만 답변 칸에 이미A IN 10.1.0.52라고 적혀 있는 양식을 받는다고 상상해 보라. 발신자는 수신자에게 그 레코드가 답변이 될 수 있는 모든 질문을 재구성해 달라고 요구한다. 이것이 DNS IQUERY의 인상적인 와이어 문법이었다.

RFC 1035는 opcode 1, 빈 Question 섹션, Answer 섹션의 리소스 레코드 하나로 이루어진 요청을 규정했다. 레코드의 소유자 이름과 TTL은 중요하지 않았다. 알려지지 않은 소유자 자리에 짧은 루트 이름이 대신 놓일 수 있었다. 성공한 응답은 이 배치를 뒤집었다. 하나 이상의 QNAME, QTYPE, QCLASS 튜플이 Question 섹션에 나타나고, 제공된 레코드는 첫 번째 결과에 맞춰 조정되었다.

이 구조는 개념적 대칭을 드러냈다. 표준 질의는 도메인 이름으로 시작해 리소스를 요구한다. IQUERY는 리소스로 시작해 도메인 이름을 요구했다. 같은 DNS 봉투가 양방향을 모두 담을 수 있었다.

그러나 대칭은 메시지 안에만 존재했다. 메시지 뒤에 있는 분산 권한 안에는 존재하지 않았다. 이름은 리졸버를 위임을 따라 책임 영역으로 이끌 수 있었다. 임의의 주소, 메일 교환기, 하드웨어 설명 또는 다른 레코드 값은 그 값이 속할 수 있는 모든 영역으로 가는 대응하는 경로를 갖고 있지 않았다.

한계는 1983년에 기록되었다

초기 DNS 사양은 이 문제를 숨기지 않았다.RFC 882는 도메인 시스템이 호스트 주소나 다른 리소스 유형이 아니라 도메인 이름으로 조직되어 있기 때문에 역질의에 대해 완전성이나 유일성을 보장할 수 없다고 명시했다. 보장을 원하는 리졸버는 적절한 데이터를 가지고 있음이 알려진 서버가 필요하거나, 관심 도메인의 모든 서버에 물어야 했다.

이것은 초기 구현에 대한 경고 그 이상이다. 누락된 라우팅 규칙을 지적한다. 평범한 DNS 해석은 위임 자체가 이름 트리 안에 표현되어 있으므로 어떤 이름에 대해 누가 권위자인지 물을 수 있다. IQUERY는 값에 대해 누가 권위자인지 정의하지 않았다. 클라이언트는 어떤 서버의 시야가 관련이 있는지 알기 전에 서버를 선택해야 했다.

따라서RFC 883은 역질의를 환경 의존적이라고 다루었다. 리졸버는 특정한 알려진 서버로 구성될 수 있었다. 그런 서버는 경계가 분명한 관리 데이터셋에 유용할 수 있었다. 문법적으로 성공한 응답을 돌려준다는 이유만으로 전체 인터넷의 신탁이 될 수는 없었다.

결정적인 구분은 진실과 범위 사이의 구분이다. 서버가 요청된 레코드를 포함하는 세 개의 로컬 이름을 발견했다면, 그 일치 항목은 완전히 사실일 수 있다. 그래도 응답은 서버가 갖고 있지 않은 다른 영역에 네 번째 일치 이름이 존재하지 않음을 증명할 수 없었다. 로컬 정확성은 전역 권위를 수반하지 않았다.

“네임 서버가 아는 범위의”가 실제 계약이었다

RFC 1035는 경계를 특별히 명확히 적었다. 응답은 네임 서버가 알고 있는, 즉which the name server knows범위 안의 모든 일치 이름을 식별한다고 했다. 어떤 서버도 전체 도메인 공간을 알지 못하므로 응답을 완전하다고 가정할 수는 없었다. 사양은 IQUERY를 데이터베이스 관리와 디버깅 용도로 한정하고, 호스트 주소를 호스트 이름으로 사상하는 일반적 수단으로는 배격했다.

이 문구는 모든 결과를 읽는 방식을 바꾼다. 이름이 0개라는 것은 선택된 서버가 가용 데이터에서 일치를 찾지 못했다는 뜻이다. DNS에 일치가 없다는 뜻이 아니다. 이름 1개는 유일성이 아니라 가시적 연관을 확립한다. 여러 개의 이름은 완전한 로컬 목록일 수도, 캐시의 우연일 수도, 더 큰 분산 집합의 일부일 수도 있다.

부정적 증거는 특히 약했다. 표준 DNS는 질의된 이름이 관련 권위를 찾아가기 때문에 지정된 영역 안에서 권위 있는 부정 응답을 반환할 수 있다. IQUERY에는 “이 값을 가진 모든 레코드” 주변에 대응하는 경계가 없었다. 부재를 증명하려면 그 값이 나타날 수 있는 모든 장소에 대한 지식이 필요했다.

이 연산은 그로써 지속적인 시스템 원칙을 드러냈다. 검색 결과는 단순히 일치하는 행의 모음이 아니다. 그 강도는 검색된 선언된 우주, 그 우주를 누가 통제하는지, 생략된 영역을 찾아낼 수 있는지에 달려 있다. 그런 사실이 없으면 완전해 보이는 목록은 하나의 시각일 뿐이다.

데이터베이스를 뒤집으면 두 번째 데이터베이스가 생겼다

운영 비용은 같은 불일치에서 비롯되었다. DNS 서버는 표준 질의가 이름과 함께 도착하므로 자연스럽게 소유자 이름 아래 레코드를 조직한다. IQUERY를 효율적으로 답하려면 레코드 내용으로 키가 매겨진 또 다른 접근 경로가 필요했다.

RFC 883은 영역별 역변환 테이블을 설명했다. 각 영역 갱신마다 관련 역변환을 다시 만들어야 할 수 있었다. RFC 1035는 전수 검색이나 기본 레코드 값으로 인덱싱된 별도 데이터베이스를 허용했다. 어느 쪽도 공짜가 아니었다. 스캔은 요청 시점에 시간을 썼고, 인덱스는 메모리와 유지 관리 노력을 끊임없이 썼다.

인덱스는 의미 작업도 배가했다. 레코드 데이터는 유형이 있다. 주소 바이트, 레코드 안의 도메인 이름, 문자열은 서로 다른 비교 규칙을 가진다. RFC 1035는 가능하면 대소문자 무시 비교를 권했지만, 서버가 내부 의미를 알지 못하는 문자 데이터를 들고 있을 수 있음을 인정했다. “이 값을 찾아라”는 보편적인 바이트 일치 연산이 아니었다.

수요와 비용은 나쁘게 나뉘었다. 원격 요청자는 작은 값을 제출할 수 있었다. 서버가 스캔, 인덱스 조회, 결과 조립, 전송 비용을 부담했다. 요청자는 그 검색이 영역 운영자에게 유익한지, 관리 가능한 결과로 경계가 지어졌는지 보여줄 필요가 없었다.

답변은 평범한 캐싱을 거부했다

DNS의 규모는 재사용 가능하고 시간이 한정된 답변에 크게 의존한다. IQUERY 결과는 그 기계 장치에 깔끔하게 들어맞지 않았다. RFC 1035는 일반 질의 응답과 같은 메커니즘으로 캐시될 수 없다고 경고했다.

이유는 패킷 형식 때문만이 아니었다. 반환된 일치는 값으로 선택된 하나의 관계를 대표했지만, 그 소유자 이름은 같은 유형의 여러 레코드를 가질 수 있었다. 멀티호미드 호스트의 한 주소에 대한 역방향 결과는 가시적 주소가 전체 집합이라는 잘못된 인상을 만들 수 있었다. 재구성된 질문으로 인덱싱된 캐시 항목은 그 결과를 만들어 낸 검색 범위와 생략 조건을 잃었다.

캐싱은 누락된 권위도 수선할 수 없었다. 로컬 답변을 더 많은 리졸버에서 반복하면 보기가 저렴해질 뿐, 전역적으로 완전해지지는 않는다. 분배는 증거적 경계를 넓히지 않고 주장만 증폭할 수 있다.

이것은 IQUERY를 평범한 DNS를 실용적으로 만든 아키텍처와 분리시켰다. 정상 질의는 조회 키, 위임, 권위, 캐시 키, TTL을 이름 중심으로 정렬한다. IQUERY는 메시지만 재사용하고 그 정렬을 깨뜨렸다. 모든 최적화는 결과가 한 시점의 한 서버의 지식을 서술한다는 사실을 기억해야 했다.

PTR은 역방향을 네이밍 문제로 만들었다

성공한 대안은 DNS에 모든 레코드 값을 검색하도록 가르치지 않았다. 역방향 키에 이름을 붙였다.RFC 1034는 IN-ADDR.ARPA를 서술한다. IPv4 주소의 옥텟이 특별한 도메인 아래 역순으로 놓이고, 그 이름에 놓인 PTR 레코드가 도메인 이름을 가리킬 수 있다.

주소10.1.0.52에 대해 리졸버는 역방향 트리 아래의 이름을 구성하고 평범한 질의를 수행할 수 있다. 그 위계는 트리의 일부를 위임할 수 있다. 리졸버는 권위 서버를 찾고, 이름이 붙은 RRset을 TTL 동안 캐시하며, 영역 안에서 경계가 분명한 부정 결과를 해석할 수 있다.

그 추가 간접 참조가 아키텍처적 성과다. PTR은 모든 주소가 레코드를 가진다거나, 한 주소에 이름이 하나뿐이거나, 반환된 이름이 기계를 인증한다고 약속하지 않는다. 더 좁고 더 방어 가능한 일을 한다. 역방향 주장을 DNS가 이미 권위 라우팅 규칙을 갖고 있는 소유자 이름 아래 놓는다.

IQUERY는 분산 시스템에 알려지지 않은 인덱스를 발견하도록 요구했다. PTR은 역방향 공간을 담당하는 주체가 예측 가능한 이름에 명시적 레코드를 공표하도록 요구했다. 검색은 검색이 되었고, 전역적 포부는 위임된 주장이 되었다.

거대한 답변은 모호성을 노출로 바꿨다

2002년까지 운영적 판정은RFC 3425가 IQUERY를 폐기할 만큼 명확했다. 이 문서는 제한된 구현과, 기존 지원이 있던 곳에서의 일반적인 비활성화를 기록한다. 드물게 실행되는 코드의 버그, 데이터베이스 부담, 영역의 큰 부분이 원치 않게 공개되는 위험을 인용한다.

일부 값은 방대한 집합과 일치할 수 있었다. 큰 공급자의 네임서버에 위임된 모든 도메인을 요구하면 수만 개의 튜플과 메가바이트 단위의 응답 데이터가 나올 수 있었다. 작은 요청이 따라서 비싼 계산과 예외적 응답을 유발해 서비스 거부 지렛대가 되었다.

역방향 MX 프로브는 또 다른 문제를 제기했다. 서버는 메일 인프라를 공유한다는 이유만으로 넓은 이름 컬렉션을 노출할 수 있었다. 레코드가 개별적으로 비밀은 아니었지만, IQUERY는 그것들을 모으는 비용을 바꾸었다. 많은 소유자 이름 아래 데이터를 공표하는 것이 무한한 값 인덱스 목록화를 자동으로 승인하는 것은 아니었다.

같은 연산은 정직한 클라이언트에게는 약하고 악의적인 클라이언트에게는 매력적이었다. 정직한 클라이언트는 결과가 완전한지 알 수 없었다. 공격자는 완전성이 필요 없었다. 자원 소모와 대량 열거는 한 서버의 로컬 시각만으로도 가치가 있었다.

폐기는 opcode의 역사를 보존했다

RFC 3425는 opcode 1을 조용히 재사용하지 않았다. IQUERY를 낡은 것(obsolete)으로 표시하고, RFC 1035의 해당 절을 대체된 것으로 다루도록 요구했으며, 서버가 그런 요청에 Not Implemented로 답해야 한다고 했다. IANA에는 opcode를 영구 폐기하도록 요청되었다.

이 결정은 프로토콜 위생이다. 잠자는 번호는 빈 공간처럼 보일 수 있지만, 재사용하면 구식 구현이 새 트래픽을 버려진 의미로 해석하게 된다. 영구 폐기는 서비스 기대를 끝내면서 의미를 판독 가능하게 유지한다.

그 RFC는 또한 의미 있는 서비스를 위해 IQUERY에 의존하는 알려진 클라이언트가 없고, PTR 역방향 사상은 수년간 커뮤니티에 봉사해 왔다고 기록했다. 폐기는 새 문법에 대한 미적 선호 때문이 아니라 작동하는 의존성의 부재를 따라왔다.

보안 논증이 이 결정을 강화했다. DNSSEC로 IQUERY 응답을 보호하는 것은 결과를 즉석에서 서명하지 않는 한 극히 어려웠다. DNSSEC는 이름이 붙은 RRset과 서명된 이름 구조 안의 부정을 인증할 수 있다. 임의의 검색 결과는 추가로 검색된 우주에서 일치하는 레코드가 생략되지 않았음을 함의한다. IQUERY는 그 우주를 전역적으로 정의하는 방법을 끝내 몰랐다.

서버는 증인이지 네임스페이스가 아니었다

IQUERY의 역사는 제도적 주장에 관한 작은 교훈으로 읽힐 수 있다. 서버는 DNS에 참여하고 권위 있는 영역, 캐시 데이터, 정확한 레코드를 들고 있을 수 있다. 그 사실은 그것을 네임스페이스의 정의된 부분에 대한 증인으로 만든다. 우연히 같은 값을 공유하는 모든 이름의 주체(principal)로 만들지는 않는다.

Lu Heng의 노트는 존재를 위임에서 분리하고, 데이터베이스 관리를 기록된 것에 대한 권위에서 분리한다. 프로토콜 규모에서 IQUERY는 같은 경계를 드러낸다. 검색 가능한 사본을 소유하면 그 사본을 보고할 권한이 생긴다. 부재 데이터에 대한 권위나 로컬 목록을 보편적 결정처럼 다룰 권한은 주어지지 않는다.

수선은 더 큰 중앙 목록을 만드는 것이 아니었다. 공통 계층을 작게 유지하는 것이었다. 이름, 위임, 레코드 유형, 캐시 수명, 명시적 역방향 트리 레코드. 참여자는 경계가 분명한 영역 안에서 주장을 공표할 수 있고, 리졸버는 한 서버에 전지성을 부여하지 않으면서 같은 상호운용 가능한 규칙을 따를 수 있었다.

증거의 한계

다섯 개의 RFC는 지정된 메시지, 그 한계, 이름 트리 대안, 그것을 낡은 것으로 만든 표준 결정을 확립한다. 그러나 현재 opcode 1 트래픽을 측정하지 않고, 모든 역사적 구현을 열거하지 않으며, 사적 진단 도구가 여전히 그런 패킷을 만들지 않는다는 것을 증명하지도 않는다.

NOTIMP는 기대되는 표준 응답이지 서버가 요청을 파싱한 적이 없다는 증거가 아니다. 타임아웃은 IQUERY 지원이나 거부를 증명하지 않는다. 응답은 전역 완전성을 증명하지 않는다. 현재 동작에는 패킷 캡처, 서버 구성, 구현별 증거가 필요하다.

PTR 역시 신원 증명으로 승격되어서는 안 된다. 정방향과 역방향 레코드는 불일치할 수 있고, 여러 이름이 같은 주소를 가리킬 수 있으며, 관리자가 데이터를 생략하거나 잘못 구성할 수 있다. 교훈은 주장에 대한 권위를 찾아가는 것이지 공표된 모든 주장이 올바르다고 보장하는 것이 아니다.

IQUERY는 질문의 방향은 제공했지만 권위의 방향을 제공하지 못했기 때문에 실패했다. 와이어는 한 비트로 사상을 뒤집을 수 있었다. 분산 시스템은 그 위임들을 그렇게 싸게 뒤집을 수 없었다. DNS는 유혹적인 질문을 폐기하고 역방향 주장을 이름 아래 살도록 요구했을 때 더 신뢰할 수 있게 되었다.

출처