요약

  • 한 클라이언트가 도메인과 그 하위 호스트를 관리하면서, 다른 클라이언트의 도메인이 같은 호스트에 의존해 해석되는 상황이 있을 수 있습니다.
  • 그 호스트를 비어 있다고 여겨지는 이름으로 바꾸거나 권한 없는 리졸버로 옮기면 위험을 다른 곳으로 이전할 뿐입니다. RFC 9874는 이러한 관행을 금지합니다.
  • 클라이언트 간 삭제 영수증은 명령 수락, DNS 영향, 영향을 받는 클라이언트에 대한 통지, 복구 가능성, 비동기 삭제 완료를 구분해야 합니다.

시나리오는 단순해 보입니다. 클라이언트 X는domain1.example을 삭제하려 합니다. X는ns1.domain1.example도 관리합니다. 그러나 클라이언트 Y는 이 호스트를domain2.example의 네임서버로 사용합니다. X는 자신의 객체를 관리할 수 있지만, Y의 도메인을 수정할 수도 없고, 연관 관계 전체를 볼 수 있는 것도 아닙니다. 반면 EPP 서버는 그래프 전체를 알고 있습니다.

서버가 성공을 반환했다면, 무엇을 증명한 것일까요? 요청이 서버 정책에 따라 수락되었다는 사실입니다. Y의 도메인에 여전히 건전한 위임이 남아 있다는 것, Y가 통지를 받았다는 것, 롤백이 가능하다는 것, 모든 지연 작업이 끝났다는 것은 자동으로 증명되지 않습니다.

권고 사항은 세 가지 일관성을 보호한다

RFC 5731은 하위 호스트가 연관된 상태에서 도메인을 삭제하지 말 것을 권고합니다. RFC 5732는 다른 객체가 아직 참조하는 호스트를 삭제하지 말 것을 권고합니다. 첫 번째 이유는 DNS입니다. 상위 도메인을 제거하면 호스트를 찾을 수 없게 되고, 호스트를 제거하면 의존하는 도메인에 접근할 수 없게 될 수 있습니다.

두 번째 이유는 클라이언트와 서버 사이의 일관성입니다. 암묵적 삭제는 클라이언트에게 레지스트리와 다른 상태 표현을 남깁니다. 세 번째는 관계적 이유입니다. 레지스트리 데이터베이스는 도메인과 호스트 사이에 무결성 링크를 강제할 수 있습니다. 이 세 가지 층은 같은 시점에 닫히지 않습니다.

문제는 권한이 분할되어 있을 때 나타납니다. Y만이 자신의 도메인 네임서버를 교체할 권한이 있습니다. 그런데 Y가 의존하는 객체의 삭제를 요청하는 쪽은 X입니다. 모든 작업을 거부하면 X를 묶어 두고, 예방책 없이 실행하면 비용을 Y에 전가합니다.

희생적 이름은 안전장치지 쓰레기통이 아니다

어떤 클라이언트는 호스트 이름을 바꿔 삭제할 도메인 밖으로 옮기기도 합니다. 새 호스트를 희생적 호스트라고 부릅니다. 이 기법은 의존 관계를 파괴하지 않고 다른 수호자에게 넘겨줄 뿐입니다.

존재하지 않을 것이라고 여겨지는 외부 도메인을 고르는 것은 매력적입니다. X는 아무것도 운영하지 않아도 되기 때문입니다. 그러나 바로 이 점이 위험을 만듭니다. 제3자가 상위 도메인을 등록해 여전히 연관된 도메인들의 트래픽을 가로챌 수 있습니다. RFC 9874는 이 관찰된 관행을MUST NOT으로 규정합니다.

호스트를 대규모 재귀 DNS 서비스로 가리키는 것은 권한을 만들지 않습니다. 쿼리는SERVFAIL을 받을 수 있고, 일부 리졸버가 이를 공격적으로 반복할 수 있습니다. 이 관찰된 관행 역시 금지됩니다.

인정되는 희생적 해법은 반대로 클라이언트가 상위 도메인을 유지하고, 공개된 주소로 권한 있는 서버를 운영하는 것을 요구합니다. 이는 기회적 인수를 막지만, 일회성 삭제를 지속적인 의무로 바꿉니다. 도메인 만료, 서비스 종료 또는 통제권 상실은 명령 이후 오랜 시간이 지나 위험을 되살릴 수 있습니다.

복구는 통제 가능한 기간을 만든다

다른 아키텍처는 도메인을 명시적으로 삭제하면서 다른 클라이언트와의 연관 관계를 처리할 수 있게 합니다. 서버는 실행 전에 영향을 상세히 설명할 수 있습니다. 영향을 받는 클라이언트에게 통지할 수 있으며, 특히 EPP Change Poll 확장을 통해 가능합니다. 무엇보다, RFC 3915의 유예 기간 동안 도메인, 하위 호스트, 그 연관 관계를pendingDelete상태로 유지할 수 있습니다.

DNS는 삭제의 맛보기를 보여줄 수 있고, 구조는 여전히 복구 가능합니다. 작업이 실수, 악의 행위 또는 예상보다 파괴적이었다면, 기한 전에 복구가 링크를 재구성할 수 있습니다. 이 기간이 지나서야 삭제가 최종 확정됩니다.

이 기간이 작업을 작게 만들지는 않습니다. RFC 9874는 연관 관계 수에 어떤 한계도 두지 않는다고 밝힙니다. 따라서 비활성화, 재활성화, 삭제 완료는 비동기 작업으로 나눌 수 있습니다. 즉시 응답은 결코 전체 종료 증명서로 쓰여서는 안 됩니다.

영수증은 세션이 아니라 그래프를 따른다

최소 영수증은 트랜잭션 식별자, 인증된 클라이언트, 대상 객체, 서버 정책, 클라이언트 간 효과를 가능하게 하는 권한으로 시작합니다. 다음으로 의존 관계의 시점 표본을 기록합니다. 열거 날짜와 방법, 하위 호스트, 영향을 받는 도메인 수, 공개가 적법할 때 해당 클라이언트, 그리고 가시성 한계입니다.

이전과 이후의 DNS 상태도 보관합니다. 이름, 주소, 권한 상태, DNSSEC 및 DS 조건, 선택된 RFC 9874 관행입니다. 경고, 요청자에게 전달된 세부 사항, 있었던 승인, 정확한 결정을 첨부합니다. 그 다음은 통지입니다. 큐 등록, 전달, 확인 또는 확인 부재입니다. 단, 등록자의 개인 데이터를 노출하지는 않습니다.

마지막으로, 환불(redemption) 기한, 복구 권한, 롤백 테스트, 지연 작업 식별자, 부분 실패, DNS에서의 최종 확인을 기록합니다. 기밀 유지는 계정이나 불투명 참조를 요구할 수 있습니다. 그러나 의존 관계의 존재 자체를 모르게 두는 것을 정당화하지는 않습니다.

이 영수증은 Daniel Kade가 제안한 운영 아이디어입니다. EPP 확장도 아니고, RFC에 추가된 의무도 아닙니다.

DNSSEC도 수호자의 품질에 달려 있다

DNSSEC와 여러 네임서버는 일부 위험을 줄일 수 있습니다. 그러나 나쁜 전환을 좋은 전환으로 바꾸지는 못합니다. RFC 9874는 DS 자동화 메커니즘이 모든 서버의 일관성을 검증하지 않을 때, 단일 서버를 장악한 공격자가 CDS 또는 CDNSKEY 레코드에 영향을 미치는 사례를 기술합니다. 이어서 CSYNC가 합법적 서버를 제거하는 데 도움을 줄 수 있습니다.

따라서 DS 자동화 상태, 조회된 서버, 응답의 일치 여부, 변경을 수락한 권한을 기록해야 합니다. “DNSSEC 활성”이라는 표기는 능력을 설명할 뿐, 수호자 교체의 안전을 증명하지 않습니다.

모든 성공을 검증 가능하게 만들기

RFC 9874는 클라이언트가 유지하는 권한 있는 희생 서비스, 세부 사항·통지·복구를 갖춘 명시적 삭제, 또는 특수 용도 도메인에 대한 맞춤 접근 중 하나를 권고합니다. 그 문서는 비용을 미래 등록자, 리졸버 또는 외부 인프라에 전가하는 지름길을 거부합니다.

삭제 자체는 금지되지 않습니다. 사라져야 하는 것은 모든 것을 요약한다고 주장하는 한 문장입니다. “명령 수락됨”, “클라이언트 통지됨”, “위임 통제 중”, “복구 가능”, “삭제 완료”는 다섯 가지 서로 다른 상태입니다. 각각 자신의 증명과 자신의 시계를 가져야 합니다.

출처