요약

  • RFC 8482는 ANY 질의에 더 적은 데이터로 답하는 선택적 방법을 제시했다. 비어 있지 않은 RRset을 일반 캐시에 넣을 수 있어, 클라이언트 전역의 새로운 거부 메커니즘 없이도 반복 질문을 줄일 수 있었다.
  • 몇 개의 완전한 RRset을 선택하는 것은 모든 사용 가능한 타입을 나열하겠다는 약속이 아니다. 최소 긍정 답변도 그것이 생략한 타입에 대해 부정하는 진술이 아니다.
  • 합성 HINFO는 기존 소프트웨어에 익숙한 답변을 만들어 주었지만, 캐시 안의 실제 HINFO를 가릴 수 있었다. 그 TTL은 현재의 질의 감소와 미래에 정책을 바꿀 자유 사이의 절충을 의미했다.

클라이언트가 이해하지 못한 코드

새로운 거부 방식의 문제는 단지 구식 클라이언트가 낯선 숫자를 표시한다는 것만이 아니었다.RFC 8482에 따르면, 제안된 낯선 응답 코드를 마주한 리졸버는 다른 이용 가능한 권위 서버를 시도하게 된다. 한 응답자가 피하려던 작업이 다른 곳에서 발생할 수 있었다.

그 대안은 비어 있지 않은 리소스 레코드 집합을 제공했다. 수정되지 않은 클라이언트는 그것을 캐시할 수 있었다. 같은 이름이 곧바로 또 다른 ANY 트랜잭션을 일으킬 필요가 없었다. 모든 리졸버에 멈출 새로운 이유를 가르치는 대신, 응답자는 답변을 받는다는 익숙한 결과를 활용했다.

이 비교는 RFC가 자신의 설계를 설명하는 것이지, 모든 DNS 오류가 동일한 재시도를 낳는다는 보편적 법칙이 아니다. 이 구분이 중요한 이유는 그 메커니즘이 새로 부과된 전 클라이언트 보장이 아니라 기존 동작에 의존하기 때문이다.

2019년 1월에 발표된 RFC 8482는 RFC 1034와 RFC 1035를 갱신하는 Standards Track 문서다. 그 명세된 동작은 발기자와 응답자 모두에게 선택 사항이다. 이 문서는 ANY를 폐지하거나 모든 서버에 HINFO 제작을 요구하지 않았다. 이미 운용 중인 소프트웨어에 이해될 수 있는 상태에서 운영자가 답변 범위를 줄일 수 있는 방법을 기술했다.

그 질문에는 정당한 사용자가 있었다

ANY는 디버깅과 특정 이름에 대한 서버 상태 조사에 도움이 될 수 있었다. 애플리케이션도 한 번의 교환으로 MX, A, AAAA 같은 레코드를 얻으려는 지름길로 그것을 사용했다. 이것들은 본질적으로 적대적인 행위가 아니었다.

그러나 지름길에는 전제가 깔려 있었다. 애플리케이션은 질의가 권위 서버에 도달해 존재하는 모든 RRset을 반환하리라고 기대할 수 없었다. RFC 8482는 그런 전제를 두는 구현자에게 대체 경로를 마련하라고 말한다. 질문을 줄이는 것은 애플리케이션 자신의 기능에 필요한 정보를 얻을 책임을 면제해 주지 않는다.

응답자에게 작업을 제한할 이유는 있었다. 일부 구현은 넓은 답변을 조립하는 데 추가 처리를 부담했다. 운영자는 데이터 수집에 대한 우려도 있었다. 그리고 위조된 소스 주소를 이용한 반사 증폭에는, 훨씬 큰 응답을 유도할 수 있는 작은 UDP 질의가 매력적이었다.

더 작은 답변은 그 매력을 줄일 수 있다. 이것은 현재의 공격 규모에 대한 추정이나 측정된 증폭 비율이 아니다. 모든 ANY 질의를 공격으로 분류하는 것도 아니다. 하나의 편리한 질문을 제한한다고 해서 다른 공개 DNS 정보가 기밀이 되는 것도 아니다.

따라서 설계는 두 사실을 동시에 수용해야 했다. 일부 질문은 유용하고, 그것을 넓게 답하는 것은 공짜가 아니다. 캐시 가능한 최소 답변은 무한한 나열을 전제하는 것과 기존 클라이언트가 다른 곳으로 옮겨 갈지 모르는 거부를 고안하는 것 사이의 응답 정책을 제공했다.

ANY는 타입이었지 재고 목록 명령이 아니었다

1987년 11월,RFC 1035는 질의 타입 255를 별표로 표현했다. 구현체는 흔히 그것을 ANY라 부른다. 현재의IANA DNS 파라미터 레지스트리는 그 값을 서버에서 이용 가능한 레코드 중 일부 또는 전부를 요청하는 것으로 기술한다. HINFO는 여전히 호스트 정보를 위한 타입 13이다.

등록은 식별자와 의미를 제공한다. 현재 서버가 어떤 특정 답변 정책을 얼마나 구현하는지에 대한 증거는 아니다.

DNS 질문의 별개 필드들도 “any”의 의미를 제약한다. RFC 1035와 같은 달에 발행된RFC 1034는 질의된 이름, 타입, 클래스를 구분한다. QTYPE의 ANY는 QNAME의 와일드카드가 아니며, AXFR 영역 전송도 아니다. 하나의 이름에 대해 넓게 묻는 것이 영역의 모든 이름을 나열하는 것은 아니다.

응답 알고리즘은 영역 데이터와 캐시 데이터를 구분한다. 캐시는 자신이 가진 일치하는 레코드로 답할 수 있다. 그렇다고 권위 서버가 가질 수 있는 모든 타입에 대한 새로 조립된 조사를 약속하는 것은 아니다. 캐시는 이미 애플리케이션의 명시되지 않은 전수 수집 기대를 불신할 이유였다.

RFC 8482의 관련 응답자 방법은 존재하는 QNAME, 클래스 IN, 질의 타입 ANY에 관한 것이다. 명시된 변경을 제외하고는 정상적인 알고리즘이 계속 적용된다. 그 정책은 존재하지 않는 이름을 발명하거나, 넓은 답변을 피하고 싶다는 이유만으로 존재하는 이름을 NXDOMAIN으로 기술할 권한이 아니다.

완전한 집합이 불완전한 선택일 수 있었다

허용된 한 가지 방법은 단일한 이용 가능한 RRset 또는 질의된 이름이 소유한 이용 가능한 RRset의 작은 부분집합을 반환한다. 4.1절은 이 선택이 불완전하다는 신호가 없음을 명시적으로 말한다. 생략된 TXT 집합은 그 이름에 TXT 데이터가 없다는 증거로 취급될 수 없다.

선택은 집합 사이에서 이루어지며, 하나의 집합 안에서 임의의 멤버 사이에서 이루어지지 않는다. 1997년 7월에 발표된RFC 2181은 RRset을 같은 소유자 이름, 클래스, 타입을 공유하되 레코드 데이터가 서로 다를 수 있는 집합으로 정의한다. 주소 RRset에 여러 레코드가 있을 때, 편리한 멤버 하나를 반환하는 것은 집합을 온전히 반환하는 것과 동등하지 않다.

RRset 완전성에 대한 일반 요구 사항은 여전히 중요하다. 필수 집합 전체가 들어가지 않으면 잘림 규칙이 관련된다. 더 적은 타입을 고르는 것은 필수 집합을 잘라내는 것과 다른 작업이다.

TC 비트는 이 구분을 지우지 않는다. 그것이 없다는 것은 모든 이용 가능한 타입이 나열되었다는 증명서가 아니다. 클라이언트는 선택된 RRset을 완전히 받으면서도 그 이름의 완전한 목록을 받지 않을 수 있다. 전송이나 메시지 조건을 재고 약속으로 읽는 것은 답변에 포함되지 않은 정보를 추가하는 일이다.

프로세서를 기술하지 않는 호스트 정보 레코드

두 번째 방법은 일치하는 소유자 이름에 CNAME이 없을 때 HINFO를 합성한다. RFC 8482는 CPU 문자열을 RFC8482로, OS 문자열을 빈 값으로 하는 단일 HINFO 레코드를 권고한다. 이것은 그 레코드를 영역의 저장된 데이터에 영구히 삽입하도록 요구하지 않는다.

빌려 쓴 형식은 새 용도보다 오래되었다. RFC 1035는 HINFO에 CPU와 OS 두 개의 문자열을 부여한다. 그것은 일반적인 호스트 정보를 기술하고, FTP가 유사한 기계와 운영체제를 다루는 절차 같은 것을 용도로 언급한다. 낡은 레코드 형태가 이제, 그 주된 실용적 가치가 보존될 수 있다는 점인 답변을 담을 수 있게 된 것이다.

이 방법으로 명시적으로 만들어진 레코드에서 CPU 문자열은 관찰된 프로세서 아키텍처가 아니다. 비어 있는 OS는 여전히 길이 0의 문자열이며, 두 번째 필드의 부재도, 호스트에 운영체제가 없다는 발견도 아니다.

그러나 수신자는 그 값들만으로 임의의 HINFO의 출처를 신뢰성 있게 판별할 수 없다. 4.2절은 이 명세가 사용되었다고 결론짓고 그 전제로 특수 처리를 적용하는 것을 경고한다. 알아볼 수 있는 텍스트는 인증된 정책 플래그가 아니다.

문서는 별도로 일반적인 캐싱을 허용한다. 기술된 종류의 일치하는 캐시된 HINFO를 가진 발기자는 나가는 ANY 질의를 억제하거나, 평소처럼 캐시에서 답할 수도 있다. 두 지점 모두 설명에 살아 있어야 한다. 캐시된 정보는 그 생성 방법에 대한 결정적 증거가 되지 않으면서도 유용할 수 있다.

낡은 의미에도 여전히 소유자가 있을 수 있었다

HINFO를 빌려 쓰는 데는 구체적인 부작용이 있었다. 합성된 레코드가 한 번 캐시되면 영역 안의 실제 HINFO를 가릴 수 있어, 이후의 직접 HINFO 질의에 영향을 미쳤다. 한 질문을 위해 설계된 답변이 다른 타입의 다음 질문에 영향을 줄 수 있었다.

RFC 8482는 전통적 HINFO에 의존하는 운영자에게 기존 RRset 방법이나 다른 레코드 타입을 선택하라고 경고한다. 저자들의 DNS 관찰에서 나와 2019년에 보고된, HINFO가 드물게 사용된다는 관찰은 아무도 그것에 의존하지 않았다는 증거가 아니다. 2026년의 새로운 도입 조사 통계도 아니다.

이것은 몇 바이트의 오버헤드가 아니라 의미론적 비용이었다. 익숙한 형식은 기존 캐시가 그것을 평범한 데이터로 취급할 것이기 때문에 배포를 쉽게 했다. 바로 그 익숙함이 원래 타입의 정당한 사용에 방해물이 될 수 있었다.

세 번째 선택지가 있다. 발기자의 필요를 추측하여 CNAME, MX, A, AAAA 집합을 반환하고 TXT나 DNSKEY 같은 다른 타입은 억제하는 것이다. 그 답변은 더 클 수 있다. 이것은 허용된 휴리스틱이지, 서버가 애플리케이션의 의도를 올바르게 추론했다는 증거가 아니다.

하나의 결정의 수명

합성 레코드의 TTL은 구성 가능해야 한다. 같은 발기자가 같은 이름에 대해 빈번히 반복하는 ANY 질의를 줄이려면 충분히 길어야 한다. 그러나 긴 수명은 이후 운영자의 ANY 정책 변경을 늦출 수 있다. RFC 8482는 모든 서비스에 단일 숫자를 규정하지 않고 이 절충을 말한다.

RFC 2181은 TTL을 최대 보유 시간으로 만들며, 정확히 그 구간 동안 레코드를 보유할 의무로 만들지 않는다. 구현은 더 낮은 한도를 둘 수 있다. 따라서 운영자는 자신이 보낸 값에서 전역적으로 동기화된 만료를 추론할 수 없고, 권위 서버를 바꾸는 것이 원격 복사본을 즉시 지운다고 가정할 수도 없다.

정책에는 두 시점이 있다. 응답자의 현재 결정과, 특정 캐시가 이전 결정으로 답하는 것을 멈추는 시점이다. 이들은 일치할 필요가 없다. 질의 감소는 부분적으로, 출처가 이미 다음 단계로 넘어간 뒤에도 이전 답변이 계속 일하게 두는 것에서 얻어진다.

부재도 서명도 없는 목록을 채워 주지 않았다

DNS의 부정 답변에는 자체 규칙이 있다. 1998년 3월에 발표된RFC 2308은 NXDOMAIN 이름 오류와, 적절한 NOERROR 응답에서 추론되는 요청 타입 데이터의 부재를 구분한다. 부정 캐싱은 응답 내용, SOA 조건, 저장된 결과의 범위에 의존한다.

비어 있지 않은 선택된 또는 합성된 ANY 답변은 그 자체로 생략된 모든 타입에 대한 부정 진술이 아니다. 존재하지 않는 모든 타입을 미존재로 표시하는 모니터링 시스템은 추가적인 추론을 한 것이다. 희박한 응답은 그것을 승인하지 않았다.

서명도 그 간극을 메우지 않는다. RFC 8482는 서명된 영역에서 선택된 RRset에 적절한 RRSIG를 요구한다. 합성 HINFO 방법에서는 DO가 설정되고 응답자가 영역이 서명되어 있음을 알 때 유효한 RRSIG가 필요하며, DO가 지워져 있으면 서명은 생략해야 한다. 추측 답변 방법도 DO가 설정된 서명된 영역에 대한 서명 요구가 있다. 이 분기들은 모든 답변이 서명을 실어야 한다는 주장이나, 최소화가 모든 서명을 면제한다는 주장으로 평탄화되어서는 안 된다.

2001년 12월의RFC 3225는 플래그 자체에 유용한 한계를 제공한다. EDNS OPT 플래그의 DO는 DNSSEC 보안 레코드를 받아들일 수 있는 능력을 표현한다. 그것은 검증이 이미 이루어졌다는 뜻이 아니다. 이 역사적 정의가 여기서 관련된다. 문서의 오래된 SIG, KEY, NXT 절차가 현재의 RRSIG 지침으로 제시되는 것은 아니다.

반환된 RRset의 인증은 생략된 RRset의 나열이 아니다. 답변은 서명 요구를 충족하면서도 애플리케이션이 수집하기를 바랐던 타입을 결여할 수 있다.

전송 방식을 바꾸는 것이 무조건적인 탈출구도 아니다. RFC 8482는 TCP에 걸친 전통적 ANY와 UDP에 걸친 최소 ANY를 포함해 UDP와 TCP에서 서로 다른 정책을 허용한다. 그것은 허용된 예시이지, 포괄적인 결과를 보장하는 강제 대체 경로가 아니다. 운영자의 정책, 질문, 캐시 경로는 모두 설명의 일부로 남는다.