요약

  • DNS의 일반 응답 코드는 서로 다른 많은 실패를 같은 결과로 압축한다. RFC 8914는 EDNS 옵션 15에 등록된INFO-CODE와 선택적 사람용EXTRA-TEXT를 배치하여 서버가 RCODE를 대체하지 않고도 원인을 설명할 수 있게 했다.
  • EDE는SERVFAIL,NXDOMAIN,REFUSED또는NOERROR조차 수반할 수 있으며 여러 EDE 옵션이 공존할 수 있다. 애플리케이션은 여전히 일반 RCODE를 자체 명세에 따라 처리해야 하며, 진단이 낡거나 위조되거나 인증되지 않은 맥락을 프로토콜 권한으로 승격시킬 수 없다.
  • 새로운 가시성은 그 자체의 보관(custody) 문제를 만든다. 포워더가 설명을 중계할지 재생성할지 결정하고, 과대 응답은 필수 데이터보다 먼저 EDE를 폐기하며, 자유 텍스트는 정책이나 계정 정보를 누설할 수 있고, 공격자는 보호되지 않은 진단을 위조할 수 있다.

02시 13분, 운영자는 실패한 이름 조회를 마주한다. 재귀 리졸버는SERVFAIL을 기록했다. 그녀는 존의 권한 서버, 네트워크 경로, DNSSEC 서명을 점검한다. 수송을 고치거나 서명된 데이터를 고치라는 다섯 비트짜리 운영 질문이 하나의 결과로 압축되었기 때문이다.

02시 16분, 다른 이름이 같은 코드를 내놓는다. 이번에는 모든 권한 서버가 응답하지만 서명이 만료되었다. 다른 검증 리졸버로 재시도하면 같은 거부가 나와야 한다. 검증하지 않는 리졸버로 재시도하면 주소가 반환될 수 있지만, 그 겉보기 복구는 존을 수복한 것이 아니라 보안 경계를 넘어선 것이다.

두 패킷은 결과에 대해서는 일치한다. 사용 가능한 답이 반환되지 않는다는 점이다. 그러나 원인, 안전한 다음 검증, 그리고 이를 고칠 수 있는 주체에 대해서는 불일치한다. 고전 DNS에는 결과를 담을 공간은 있었지만 그 구별을 담을 여지는 거의 없었다.

작은 결과 필드가 너무 많은 이력을 담았다

RFC 1035는 익숙한 응답 헤더를 정의했다. RCODE 값은 오류 없음, 형식 오류, 서버 실패, 존재하지 않는 도메인, 미지원 연산, 거부 같은 넓은 결과를 서술한다. 이 압축 문법은 모든 리졸버가 서버 내부 구조를 모르고도 같은 첫 결정을 내릴 수 있기 때문에 가치가 있다.

그러나 압축은 증거를 지운다. 서버는 존을 아직 적재 중이거나, 모든 권한 목적지에 도달할 수 없거나, 캐시된 실패 상태가 활성 상태로 남아 있거나, DNSSEC 증명이 불완전하거나, 정책이 답을 금지하기 때문에 실패할 수 있다.SERVFAIL은 이런 인과 분기를 인코딩하지 않는다.REFUSED도 마찬가지로 서버가 권한을 갖지 않은 것인지, 이 클라이언트를 거부하는 것인지, 필터링 규칙을 적용하는 것인지 말해주지 않는다.

애플리케이션은 추측으로 이 공백을 메웠다. 스텁은 검증 관련SERVFAIL이후 다음 설정 리졸버에게 물을 수 있다. 그 다음 리졸버가 DNSSEC을 검증하지 않는다면 애플리케이션은 첫 리졸버가 올바르게 거부한 데이터를 받을 수 있다. 도달성이 개선된 것은 클라이언트가 볼 수 없는 보안 증거를 버렸기 때문이다.

결함은 RCODE가 틀렸다는 것이 아니었다.SERVFAIL은 올바른 상호운용 가능한 결과로 남았다. 빠진 계층은 결과의 의미를 바꾸지 않으면서 진단을 안내할 수 있는 설명이었다.

EDNS는 새 답이 아니라 사이드 채널을 제공했다

RFC 6891은 이미 OPT 가상 레코드와 옵션 레지스트리를 만들었다. OPT는 DNS 메시지에 실리지만 일반 존 데이터가 아니다. 오래된 모든 필드를 늘리지 않으면서 기능과 메타데이터를 위한 유계 확장 표면을 제공한다.

2020년에 발행된RFC 8914는 EDNS 옵션 15를 확장 DNS 오류(Extended DNS Error)에 할당했다. 옵션 페이로드는 16비트INFO-CODE로 시작한다. 나머지 옥텟은 선택적 UTF-8EXTRA-TEXT를 이룬다.

이 분할은 의도적이다. 숫자 코드는 레지스트리를 색인하고 안정적인 분류를 지원할 수 있다. 자유 텍스트는 특정 키가 만료되었다거나 실패의 업스트림 출처를 말할 수 있지만, 사람이 읽기 위한 것이다. 프로그램이 문장을 마치 두 번째 프로토콜처럼 파싱해서는 안 된다.

이 옵션은 쿼리에 OPT 레코드가 실렸다면SERVFAIL,NXDOMAIN,REFUSED,NOERROR등 다른 응답 코드와 함께 나타날 수 있다. 하나의 응답에 여러 EDE가 나타날 수 있다. 수신자는 이들을 모두 수용할 수 있어야 하지만, 모두에 대해 행동할 필요는 없다.

가장 중요한 점은 EDE가 RCODE 처리를 변경하지 않는다는 것이다.NOERROR와Stale Answer를 받은 애플리케이션은 여전히 만료 이력이 중요한 답을 가진다.SERVFAIL과DNSSEC Bogus를 받은 클라이언트는 여전히 실패를 겪고 있다. 설명은 조사 범위를 좁히지만 결과를 다시 열지 않는다.

하나의 코드가 검증 실패를 불확실성과 분리했다

DNSSEC 코드는 정밀성이 왜 중요했는지 보여준다.RFC 4035는Bogus를Indeterminate와 구별한다. Bogus 데이터는 신뢰 사슬이 구성 가능해야 하지만 검증할 수 없는 데이터다. 원인은 공격, 구성 오류, 손상일 수 있다. Indeterminate 데이터는 다르다. 리졸버가 필요한 DNSSEC 레코드를 얻을 수 없어 서명 적용 여부를 판단할 수 없는 것이다.

RFC 8914는 이 상태들에 별도의 진단 번호를 부여했다. 또한 미지원 DNSKEY 알고리즘, 미지원 DS 다이제스트 유형, 만료된 서명, 아직 유효하지 않은 서명, 누락된 DNSKEY 또는 RRSIG 레코드, 설정되지 않은 존 키 비트, 누락된 NSEC 증거에 대한 코드도 제공했다.

이 어휘는 책임을 증명하지 않는다.DNSSEC Bogus는 공격자가 존을 소유한다는 판정이 아니다. 리졸버가 도달한 검증 상태가 무엇인지 말한다. 해결책은 존 운영자, 등록기관, 부모 존, 시계 소스, 소프트웨어 구현 또는 필요한 레코드를 잃은 경로에 있을 수 있다.

이 구별은 안전한 복구를 바꾼다. 다른 검증 리졸버는 조건이 국소적인지 시험할 수 있다. 비검증 답은 실패를 반증하지 못한다. 그저 같은 증명 요구를 거부할 뿐이다. EDE는 클라이언트나 운영자가 더 약한 검증을 성공적인 수복으로 오해하지 않도록 그 선택을 충분히 가시화한다.

성공은 시간에 대한 경고를 실을 수 있었다

EDE는 실패 응답만을 위해 설계된 것이 아니다. 재귀 리졸버는 정상 만료 전에 데이터를 갱신하지 못하면서도, 답이 없는 것보다 오래된 캐시 답을 선호하도록 결정할 수 있다.RFC 8767은 그 복원력 메커니즘에 경계를 둔다. EDE 코드 3은 낡은 긍정 답을, 코드 19는 낡은 NXDOMAIN을 표시한다.

따라서 일반 결과는NOERROR이면서도 경고를 실을 수 있다. 이것은 모순이 아니다. RCODE는 현재 응답 클래스를 서술하고, EDE는 그것이 만들어진 출처나 조건을 서술한다. 레코드는 리졸버가 연속성을 선택했다고 해서 새로워지지 않는다.

같은 분리가 코드 4인Forged Answer에도 적용된다. RFC 8914는 정책이 답을 변경시켰음에도 답이 여전히 반환되는 경우 이를 사용한다. 정책이 대신 답을 막는다면 다른 코드가 경계를 누가 부과했는지 서술한다. 리졸버 운영자의 내부 보안 정책에는Blocked, 외부 요구에는Censored, 클라이언트가 요청한 필터링에는Filtered가 쓰인다.

이 라벨은 응답 시스템이 내놓는 진단적 단정이다. 그들은 제도적 통제를 드러낼 수 있지만, 법원 명령을 인증하거나 위협 분류를 증명하거나 모든 중개자가 용어를 올바르게 사용했음을 확립하지는 않는다.

캐시된 실패가 출처를 갖게 되었다

캐시될 수 있는 DNS 상태는 답만이 아니다. 모든 새 클라이언트가 비용이 큰 실패한 작업 사슬의 반복을 강제하지 않도록 조회 실패를 잠시 보관할 수 있다.RFC 9520은 실패 캐싱을 명시적이고 유계로 만든다.

EDE 코드 13인Cached Error는 반환된SERVFAIL이 이런 캐시 상태에서 왔음을 클라이언트에게 알린다. 그 실패를 권위 있는 존 데이터로 만들지는 않는다. 같은 리졸버에서 즉시 반복하면 실패하는 업스트림 경로가 아니라 캐시를 작동시킬 수 있음을 운영자에게 알린다.

이것은 미묘하지만 유용한 구별이다. 신선한 실패와 캐시된 실패는 동일한 RCODE를 실을 수 있으나, 새 조회 시도를 반드시 대표하는 것은 하나뿐이다. 그 출처 정보 없는 관측은 재시도 폭풍을 반복되는 독립적 증거처럼 보이게 할 수 있다.

포워딩은 발화자를 모호하게 만들었다

스텁 리졸버는 흔히 로컬 재귀 리졸버와 통신하고, 그 리졸버는 권한에 접촉하기 전에 다른 리졸버로 포워딩할 수 있다. 따라서 에지에서 관찰된 EDE에는 여러 가능한 저자가 있다.

RFC 8914는 포워딩 정책을 국소적으로 남겨둔다. 리졸버는 받은 EDE를 억제하거나, 그대로 전달하거나, 정보를 전달하는 새 옵션을 만들 수 있다. 의미를 포워딩한다면EXTRA-TEXT에 출처를 밝혀야 한다. 그렇지 않으면 클라이언트는 그 즉시 리졸버가 발생시킨 것처럼 옵션을 본다.

그러므로 설명은 DNS 답의 익숙한 섹션보다 약한 보관 사슬을 가진다. 숫자 코드는 출처가 모호해지는 동안 살아남을 수 있다. 자유 텍스트가 귀속을 회복할 수 있지만, 자유 텍스트는 기계 문법도 아니고 자동 인증도 아니다.

여러 EDE 옵션은 계층화된 원인을 보존할 수 있다. 업스트림 검증 결함, 캐시된 로컬 실패, 다운스트림 정책 결정은 하나의 숫자로 붕괴될 필요가 없다. 수신자는 여전히 어느 계층을 신뢰하고 어느 주체가 수복할 수 있는지 결정해야 한다.

보충 증거는 혼잡한 패킷에서 가장 먼저 떠났다

DNS에는 여전히 크기 한계가 있다. 긴 사람용 설명을 실은 EDE는 UDP 응답을 요청자가 광고한 페이로드 크기를 넘어설 수 있다. RFC 8914는 서버에게 다른 응답 데이터를 버리기 전에 EDE 옵션을 버리고 그렇게 할 때 단편화(truncation) 비트를 설정하라고 지시한다.

이 우선순위는 그 계약을 정확히 표현한다. 진단은 유용하지만 답과 그 증명이 더 중요하다. 단편화 이후 사라진 EDE는 서버에 진단이 없었다는 증거가 아니다. 긴 산문은 TCP 폴백을 강제하거나 크기 경계에서 사라짐으로써 스스로 제공하려던 가시성을 파괴할 수 있다.

따라서 운영자는 간결한 코드, 유계 텍스트, 그리고 EDE가 생성되었는지, 포워딩되었는지, 교체되었는지, 생략되었는지 기록하는 로그가 필요하다. 패킷 캡처만으로는 최종 부재는 관찰할 수 있어도 이전의 결정은 볼 수 없다.

설명은 구체적이라고 해서 인증된 것이 아니었다

구체적인 언어는 권위 있게 느껴진다. "서명이 만료되었다"거나 "외부 요구에 따라 차단되었다"는 응답은 불투명한 실패보다 더 신뢰할 만해 보일 수 있다. 유선은 그 신뢰를 부여하지 않는다.

RFC 8914는 DNS 트랜잭션이 인증 메커니즘이나 보안 전송으로 보호되지 않는 한 EDE는 인증되지 않는다고 경고한다. EDE를 위조할 수 있는 경로상 공격자나 악의적 리졸버는 RCODE나 일반 답도 위조할 수 있다. EDE는 진단으로 남아야 하며 DNS 프로토콜 처리를 바꿔서는 안 된다.

텍스트는 프라이버시 위험도 만든다. 계정 번호, 내부 업스트림, 차단 목록 결정, 그렇지 않으면 관찰할 수 없는 정책의 존재를 노출할 수 있다. 더 많은 설명이 자동으로 더 많은 책임은 아니다. 유용한 기록은 무관한 비공개 상태를 공개하지 않으면서 다음 검증과 책임 있는 통제 표면을 선택할 만큼 충분히 말한다.

IANA DNS 파라미터 레지스트리는 옵션 15와 진화하는 INFO-CODE 할당을 기록한다. 식별자와 참조가 조율되었음을 증명한다. 그러나 리졸버가 이를 발행하고, 충실하게 포워딩하고, 전송을 보호하고, 사용자에게 보여주고, 실패를 올바르게 분류한다는 것은 증명하지 않는다.

확장 DNS 오류는 특이한 규율로 좁은 역사적 문제를 해결했다. DNS는 더 표현력 있는 실패 증거를 필요로 했지만, 편리한 설명이 두 번째 답이 되도록 허용될 수는 없었다. RCODE는 처리에 대한 권한을 유지했다. EDE는 맥락을 실었다. 이 분리는 진단 신뢰를 그것을 전달한 채널보다 강하게 만들지 않으면서 실패를 더 쉽게 수복 가능하게 만들었다.