요약

  • DNS 와일드카드는 존을 검색하는 패턴이 아닙니다. 별표 레이블로 시작하는 소유자에 위치한 RRset으로, 정확한 트리 매칭이 권위 있는 존에서 벗어났을 때만 사용됩니다.
  • RFC 4592는 우선순위를 명확히 했습니다: 가장 가까운 기존 인클로저(closest encloser)를 찾은 다음, 정확히 하나의 가능한 소스인*.<가장 가까운 인클로저>만 살펴봅니다. 이것이 없거나 요청한 타입을 갖고 있지 않으면 더 먼 와일드카드는 시도되지 않습니다.
  • DNSSEC는 와일드카드 데이터와 정확히 일치하거나 더 가까운 이름이 응답했어야 할 대상이 없다는 증거를 모두 검증해야만 합성된 응답을 인증할 수 있으며, 목적지의 안전성이나 의도를 보증하지는 않습니다.

저장된 소유자 없이 나오는 긍정 응답

존에*.example에 주소 RRset이 있지만blue.example이라는 소유자가 없다고 가정해 봅시다. 존재하지 않는 이름에 대한 쿼리는 소유자가blue.example이고 주소, TTL, 클래스가 와일드카드 RRset에서 온 응답을 받을 수 있습니다. 서버가 쿼리별 소유자 이름을 만들어 내기 때문에 응답은 구체적으로 보입니다. 저장된 지시는 여전히 와일드카드입니다.

RFC 1034는 1987년 와일드카드 레코드를 레코드를 합성하기 위한 지시로 기술했습니다. 메일 게이트웨이가 초기 사례였습니다: 존은 알려지지 않은 이름에 공통 전달 속성을 부여할 수 있었습니다. 그러나 이 명세는 별표를 정규 표현식이나 무한한 소유자 레지스트리로 만들지 않았습니다. 하나의 권위 있는 존 안에서의 조건부 서버 동작을 정의했습니다.

이 구분은 애플리케이션이 나중에 긍정적인 DNS 응답을 이름이 의도적으로 프로비저닝되었다는 증거로 취급할 때마다 중요합니다. 아무도 그 정확한 소유자를 만들지 않았더라도 서버는 올바르게 응답했을 수 있습니다. DNS는 트리 알고리즘의 결과를 확인해 줄 뿐, 쿼리된 문자열 뒤에 있는 역사나 의도는 확인해 주지 않습니다.

정확한 존재가 우선권을 갖는다

와일드카드 합성은 평범한 레이블 매칭이 불가능해질 때만 시작됩니다. 쿼리 이름이 존재하면 와일드카드는 누락된 타입을 공급할 수 없습니다. AAAA 레코드는 있지만 MX 레코드가 없는 기존 이름은 MX 데이터를 생성하지 않으며,*.example에서 MX를 빌려오지도 않습니다.

존재는 쿼리된 노드에 보이는 레코드보다 넓습니다. 이름은 빈 비단말(empty non-terminal)일 수 있습니다: RRset을 소유하지 않지만 더 깊은 자손이 존재하기 때문에 존재해야 하는 노드입니다. 그 침묵하는 구조적 노드조차 매칭을 바꿉니다. 따라서 평범한 자손 하나를 추가하면 이전에 관찰되던 와일드카드 응답을 억제하는 중간 이름이 만들어질 수 있습니다.

이 우선순위는 명시적 구조에 기본값을 좁힐 권리를 부여합니다. 또한 삭제가 결과를 낳음을 보여줍니다. 빈 비단말 아래의 마지막 자손을 제거하면 중간 노드가 존재하지 않게 되어 그 아래 이름들이 다시 더 넓은 와일드카드에 노출될 수 있습니다. 와일드카드 RRset은 변하지 않았습니다; 그 사용 권한은 주변 트리가 바꾼 것입니다.

하나의 가장 가까운 인클로저, 하나의 가능한 소스

구현 경험과 DNSSEC 작업은 원래 문구의 모호성을 드러냈습니다.RFC 4592가 정확한 용어를 제공했습니다.

가장 가까운 인클로저는 쿼리와 가장 긴 레이블 접미사를 공유하는 기존 존 노드입니다. 정확한 매칭이 트리에서 벗어나면 서버는 그 노드 바로 아래의 후보 하나를 만듭니다:*.<가장 가까운 인클로저>. 그 와일드카드 도메인 이름이 존재한다면 그것이 합성의 소스입니다.

편리한 답을 위해 조상 와일드카드를 뒤지는 일은 없습니다. 하나의 조회에 최대 하나의 소스만 적용됩니다. 그 소스가 없으면 조회는 와일드카드 합성 없이 끝납니다. 존재하지만 요청한 타입의 RRset이 없으면 결과는 와일드카드 노 데이터(no data)이며, 더 먼 와일드카드가 그 간격을 채울 수 없습니다.

이 규칙은 중첩된 와일드카드를 결정론적으로 만듭니다. 또한 '와일드카드는 도메인 아래 모든 것을 커버한다'는 표현이 왜 안전하지 않은지 드러냅니다. 더 가까운 기존 노드, 심지어 빈 노드조차 후보 소스를 다시 계산합니다. 커버리지는 현재 트리와 쿼리의 결과이지, 하나의 별표가 소유한 영구 영역이 아닙니다.

별표는 언어가 아니라 레이블이다

정확히*인 초기 레이블만 도메인 이름에 와일드카드 지위를 부여합니다. 다른 위치에 삽입된 별표는 특별한 와일드카드 의미가 없습니다. 리터럴 별표를 포함한 쿼리는 패턴 매칭 요청이 아니며, 다른 레이블처럼 처리되어 와일드카드 소유자 자체를 조회하는 데 사용될 수 있습니다.

합성 이후에도 평범한 레코드 의미론이 적용됩니다. 와일드카드 CNAME이 합성될 수 있으며, 그 이후 일반 별칭 처리가 계속됩니다. 그렇다고 DNS가 애플리케이션 라우터, 부분 문자열 매처 또는 인증서 정책이 되는 것은 아닙니다. 규칙은 RRset을 선택할 뿐이고, 그 결과 데이터가 무엇을 허용하는지는 상위 계층이 결정합니다.

위임은 기본값을 끝낸다

RFC 1034는 의도적으로 와일드카드 기본값이 존 경계를 넘지 않는다고 말했습니다. 매칭이 위임에 도달하면 부모는 부모의 와일드카드를 컷 아래 적용하는 대신 리졸버를 자식에게 참조시킵니다. 자식은 자체 기본값을 구성할 수 있지만, 자체 권위 있는 데이터 아래에서 그렇게 합니다.

이것은 구현 세부사항이 아니라 제어 경계입니다. 부모는 모든 누락된 자식 이름에 대한 숨겨진 폴백 응답을 유지하지 않으면서 네임스페이스를 위임할 수 있습니다. 반대로 운영자는 유용한 부모 와일드카드가 새로 위임된 분기를 따라갈 것이라고 가정할 수 없습니다. 권위는 컷에서 바뀌고, 기본값도 그와 함께 바뀝니다.

더 가까운 것이 와일드카드를 앞지르지 않았음을 증명하기

DNSSEC는 와일드카드 응답의 숨겨진 전제를 검증 가능하게 만들었습니다.RFC 4035는 서명된 와일드카드 응답이 확장된 RRset과 서명, 그리고 정확히 일치하거나 더 가까운 매치가 응답했어야 할 대상이 없음을 보여주는 인증된 부정 증거를 함께 담을 것을 요구합니다.

RRSIG 레이블 수는 응답이 쿼리 이름을 표시하더라도 검증자가 서명 검증에 사용된 와일드카드 소유자를 재구성하게 합니다. NSEC 증거는 합성을 허가한 부재를 증명합니다. 따라서 검증자는 두 사실을 확인합니다: 소스 데이터가 서명되었고, 존 트리가 이 와일드카드를 적용 가능한 소스로 남겼다는 것입니다.

그 증명은 여전히 좁습니다. 서명된 존의 진술과 결정론적 우선순위 규칙을 인증할 뿐입니다. 쿼리된 철자가 의도되었는지, 서비스가 양성인지, 인증서가 발급되어야 하는지, 애플리케이션이 목적지를 신뢰해야 하는지는 보여주지 않습니다.

출처와 한계

폐쇄된 증거 집합은RFC 1034,RFC 4592,RFC 4035입니다. 이는 프로토콜 동작, 용어, DNSSEC 증명 의무를 확립합니다. 현재 배포, 쿼리 볼륨, 운영자 관행, 리졸버 점유율, 어뷰즈 또는 제품 행동은 측정하지 않습니다.