요약

  • DNS의 Authoritative Answer(AA) 플래그는 질의된 이름 또는 Answer 섹션의 첫 번째 소유자 이름에 근거합니다. 같은 응답에 담긴 별칭 대상 이름, Authority 레코드, 글루 및 기타 Additional 데이터는 서로 다른 출처 정보를 가질 수 있습니다.
  • 방어 가능한 리졸버 수신 기록은 각 RRset의 소유자, 타입, 섹션, 존 컷, 캐시 출처, DNSSEC 상태와 모든 후속 질의를 보존해야 하며, 하나의 헤더 비트를 패킷 전체의 권위나 진위성으로 확대 해석해서는 안 됩니다.

권위 있는 서버에shop.example을 질의해서 세 가지 유용한 정보를 받았다고 상상해 봅시다. Answer 섹션은shop.example을 소유자로 하는 CNAME으로 시작합니다. 이후의 주소 RRset은 다른 존에 있는 대상 이름을 가리키며 캐시에서 온 것입니다. Additional 섹션은 리졸버가 추가 질의를 하지 않도록 도와주는 또 하나의 주소를 제공합니다. 헤더에는 AA가 설정되어 있습니다.

패킷 중심 감사 테이블이 여기서 유혹적인 선택을 합니다. 세 RRset을 모두authoritative = true아래에 기록하는 것입니다. 몇 달 뒤 대상 주소가 그 자체 존에서 온 직접 응답과 충돌합니다. 이 테이블은 첫 번째 이름에 대한 권위, 별칭을 통해 도달한 캐시 데이터, 편의를 위해 추가된 정보 사이의 구분을 이미 폐기했기 때문에 충돌을 설명할 수 없습니다.

이것은 보고된 DNS 사고가 아니라 가상의 증거 설계 실패 사례입니다. 그럼에도 이는 1비트 필드에 내장된 특이할 만큼 정밀한 경계를 드러냅니다.

하나의 닻에 고정된 비트

RFC 1035를 집필한 폴 모카페트리스(Paul Mockapetris)는 DNS 응답 헤더의 AA 비트를 정의했습니다. 이 비트는 응답하는 네임 서버가 Question 섹션의 도메인 이름에 대한 권위자임을 나타냅니다. 문서는 곧 어려운 사례를 다룹니다. 별칭 때문에 Answer 섹션은 여러 소유자 이름을 담을 수 있으므로, AA는 질의 이름과 일치하는 이름 또는 Answer 섹션의 첫 번째 소유자 이름에 해당합니다.

이 한 문장이 패킷 수준의 지름길을 막습니다. AA는 하나의 플래그이며, 모든 RRset 옆에 붙는 병렬 비트가 아닙니다. AA는 응답 경로의 시작점에서 응답자의 권위에 대해 보고합니다. 뒤에 오는 모든 이름, 모든 메시지 섹션, 모든 데이터 출처에 동일한 출처 정보를 다시 칠하지 않습니다.

이 구분은 플래그의 결함이 아닙니다. 컴팩트한 DNS 헤더는 모든 RRset이 응답에 들어온 경로 전체를 인코딩할 수 없습니다. 오류는 관찰자가 이 컴팩트한 신호에 경로를 대체하도록 요구하는 순간 시작됩니다.

모카페트리스의 동반 문서RFC 1034는 경로가 갈라지는 이유를 보여줍니다. 권위 있는 존 데이터를 다루는 서버는 CNAME을 Answer에 복사하고 QNAME을 정식 이름으로 바꾼 뒤 처리를 다시 시작할 수 있습니다. 위임 지점에서는 NS 레코드를 Authority에, 이용 가능한 주소를 Additional에 넣으며, 그 데이터는 글루, 권위 있는 데이터 또는 캐시에서 나올 수 있습니다. 응답을 보내기 전에 유용하다고 판단하는 다른 로컬 레코드를 추가할 수도 있습니다.

따라서 하나의 유선 메시지가 하나의 증거 등급이 아니면서도 일관되고 유용할 수 있습니다.

섹션은 증거이지 판정이 아니다

RFC 1035는 응답 섹션에 각기 다른 역할을 부여합니다. Answer 레코드는 질문에 답합니다. Authority 레코드는 권위 있는 네임 서버를 가리킵니다. Additional 레코드는 질의와 관련되지만 엄밀한 의미의 답은 아닙니다. 섹션 구분을 보존하는 것은 평면화된 패킷에 대한 첫 번째 수복이지 마지막이 아닙니다.

Authority에 들어간 NS RRset과 Additional에 담긴 그 주소 레코드는 함께 작동해 리졸버를 다음 단계로 전진시킵니다. 존 컷에서 일부 주소 데이터는 부모가 공급하는 글루일 수 있습니다. 자식의 서버 이름이 다른 방법으로는 도달하기 어려울 수 있기 때문입니다. 그래서 이 데이터는 운영상 필요합니다. 그러나 이것이 부모가 컷 아래 모든 이름에 대해 권위를 갖게 만들지는 않으며, 글루를 자식 존의 주소 주장으로 바꾸지도 않습니다.

같은 섹션이 서로 다른 시점에 서로 다른 이력을 가진 레코드를 담을 수도 있습니다. 리졸버는 단지 "Additional"이 아니라 소유자 이름, 타입, 클래스, 관할 범위(bailiwick), 출처 서버, 캐시 수신 기록, 만료 시각을 필요로 합니다. 메시지 레이아웃은 레코드가 어디에 실려 왔는지 알려줄 뿐입니다. 그것만으로 출처 분석이 끝나지 않습니다.

RFC 2181은 이 순위를 명시적으로 만듭니다. 글루를 제외한 기본 존 및 존 전송 데이터는 권위 있는 Answer 데이터보다 위에 놓입니다. 권위 있는 응답의 Authority 데이터, 글루, 비권위 Answer 데이터, Additional 데이터는 각각 구분되는 하위 위치를 차지합니다. 응답에서 온 권위 있는 답은 이전에 Additional로 취득해 캐시된 RRset을 대체할 수 있고, Additional 정보는 더 우수한 권위 또는 존 파일 데이터를 밀어내서는 안 됩니다.

이 순위가 중요한 이유는 캐시가 우연히 맥락을 세탁할 수 있기 때문입니다. 어떤 시스템이 Additional RRset을 출처 순위 없이 저장하면, 이후 내보내기에서 그것을 평범한 답으로 반환할 수 있습니다. 탐색 보조 도구로 시작한 것이 직접 주장처럼 보이게 되는 것입니다. 메모리에 머무는 동안 그 바이트들이 더 권위적이 되었던 것은 아닙니다.

별칭이 경계를 드러낸다

별칭은 "AA가 응답 전체를 커버한다"는 주장에 대한 가장 강력한 반례입니다. RFC 2181에 따르면 권위 있는 응답의 Answer 섹션은 보통 권위 있는 데이터를 담지만, 찾는 이름이 별칭인 경우에는 별칭을 기술하는 레코드만 반드시 권위 있는 것입니다. 다른 레코드는 캐시에서 왔을 수 있습니다. 권위 있는 데이터가 필요한 클라이언트는 정식 이름으로 다시 질의해야 합니다.

RFC 6604는 이후 CNAME과 DNAME 체인의 관점에서 이를 다시 서술했습니다. xNAME 체인의 각 답에 대해 권위 상태는 달라질 수 있습니다. AA의 규칙은 여전히, 서버가 Answer 섹션의 첫 번째 소유자 이름이 속한 존에 대해 권위자인지에 근거합니다.

첫 번째 서버가shop.example에 대해 권위자이고service.vendor.test로의 CNAME을 반환했다고 가정해 봅시다. 별칭에 대해 AA를 설정하는 것은 완전히 올바를 수 있습니다. 대상의 캐시된 주소도 여전히 유용할 수 있습니다. 그러나 "service.vendor.test의 권위 있는 주소"라고 기록한 수신 기록은 새로운 권위를 기록하지 않은 채 존 경계를 넘어선 것입니다. 대상의 권위 서버로의 후속 질의는 그 자체 응답과 플래그를 갖는 별개의 이벤트입니다.

증거 모델은 각 별칭 단계를 에지로 유지해야 합니다. 입력 이름, CNAME 또는 DNAME RRset, 권위 존, 출처 응답, 다음 이름, 이어진 질의가 그 에지를 구성합니다. 체인을 최종 주소로 접어버리는 것은 애플리케이션 캐시에는 편리할 수 있지만, 어떤 권위가 무엇을 주장했는지 말해야 하는 감사에는 불충분합니다.

권위는 진위성이 아니다

"권위 있는"이라는 단어는 더 큰 오류를 부릅니다. AA를 암호학적 보증으로 다루는 것입니다. RFC 6604는 AA 헤더 플래그가 DNSSEC로 보호되지 않는다는 점을 분명히 합니다. TSIG나 SIG(0) 같은 트랜잭션 보안은 서버와의 통신을 보호할 수 있지만, 데이터에 대한 DNSSEC 검증은 별개의 절차입니다.

RFC 4035는 RRset에 보안 상태를 부여합니다. 리졸버는 신뢰 닻으로부터 체인을 구성하면 Secure, 그런 체인이 적용되지 않음을 알면 Insecure, 예상된 증명이 실패하면 Bogus, 판단할 수 없으면 Indeterminate로 분류합니다. 이 상태들은 DNSKEY, DS, 서명, 부존재 증명, 정책, 검증에서 나오며 AA에서 나오지 않습니다.

AD 플래그는 또 다른 정의된 범위를 갖습니다. 보안 인지 서버는 사양의 세부 규칙에 따라 Answer와 Authority의 모든 RRset을 진짜로 간주하지 않는 한 이를 설정해서는 안 됩니다. RFC 6604는 이를 AA와 의도적으로 대조합니다. 그런 경우에도 클라이언트는 재귀 서버와 그 채널을 신뢰하는지 알아야 하며, 상위의 AD 주장이 자동으로 클라이언트 자신의 검증 수신 기록은 아닙니다. Additional 데이터는 AD의 대표 조건 밖에 있으며 여전히 별도의 처리가 필요합니다.

따라서 신중한 기록에는 여러 진실이 동시에 담길 수 있습니다. 첫 번째 답의 소유자에 대해 AA가 올바르게 설정되었고, 하나의 RRset은 Secure로 검증되었으며, 다른 하나는 Insecure였고, 하나의 글루 주소는 Additional에 도착했고, 중개자까지의 전송은 인증되지 않았습니다. 이 행 묶음을 하나의 초록색 "권위 있음" 배지로 축약하면 정보가 파괴됩니다.

기록 속에서 모카페트리스의 위치

Internet Hall of Fame 프로필은 폴 모카페트리스가 1983년 USC 정보과학연구소(Information Sciences Institute) 재직 시절 DNS를 발명했다고 기록합니다. RFC 1034와 RFC 1035는 그 뒤를 이은 개념과 유선 명세에 대한 그의 저자십을 보존합니다. 이 프로필은 또한 본 기사의 편집 이미지에 쓰인 역사적 공개 초상 자료를 제공합니다.

그 기록은 신원과 기여를 확립할 뿐, 현재의 운영 권위를 확립하지 않습니다. 기초 문서에 그의 이름이 있다고 해서 모카페트리스가 어떤 리졸버의 운영자, 존의 소유자 또는 현대 배포 결정의 출처가 되는 것은 아닙니다. 이후의 RFC들은 원래 설계가 이미 드러낸 구분을 구현이 어떻게 보존해야 하는지를 명확히 하는 집단적 표준 작업입니다.

여기서 얻을 수 있는 유용한 교훈은 더 좁습니다. DNS는 권위를 분산함으로써 네이밍을 확장했고, 그 메시지들은 그 분산의 서로 다른 단계에서 나온 결과를 실어야 했습니다. AA 비트는 모든 바이트에 찍히는 만능 증명서가 아니었습니다. 그 절제가 곧 아키텍처의 일부입니다.

패킷 라벨이 아니라 RRset 수신 기록을 만들어라

질의 튜플에서 시작하십시오. QNAME, QTYPE, QCLASS, 재귀 의도, DNSSEC OK와 Checking Disabled 선택, 트랜잭션 식별자, 전송 시각이 그 대상입니다. 정규화 이전에 응답 바이트, 엔드포인트, 전송 계층, 수신 시각, 트랜잭션 인증 증거를 저장하십시오.

그런 다음 메시지를 RRset 단위로 분할하십시오. 각 세트마다 소유자, 타입, 클래스, 섹션, 관찰된 TTL, 존 컷, 관할 범위를 보존하십시오. 정보가 있는 경우 출처가 로컬 존 데이터였는지, 전송인지, 캐시인지, 글루인지, 새로운 해석인지 기록하십시오. 재귀 클라이언트는 권위 서버의 내부 출처를 알 수 없으므로 불확실성은 AA로 메우는 것이 아니라 명시적으로 남겨 두어야 합니다.

AA 닻은 별도로 저장하십시오. 원래 질의 이름, 첫 Answer 소유자, 응답자, 응답자가 권위자로 간주된 존이 그 대상입니다. 모든 별칭 전환과 후속 질의를 기록하십시오. 추천(referral)의 경우 부모 NS RRset, 글루 주소, 자식 질의, 이후의 권위 있는 자식 답을 연결되어 있지만 독립적인 수신 기록으로 유지하십시오.

마지막으로 RRset별 DNSSEC 상태와 검증 증거를 붙이십시오. 서명, 신뢰 닻 경로, 검증 시각, 정책, 실패 사유를 보존하십시오. 수신한 AD 플래그는 상위의 주장으로만 유지하고 로컬 검증의 대체물로 두지 마십시오. 애플리케이션이 결과를 소비할 때 어떤 RRset과 어떤 캐시 세대를 사용했는지 기록하십시오.

그러면 최종 진술은 정확해질 수 있습니다. 이 서버가 이 첫 소유자에 대해 AA를 설정했고, 이 RRset은 이 섹션과 출처에서 왔으며, 이 검증기가 이 보안 상태를 부여했고, 이 후속 질의가 다음 이름에 대한 권위를 확립했거나 확립하지 못했고, 이 애플리케이션이 이 결과를 사용했다. 하나의 비트가 더 이상 전체 응답을 대변하도록 강요되지 않을 때, 그 비트는 여전히 가치를 갖습니다.

출처