요약

  • draft-gould-regext-epp-server-validation-00는 동기, 비동기, 예약 서버 검증을 위한 공통 EPP 컨테이너를 제안하지만, 검증 유형은 서버 정책으로 정의되고 그 날짜, 트리거, 전이 이력, 실패 사유는 선택 사항입니다.
  • 이진 값은 마지막 검증이 성공했는지 실패했는지만 보고합니다. 그것만으로는 무엇이 검증되었는지, 어느 관찰 지점에서, 어떤 입력에 대해, 결과가 얼마나 유효한지, 또는 이후 poll 메시지가 수신되어 처리되었는지를 입증하지 못합니다.
  • 운영자는 판정을 정책 버전, 검증 정의, 관찰 지점, 입력, 실행 시각과 전이 시각, 트리거, 수신자, poll 식별자, 확인 및 복구 증거에 결합하는 검증 상태 접수증이 필요합니다.

녹색 표시는 빠르게 답하고 쉽게 통제합니다. 워크플로우를 해제하고, 경보를 잠재우고, 고객을 안심시킬 수 있습니다. 그 편의가 곧 위험입니다. "성공"이라는 라벨은 그것을 참으로 만든 조건을 벗어 버립니다.

EPP용 Server Validation Extension의 첫 버전은 실제 조율 문제를 해결하려 합니다. 레지스트리는 DNS 해석이나 DNSSEC 같은 관리 대상 주체 주변의 조건을 검증할 수 있습니다. 오늘날 이러한 결과는 독자적 방식으로 노출되거나 전혀 노출되지 않습니다. 이 초안은 변환 명령에 대한 응답에 즉시 나타나거나, 이후 poll 메시지를 통해, 또는 info 응답에서 요청에 따라 나타날 수 있는 구조화된validationData요소를 정의합니다.

이 공통 봉투는 가치가 있습니다. 그러나 공통 검증 정책은 아닙니다.type값은 명시적으로 서버 정책에 맡겨져 있습니다.dns와dnssec은 예시일 뿐입니다. 초안은status에 마지막 성공한 검증을 뜻하는 success와 마지막 실패한 검증을 뜻하는 failed 두 값만 부여합니다. 무엇이 DNS 해석으로 간주되었는지, 어떤 리졸버 경로가 사용되었는지, 어떤 DNSSEC 체인과 알고리즘이 수용되었는지, 재시도가 어떻게 처리되었는지, 결과가 언제 만료되는지는 이 두 토큰 밖에 있습니다.

선택적인 시계가 이 주장의 중심입니다

초안은 검증이 실행된 시각, 그것을 유발한 변환 작업, 마지막 이전 성공, 첫 실패, 복구 전 마지막 실패를 담을 수 있습니다. 이들 필드는 모두 선택 사항입니다. 실패에는 하나 이상의 서버 고유 사유가 포함될 수 있고, 언어 태그가 함께 붙을 수 있습니다. 이 구조는 풍부한 시간 서사를 담을 수 있지만, 모든 구현이 그렇게 하도록 요구하지는 않습니다.

그래서 생략은 의미를 갖습니다. 검증 날짜 없는 "성공"은 지금 관찰된 성공과 동등하지 않습니다.lastSuccess없는 실패 결과는 그 주체가 항상 실패했는지 아니면 어제 악화되었는지를 말할 수 없습니다.lastFailed없는 복구 결과는 사건의 지속 기간과 반복 여부를 지웁니다. 트리거하는 변환 없는 비동기 검증은 작업을 의도적으로 생략하는데, 이는 맞지만 운영자는 그것이 스케줄에서, 수동 개입에서, 아니면 다른 서버 정책에서 비롯된 것인지 알아야 합니다.

DNS에서 시간은 장식적 메타데이터가 아닙니다. 레코드, 서명, 위임, 리졸버 캐시, 네트워크 경로는 변합니다. RFC 4035는 DNSSEC 검증자 동작을 규정하지만, 이 확장의 유형화된 결과는 여전히 자체 정책 아래에서 특정 서버가 생성합니다. 한 검증은 그 관찰 지점에 대해서는 정확할 수 있지만, 레지스트라가 곧 내리려는 결정에 대해서는 낡았을 수 있습니다.

따라서 올바른 독해는 "서버가 기록한 검증 유형 X의 마지막 실행은 success를 반환했다"이지, "이 도메인은 건강하다"가 아닙니다. 후자는 스키마에 없는 연속성, 포괄성, 인증을 조용히 덧붙입니다.

동기적 진실과 비동기적 진실은 다른 보관 계정을 갖습니다

검증이 동기적이면 결과는 그것을 유발한 EPP 응답과 함께 전달됩니다. 클라이언트는 결과와 함께 클라이언트·서버 트랜잭션 식별자를 보존할 수 있습니다. 검증 정의가 여전히 서버 정책에서 나오긴 하지만, 작업과의 관계는 비교적 직접적입니다.

비동기 및 예약 결과는 EPP poll 큐로 들어갑니다. RFC 5730은 그 큐를 순차적이고 클라이언트 고유로 만듭니다. poll 요청은 고유한 메시지 ID와 큐 개수와 함께 첫 메시지를 반환합니다. 클라이언트는 수신을 확인(acknowledge)해야 하며, 그때 서버는 메시지를 제거하고 다음 메시지를 노출합니다.

그 확인은 전달 사건입니다. 복구 사건이 아닙니다. 클라이언트는 실패를 파싱했을 수도, 내부적으로 라우팅하지 못했을 수도, 운영자가 보기 전에 확인했을 수도 있습니다. 예약된 성공→실패 전이는 무관한 메시지 뒤에 대기할 수 있습니다. 큐 압박은 다른 전달 경로에 영향을 줄 수 있습니다. 검증 타임스탬프, 큐 삽입 시각, 검색 시각, 확인 시각은 서로 다른 지연을 기술하며 하나의 "통지 시각"으로 압축되어서는 안 됩니다.

이 제안된 확장은 poll 응답에 검증 데이터를 추가하지만 poll 명령 자체는 바꾸지 않습니다. EPP의 재사용으로서 타당합니다. 동시에 신호의 내구성이 기존 큐 규율에 의존한다는 뜻이기도 합니다. 메시지를 확인한 뒤 버리는 레지스트라는 전송 프로토콜을 지켰지만 거버넌스 기록은 잃었습니다.

수신자가 증거를 바꿉니다

보안 절은 또 하나의 정책 경계를 명시합니다. 서버는 스폰서 클라이언트와 비스폰서 클라이언트에 제공할 정보를 선택하며, 실패 사유는 스폰서 클라이언트에만 공개할 수 있습니다. 이는 무단 접근자에게 유용할 수 있는 운영 세부를 보호합니다. 동시에 같은 주체에 대한 두 개의 승인된 관점이 서로 다른 증거를 담을 수 있음을 의미합니다.

공개 또는 비스폰서 관찰자는 서버 고유 사유 없이 failed만 볼 수 있습니다. 스폰서 레지스트라는 누락된 DNSKEY 세부를 받을 수 있습니다. 어느 응답도 반드시 거짓은 아닙니다. 둘은 서로 다른 공개 정책에 답합니다. 따라서 감사는 수신자 등급을 기록해야 하며, 그러지 않으면 나중의 비교에서 통제된 편집을 검증 불일치로 오인할 수 있습니다.

사유 자체를 안정된 코드로 오인해서는 안 됩니다. 현 초안에서 그것은 선택적인 서버 고유 텍스트입니다. 현지화되고 반복될 수 있습니다. 사람의 문제 해결에는 도움이 되지만, 기계는 문구를 긁어 내며 내구성 있는 범주를 추론해서는 안 됩니다. 상호운용 가능한 복구 라우팅이 필요하다면 별도로 통제되는 사유 분류 체계 또는 버전 이력이 있는 문서화된 로컬 매핑이 필요합니다.

모든 변환은 검증 그림자를 가질 수 있습니다

초안은 create, renew, transfer, update, 그리고 주체를 즉시 소멸시키지 않는 deletion을 다룹니다. restore, 자동 갱신, 자동 삭제, 서버 정책으로 정의된 사용자 지정 작업도 인식합니다. transfer는 request, approve, cancel, reject 같은 하위 작업을 필요로 하고, restore는 request와 report를 구분합니다. 확장이 변환 요청에 새 요소를 추가하지 않음에도 동기 데이터는 변환 응답에 나타날 수 있습니다.

이 분리는 클라이언트가 서버가 검증했다고 주장할 내용을 지정하는 것을 막습니다. 동시에 서버에 검증이 언제 실행되는지에 대한 광범위한 재량을 줍니다. 한 레지스트리는 create 이후와 스케줄에 따라 DNSSEC을 검증할 수 있고, 다른 레지스트리는 update에서만 검증할 수 있으며, 셋째는 사용자 지정 검사를 정의할 수 있습니다. 모두 같은success토큰을 직렬화할 수 있습니다.

따라서 비교 가능성에는 스키마 적합성 이상이 필요합니다. 정책을 비교하지 않고 레지스트리 간 success를 세는 조달 보고서는 서로 다른 검사를 같은 순위로 매길 수 있습니다. 날짜 없음을 현재로 취급하는 서비스 수준 대시보드는 가장 정보가 적은 구현에 보상할 수 있습니다. 스폰서 클라이언트 세부를 공개 증거와 동등하게 취급하는 컴플라이언스 프로그램은 과다 공개하거나 과다 주장할 수 있습니다.

검증 상태 접수증이 빠진 차원을 보존합니다

저는 검증 상태 접수증을 제안합니다. 이는 초안의 일부가 아닙니다. 이진 상태를 다른 결정을 통제하는 데 사용하기 전에 필요한 최소 증거 묶음입니다.

첫 블록은 검사를 식별합니다: 검증 유형, 서버 정책 버전, 규범적 또는 로컬 정의, 수용된 알고리즘, 재시도 논리, 리졸버 또는 네트워크 관찰 지점, 정확한 입력 집합. DNSSEC의 경우 비밀이나 재사용 가능한 공격 경로를 공개하지 않으면서 체인과 트러스트 앵커 맥락을 포함할 수 있습니다.

둘째 블록은 시간과 원인을 식별합니다: 실행 시각, 유발한 변환과 하위 작업, 또는 예약/수동 기원. 가능하면 마지막 성공, 첫 실패, 마지막 실패를 기록하고, 없는 필드는 "없었음"으로 변환하지 않고 알 수 없음으로 표시합니다.

셋째 블록은 보관 계정을 기록합니다: 주체, 수신자의 스폰서 지위, poll 메시지 ID와 개수, 큐 날짜, 검색 시각, 확인 시각, 내부 인계. 사유가 보류되었다면 그렇다고 명시합니다. 텍스트가 현지화되었다면 원래 토큰과 언어가 계속 사용 가능합니다.

마지막 블록은 접수증과 복구를 분리합니다. 티켓, 운영자 결정, 이후 검증, 종결 증거를 기록합니다. poll 확인은 큐 항목을 끝낼 뿐이며, 그 조건이 끝났음을 보여줄 수 있는 것은 이후의 이 증거뿐입니다.

현 문서는 2026년 7월 19일자 개인 Internet-Draft입니다. Datatracker는 그것이 공식 IETF 지위도, 스트림도, 의도된 RFC 지위도 없다고 밝히는 반면, 헤더는 Standards Track이라고 표기합니다. 초안은 향후 IANA 네임스페이스 및 확장 레지스트리 등록을 요청하지만, 그 요청이 이미 존재하는 사실을 만들지는 않습니다. 배포된 합의로 격상시키지 않고 그 아이디어를 검토할 가치가 있습니다.

출처