요약

  • 공개 기록은 ZDNS의 네트워크 및 논리적 서비스 존재에 대해 중간 등급의 근거를 뒷받침합니다. 이 회사는 2026년 ICANN 평가 기록에 등재되어 있고, 8개의 위치 의존 지점을 명시하며, 가시적인 듀얼 스택 라우팅 표면을 운영하고, 식별 가능한 최상위 도메인 위임을 서비스하고 있습니다.
  • ZDNS 귀속으로 확인할 수 있는 물리적 용량과 사용 가능한 페일오버 여유에 대한 근거는 약합니다. 공개된 732랙 부속 시설은 호스트 시설을 설명할 뿐 ZDNS의 할당분이 아니며, 검토된 자료에는 설치 재고, 예비 재고, 사이트 부하 또는 최대 사이트 상실 시나리오 결과가 제시되지 않습니다.
  • 진지한 구매자는 사이트를 기능, 장비, 트래픽, 철수 동작, 복원 테스트, DNSSEC 비상 절차, 에스크로 검증 및 달성된 복구 목표와 연결하는 날짜가 기재된 근거를 요구해야 합니다. 애니캐스트, 매일의 예탁금과 문서화된 통제는 유용한 역량이지만, 그것만으로는 복구 능력을 입증하지 못합니다.

중요한 질문은 “네트워크가 존재한다” 이후에 시작됩니다

ZDNS가 실제로 중대한 인터넷 대면 서비스를 운영하고 있음을 확립하는 데 사용할 수 있는 공개 자료는 넉넉합니다.2026년 평가 대상 신청 목록은 ZDNS가 국제화 도메인 이름 지원을 포함하여 Main, DNS, DNSSEC 및 Proxy 서비스 유형에 대해 통과된 것으로 기록합니다. 관련된ICANN 프로그램 페이지는 그 평가가 놓인 맥락을 설명합니다. ZDNS의 자체 페이지는 레지스트리 기능과 폭넓은 DNS 포트폴리오를 설명하고, 라우팅 관측은 살아 있는 듀얼 스택 표면을 보여줍니다. 이것들은 의미 있는 신호이며, 기본적인 존재 여부 질문에 답합니다.

그러나 더 어려운 운영 질문에는 답하지 않습니다. 주요 의존 요소가 사라지면 무엇이 사용 가능한 상태로 남는가?

이 구분이 중요한 이유는, 전체 시스템의 놀랍도록 얇은 부분만으로도 전 세계적으로 가시적인 DNS 응답을 만들어낼 수 있기 때문입니다. 라우팅은 뒤에 있는 서버 수, 그 서버들을 지탱하는 전력 예약, 사이트의 예비 포트 또는 제어 평면이 손상된 상태에서 복구할 수 있는 능력을 드러내지 않고 쿼리를 이용 가능한 엔드포인트로 유도할 수 있습니다. 레지스트리는 매일 데이터를 예탁하면서도 복구 팀이 최근에 예탁 데이터를 복호화, 적재, 정합성 확인했음을 입증하지 않습니다. 위치 목록은 8개의 행을 나열하면서 8개의 독립적인 장애 도메인을 보여주지 않습니다. 인증서는 수백 개의 랙을 설명하면서 ZDNS가 그 중 하나라도 점유하고 있음을 입증하지 못합니다.

따라서 올바른 실사 질문은 “ZDNS에 글로벌 인프라가 있는가?”가 아닙니다. 공개 기록은 글로벌하게 가시적인 논리적·네트워크적 존재를 갖고 있다고 말할 만한 충분한 근거를 제공합니다. 더 나은 질문은 다음과 같습니다. 그 존재 중 얼마나를 ZDNS 귀속의 물리적 자산, 사용 가능한 페일오버 용량과 입증된 복구에 연결할 수 있는가?

이 틀은 서로 다른 두 개의 근거 등급을 만들며, 둘은 분리된 채 유지되어야 합니다. 네트워크 및 논리적 서비스 근거는 중간입니다. ZDNS 귀속의 물리적 용량과 사용 가능한 페일오버 여유에 대한 근거는 약합니다. 이들을 하나의 안심되는 “용량” 레이블로 합치면 가장 큰 정보 공백이 가려집니다. 도달 가능성이 예비 용량을 대변하고, 서비스 설명이 테스트된 생존 능력을 대변하게 됩니다.

이것은 ZDNS에 장비나 복원력이 없다는 주장이 아닙니다. 검토된 공개 기록으로부터 외부 구매자가 확립할 수 있는 것에 관한 주장입니다. 공시되지 않은 재고의 부재는 재고가 없다는 증명이 아닙니다. 다만 운영자가 날짜가 기재된 사이트별 근거를 제공할 때까지 더 강한 결론을 보류하는 합리적 이유이기는 합니다.

산수에 앞서 귀속이 먼저입니다

자산 보유자, 네트워크 보유자와 서비스 운영자의 신원이 흐려지면 용량 분석은 빠르게 실패합니다. 이 회사의 디렉터리 레이블은AS38345의 APNIC RDAP 기록에서 보이는 철자인 “Resrarch”를 그대로 유지합니다. 현재의 ICANN 신청서에는 바로잡은 법적 이름과 DBA ZDNS가 사용되어 있으며, 회사의연락처 페이지도 현재의 정체성을 뒷받침합니다. 철자 차이는 두 번째 회사를 발명하는 근거가 아닙니다. 디렉터리 계약이 요구하는 곳에서는 보존되고, 서술적 분석에서는 신중하게 다뤄져야 하는 기록 관리상의 잔여 문제입니다.

시점은 두 번째 잔여 문제를 만듭니다. AS38345 등록은 ZDNS가 말하는 2013년 설립보다 앞서며, 오래된APNIC Whois 화면에는 KNET 연락처가 남아 있습니다. ZDNS의회사 개요는 회사와 그 서비스 방향을 설명하지만, 제공된 사실만으로는 모든 과거 필드를 정합적으로 설명해 줄 인수, 전신 합의 또는 소유권 체인을 확립할 수 없습니다. 신중한 평가는 그런 역사를 지어내서는 안 됩니다.

대신 귀속은 한 층씩 이루어져야 합니다. AS38345가 발원한 경로는 관측 시점에 그 자율 시스템과 연관된 네트워크 표면에 대한 추론을 뒷받침합니다. 그 경로를 통해 도달한 서버의 소유자를 자동으로 확립하지는 않습니다. 신청서와 함께 제출된 데이터센터 부속 자료는 공시된 의존 지점의 존재를 뒷받침합니다. 랙 소유권, 임대 수량 또는 독점 사용을 확립하지는 않습니다. 위임 항목의 기술 연락처 항목은 위임된 네임스페이스 주변의 운영 역할을 뒷받침합니다. 엔드포인트 뒤에 있는 계약적 책임 분담을 공시하지는 않습니다.

이 구분은 법적 섬세함 이상의 의미가 있습니다. 그것은 이후의 모든 계산을 지배합니다. 시설 전체 규모를 운영자 할당분으로 취급하면 분석이 시작되기도 전에 랙 수, 전력과 발전기 용량이 과대 계산됩니다. 각 경로 발원지를 별도 소유 사이트로 취급하면 네트워크 다양성이 가정에 의해 물리적 다양성이 됩니다. 공유된 권위적 네이밍 패턴을 고객 전용 인프라로 취급하면 근거 없이 격리를 단언하게 됩니다.

규율 있는 방법은 모든 숫자와 레이블에 대해 세 가지 질문을 던지는 것입니다. 이 기록은 정확히 무엇을 설명하는가? 어떤 주체에 귀속할 수 있는가? 그 근거는 어떤 운영 결론을 허용하는가? 이 방법 하에서 ZDNS 기록은 논리적 서비스와 네트워크 층에서 가장 강합니다. 설치 하드웨어, 예약된 자원과 생존 용량의 층으로 내려가면 훨씬 얇아집니다.

8개의 위치 행은 8개의 독립 사이트가 아니라 의존 지점을 설명합니다

가장 구체적인 지리는ZDNS 데이터센터 부속 자료에서 나옵니다. 여기에는 8개의 행이 나열됩니다: 베이징 CSNET, 베이징 주현차오(九仙桥), 청두, 홍콩의 HKIX, 그리고 로스앤젤레스, 시카고, 프랑크푸르트, 뉴욕의 Cogent 위치들. 이 부속 자료는 베이징, 홍콩, 로스앤젤레스, 시카고, 프랑크푸르트, 뉴욕을 애니캐스트에, 주현차오와 청두를 유니캐스트 서비스에 연관시킵니다.

이는 유용한 공시입니다. 여러 도시와 지역의 시설과 네트워크에 의존하는 설계를 보여주며, “글로벌 커버리지” 같은 마케팅 문구보다 많은 실체를 제공합니다. 또한 어떤 서비스 기능이 어느 행에 존재하는지에 대한 구체적 후속 질문을 가능하게 합니다.

그러나 행은 노드 수가 아니며, 노드는 반드시 장애 도메인인 것도 아닙니다. 이 부속 자료는 각 위치에 몇 대의 서버가 있는지, 동일한 제어 평면이 모두를 지원하는지, 각 위치가 얼마나 쿼리 부하를 나르는지, 어떤 링크가 물리적 도관을 공유하는지를 명시하지 않습니다. 공인 주소를 특정 행에 매핑하지 않습니다. 4개의 Cogent 항목이 하나의 계약 아래 구매된 것인지, 그들의 상위 의존이 다른 곳에서 수렴하는지, 일부 행이 다른 행보다 좁은 역할을 하는지 보여주지 않습니다.

레이블 자체도 절제의 필요성을 강화합니다.HKIX 공개 운영 사이트는 교환 환경을 설명할 뿐, ZDNS가 그곳에 갖는 장비, 용량 또는 계약 조건을 확립하지 않습니다.Cogent 네트워크 맵은 폭넓은 네트워크를 설명할 뿐, 4개의 도시 이름을 ZDNS 소유 시설 4곳으로 바꾸지 않습니다. 교환 지점이나 캐리어 위치에 대한 의존은 운영적으로 가치 있을 수 있지만, 공개 레이블만으로 예약된 여유나 물리적 독립성을 드러낼 수 없습니다.

애니캐스트와 유니캐스트의 구분조차 신중함이 필요합니다. 애니캐스트는 여러 사이트가 동일 주소를 제시하고 라우팅이 근접하거나 선호되는 경로를 선택하도록 할 수 있습니다. 유니캐스트는 더 위치 특정적인 주소 관계를 노출합니다. 어느 레이블도 빠진 장비 목록을 제공하지 않습니다. 어느 행이 레지스트리 데이터베이스, 서명 시스템, 로그 저장소, 모니터링, 고객 관리 또는 권위적 서빙을 호스팅하는지 말하지 않습니다. 최대 사이트가 차지하는 일반 트래픽 비중도 수량화하지 않습니다.

구매자 입장에서 8개 행은 의존 지도의 시작점으로 취급되어야 합니다. 다음 문서는 사이트-기능 매트릭스여야 합니다: 각 행, 각 서비스 역할, 각 주소 계열, 각 라우팅 모드, 설치 및 예비 장비, 일반 및 최대 부하, 네트워크 커밋과 다른 행들과 공유하는 의존성. 그 매트릭스가 나올 때까지 “8개 위치”는 명명된 의존 지점에 관한 서술이지, 8개의 동등하고 독립적이며 완전히 대체 가능한 단위의 개수가 아닙니다.

732랙 수치는 ZDNS가 아니라 호스트 시설에 속합니다

부속 자료의 한 숫자는 근거 한계가 허용하는 것보다 멀리 퍼질 가능성이 특히 높습니다. 베이징 M5 3단계 인증서 부록은 세 개의 방에 걸쳐 732개 랙을 다룹니다. 여기에는 2기의 3,517kW 칠러, 2기의 84입방미터 냉수 탱크, 5기의 2,500kVA 디젤 발전기도 나열됩니다. 이 수치들은 상당한 인프라 기반처럼 들리며, 공시된 호스트 의존 지점에 실질적인 시설 시스템이 있다는 근거입니다.

그러나 ZDNS의 용량 총계가 아닙니다.

부록은 호스트 시설의 인증 범위를 설명합니다. ZDNS가 몇 개의 랙을 점유, 임대, 예약하거나 비상 시 확보할 수 있는지 말하지 않습니다. 어느 칠러, 어느 탱크, 어느 디젤 발전기도 ZDNS에 배정하지 않습니다. ZDNS의 계약 전력, 실측 소비 또는 방별 할당을 제공하지 않습니다. 네트워크와 케이블링은 인증서 범위 밖이므로, 이 문서는 DNS 운영을 위한 다양화된 진입구, 독립적인 캐리어 경로 또는 예비 크로스커넥트도 입증할 수 없습니다.

같은 규칙이 화이러우(怀柔) 설명에도 적용됩니다. 그 자료는 약 20,000제곱미터와 1,000개 이상의 캐비닛을 다룹니다.CNIC 기관 개요는 기관에 대한 맥락을 제공하지만, 총 면적과 캐비닛 수치는 ZDNS에 배정될 수 없습니다. 큰 호스트 환경은 유리한 조건을 제공할 수 있지만, 할당 근거 없이는 사용 가능 용량 잔고에 임차인 몫으로 더해질 수 없습니다.

인프라 서술이 의존에서 소유로 미끄러지는 지점이 바로 여기입니다. 호스트에 발전기가 있으므로 임차인이 그 발전기를 “가지고 있는” 것처럼 말하는 것. 건물에 732랙이 있으므로 임차인이 732랙에 “접근할 수 있는” 것처럼 말하는 것. 캠퍼스에 1,000개 이상의 캐비닛이 있으므로 서비스에 막대한 예비가 있는 것처럼 말하는 것. 그 어떤 치환도 여기서 지지되지 않습니다. 공유 시설 시스템은 ZDNS에 이익이 될 수 있지만, ZDNS가 소유하거나 독점적으로 이용할 수 있는 것은 아닙니다.

이 구분은 장애 분석에도 영향을 줍니다. 시설 전체 발전기 총계는 특정 부하가 이용할 수 있는 가동 시간, 연료 보충 합의, 정비 상태 또는 임차인의 배전 경로가 테스트 범위 안에 있는지에 대해 거의 말해주지 않습니다. 칠러 총계는 임차인의 실제 밀도에서 부품 장애 후 얼마나 많은 냉각이 남는지 보여주지 않습니다. 랙 총계는 전력과 네트워크가 연결된 예비 용량을 보여주지 않습니다. 따라서 732랙 수치는 호스트 의존과 그 집계된 인증 시스템에 대한 근거입니다. ZDNS 용량 732랙에 대한 근거가 아니며, 결코 그렇게 제시되어서는 안 됩니다.

티어 언어는 설계 기대치를 정하는 것이지 예비 용량 측정이 아닙니다

Main RSP 신청서는 티어 III 이상 또는 동등 수준의 독립 데이터센터 최소 2개를 주장하며, 백업, 모니터링, 복구 통제와 24시간 온콜 대응을 함께 주장합니다. 이들은 관련된 약속입니다. 겉으로 보기에 단일 시설에 대한 의존을 피하고 연속 운영을 지원하도록 설계된 설계를 설명합니다.

티어 용어는 흔히 요구되는 일보다 더 좁은 역할을 합니다.Uptime Institute 티어 개요는 일반적인 프레임워크를 제공하지만, 티어 수준은 “내 서비스 중 몇 퍼센트가 가장 바쁜 사이트 장애에서 생존하는가?”에 대한 답이 아닙니다. 시설 토폴로지와 유지보수성은 서비스 수준의 예비 용량과 같지 않습니다. 적합한 두 건물조차 일반 부하가 한 위치에 집중된 애플리케이션을 담을 수 있습니다. 그들은 데이터베이스 의존, 서명 의존, 캐리어 경로, 관리 통제 또는 오류 도메인을 공유할 수 있습니다.

또한 공개된 주장은 분모를 드러내지 않습니다. 공시된 설치 서버 수, 예비 서버 수, 포트 커밋, DDoS 예비 또는 최대 사이트 비중이 없습니다. 남은 위치들이 철수된 사이트의 일반 및 최대 부하를 안전 마진을 유지하며 흡수할 수 있음을 보여주는 표도 없습니다. “최소 2개”는 최소한의 아키텍처 주장을 확립할 뿐, 어느 위치 내부의 용량도 수량화하지 않습니다.

독립성도 서비스 수준에서 입증되어야 합니다. 건물은 지리적으로 분리되어 있으면서 소프트웨어 릴리스, 키 관리 또는 레지스트리 데이터는 결합되어 있을 수 있습니다. 전력 시스템은 독립적이면서 라우팅 제어 실수가 양쪽 모두에 영향을 줄 수 있습니다. 캐리어 이름은 다르면서 물리적 도관은 수렴할 수 있습니다. 반대로 서비스는 신중하게 엔지니어링된 공유 인프라에서 의미 있는 복원력을 얻을 수 있습니다. 요점은 모든 공유 요소에서 약점을 추론하는 것이 아니라, 공유 요소를 그 결과를 테스트할 수 있을 만큼 충분히 가시화하는 것입니다.

티어 III 이상 또는 동등 수준이라는 주장을 평가하는 구매자는 시설 등급 또는 동등성 근거를 요청한 뒤, 이를 ZDNS의 실제 배치와 연결해야 합니다. 어느 방에 장비가 있는가? 어떤 전력 경로가 그것에 전원을 공급하는가? 평가된 범위 안팎에 어떤 네트워크 구성 요소가 있는가? 정비 또는 모의 손실 동안 얼마나 많은 부하가 이전되었는가? 이후 얼마나 많은 용량이 남았는가? 그 연결이 없다면, 티어 언어는 명시된 설계 방향에 대한 신뢰를 뒷받침하지만 사용 가능한 페일오버 여유를 둘러싼 근거 공백을 메울 수 없습니다.

AS38345는 살아 있는 듀얼 스택 표면을 보여주지, 하드웨어 재고를 보여주지 않습니다

라우팅 근거는 공개 기록에서 가장 강한 부분 중 하나입니다. 연구 관측 동안 AS38345는 광범위한 수집기 가시성과 함께 24개의 IPv4 /24 프리픽스와 12개의 IPv6 /48 프리픽스를 광고했습니다.RIPEstat AS 개요,공표 프리픽스 화면과라우팅 상태 화면은 그 표면에 대한 서로 다른 창을 제공합니다.Cloudflare Radar의 AS38345 페이지는 또 다른 라우팅 지향적 시각을 제공합니다.

이 관측들은 함께 하나의 절제된 결론을 뒷받침합니다: AS38345는 의미 있는 IPv4와 IPv6 경로 집합을 가시적으로 광고하고 있었다. 이는 살아 있는 듀얼 스택 네트워크 존재의 좋은 근거입니다. 그러나 특정 서버 수, 트래픽 한도 또는 지리적 분포에 대한 근거는 아닙니다.

BGP는 인터넷에 프리픽스에 도달하는 방법을 알려줍니다. 그 뒤의 부품 목록을 공개하지는 않습니다. 동일 프리픽스는 여러 애니캐스트 위치에서 서빙될 수 있고, 관측된 경로는 더 작은 활성 노드 집합에서 끝날 수 있습니다. 수집기는 경로를 볼 수 있지만 그 경로 뒤의 애플리케이션은 비정상일 수 있습니다. 광범위한 가시성은 공유된 물리적 병목과 공존할 수 있습니다. 반대로 적당한 수의 프리픽스가 상당한 서비스를 내세울 수 있습니다. 따라서 프리픽스 산수는 장비와 부하 근거를 대체하기 어려운 열악한 대리물입니다.

관련된ASN 이웃 데이터와라우팅 일관성 데이터는 라우팅 관계와 관측을 설명하는 데 도움이 됩니다. 그럼에도 두 개의 표면상 경로가 분리된 도관으로 건물에 진입하는지, 에지 라우터에 예비 포트가 있는지, 스크러빙 합의가 대규모 공격에 대한 예비를 갖고 있는지 보여줄 수 없습니다. 논리적 경로 다양성은 가치 있지만, 물리적 경로 다양성은 별도로 확립되어야 합니다.

RPKI 표본에도 같은 절제가 필요합니다. 표본화된 AS38345 프리픽스 하나는150.242.156.0/24 검증 화면에서 유효로 나왔고, 다른 하나는1.8.1.0/24 검증 화면에서 미상으로 나왔습니다. 두 관측은 자율 시스템에 대한 영구 점수가 아니며, “미상”은 하이재킹의 근거가 아닙니다. 이들은 광범위하고 날짜가 기재된 경로 발원지 검토를 정당화하는 표본이지, 총괄적 판정이 아닙니다.

라우팅 기록은 관측 가능하고, 구체적이며, 관련성이 있기 때문에 중간 근거 등급을 받을 자격이 있습니다. 그것은 여전히 네트워크 층 기록입니다. 물리적 용량 증명으로 취급하는 것은 BGP에 원래 설계된 적 없는 질문을 던지는 일입니다.

위임은 기계를 드러내지 않으면서 운영 패턴을 드러냅니다

루트 존 위임 기록은 ZDNS를 식별 가능한 권위적 DNS 책임에 연결합니다..baidu,.icbc와.unicom의 IANA 페이지는 ZDNS를 기술 연락처로 식별하고 권위적 엔드포인트에서 공유된 패턴을 드러냅니다. 이는 ZDNS가 단순히 가상의 DNS 서비스를 설명하는 것이 아니라, 위임된 최상위 도메인에서 가시적 역할을 맡고 있음을 보여주는 구체적 근거입니다.

그럼에도 이 기록들은 위임을 설명하지, 그 아래의 물리적 구현을 설명하지 않습니다. 어느 도시가 특정 쿼리에 응답하는지, 각 최상위 도메인에 몇 개의 노드가 서빙하는지, 고객이 호스트를 공유하는지, 용량이 어떻게 나뉘는지 보여주지 않습니다. 네임서버 레이블이 하나의 플랫폼에 매핑되는지 여러 개의 운영적으로 격리된 그룹에 매핑되는지 드러내지 않습니다. 기술 연락처 역할은 레지스트리 운영자, DNS 운영자, 시설과 네트워크 사이의 모든 계약적 경계도 공개하지 않습니다.

선별된 주소 관측은 혼합 발원지 그림을 강화합니다.203.99.24.1,116.169.54.111,223.72.199.37과2401:8d00:2::1의 네트워크 정보는 AS38345, AS4837, AS56048과 AS24149에서 온 선별된 권위적 주소를 보였습니다. 여러 발원지는 분산 서비스와 다양한 의존성과 정합적일 수 있습니다.

그러나 그것만으로 별개의 시설이나 다양화된 도관을 증명하지는 않습니다. 경로 발원지는 서버 소유권, 임대 조건 또는 운영 책임을 결정하지 않습니다. 서로 다른 발원지가 동등한 용량, 공통 데이터 신선도 또는 독립적 통제를 갖고 있음을 보여주지도 않습니다. 견고한 설계는 의도적으로 여러 네트워크를 사용할 수 있지만, 복원력 결론은 자율 시스템 번호의 개수가 아니라 테스트된 서비스 지도에서 따라와야 합니다.

RFC 2182의 세컨더리 DNS 설계 지침은 다양성이 왜 중요한지 강조합니다: 권위적 서비스는 쉽게 공유되는 장애 모드를 피해야 합니다. 공개 위임과 발원지는 구매자에게 그 조사의 유용한 시작점을 줍니다. 그것으로 조사를 끝낼 수는 없습니다. 빠진 연결 고리는 고객 대면 위임을 서빙 그룹, 네트워크, 시설, 용량 비중과 테스트된 장애 동작으로 매핑하는 것입니다.

하나의 브랜드가 여러 운영 표면에 걸쳐 있습니다

ZDNS의 공개 자료는 두 개 이상의 제품을 설명합니다. 회사의TLD 플랫폼 페이지는 레지스트리 지향 기능과 성능 주장을 논의합니다.클라우드 DNS 페이지는 호스티드 DNS 역량을 설명합니다.코어 장비 페이지는 별도의 배치형 어플라이언스 라인을 제시합니다. 더 넓은 포트폴리오에는 에스크로, DNSSEC, WHOIS/RDAP, 권위적 DNS, GSLB, HTTPDNS와 BGP/애니캐스트가 포함됩니다.ICANN 기본 레지스트리 협약은 관련 레지스트리 맥락을 제공하지만, 그 제품들을 하나의 운영 표면으로 묶지는 않습니다.

이 폭은 상업적으로 유용하고 분석적으로 위험합니다. “ZDNS 서비스”는 최소 세 가지 뚜렷이 다른 합의를 가리킬 수 있습니다: 최상위 도메인 플랫폼의 일부로 운영되는 레지스트리 기능; 공유 인터넷 인프라를 통해 전달되는 호스티드 권위적 또는 클라우드 DNS; 그리고 고객이 통제하는 환경에 배치되는 장비. 각 합의는 서로 다른 자산 경계, 의존 체인과 복구 책임을 갖습니다.

고객 사이트에 설치된 어플라이언스는 호스티드 DNS 클라우드를 위한 예비 용량으로 계산되어서는 안 됩니다. 글로벌 라우팅되는 권위적 노드가 레지스트리 데이터베이스를 포함한다고 가정해서는 안 됩니다. 레지스트리 에스크로 약속이 호스티드 기업 DNS 존이 동일 메커니즘으로 복원될 수 있음의 증명으로 취급되어서는 안 됩니다. DNSSEC 키 보관은 고객과 서비스 유형에 따라 달라질 수 있습니다. 공개 기록은 모든 배치에 대한 보편적인 법적 또는 운영적 배정을 뒷받침하지 않습니다.

같은 주의가 성능에도 적용됩니다. WHOIS/RDAP에 붙은 쿼리율 수치는 서명 시스템의 한계에 대해 거의 말해주지 않습니다. 서명 트랜잭션 주장은 권위적 서비스의 공격 예비를 알려주지 않습니다. 하루 20억 건의 DNS 해석은 규모에 관한 서술이지 토폴로지에 관한 서술이 아닙니다. 이들을 합치면 인상적이지만 무의미한 총계가 만들어질 수 있습니다.

따라서 구매자는 복원력 근거를 요청하기 전에 서비스 경계를 정의해야 합니다. 어느 기능이 범위 안에 있는가? 어느 것이 공유되는가? 어느 것이 고객 자산에 남는가? 레지스트리 데이터, 존 데이터, 로그, 백업과 키는 어디에 저장되는가? 누가 경로를 바꿀 수 있는가? 누가 데이터베이스를 복원할 수 있는가? 누가 복구 목표를 소유하는가? 그 질문들에 답한 후에만 위치와 용량 근거를 실제 구매하는 서비스에 맞출 수 있습니다.

이 층적 관점은 단일 회사 차원의 근거 등급이 오해를 일으키는 이유도 설명합니다. ZDNS에는 가시적 네트워크와 논리적 서비스 존재에 대한 중간 평가를 뒷받침할 만큼의 공개 근거가 있습니다. 어느 하나의 제품이 이용할 수 있는 특정 물리적 자산과 예비 용량은 약하게 근거가 제시됩니다. 다른 제품들은 그 공개 기준보다 더 좋거나 나쁠 수 있지만, 검토된 자료는 그 차이를 수량화하지 않습니다.

마케팅 용량은 생존 용량이 아닙니다

ZDNS는 여러 인상적인 성능 수치를 마케팅합니다: 초당 3,000건의 서명 트랜잭션, 15,000개의 키 페어, 초당 16,000~27,000건의 WHOIS/RDAP 처리량, 하루 20억 건의 DNS 해석, 99.999퍼센트를 넘는 가용성. 이 수치들은 ZDNS가 구매자가 자신의 플랫폼과 연상하기를 바라는 규모와 서비스 품질을 보여주므로 관련이 있습니다.

그러나 이들을 사용 가능한 페일오버 여유로 직접 변환할 수는 없습니다.

첫째, 공개 주장에는 날짜가 기재된 측정 방법이 없습니다. 기록은 각 수치 뒤의 테스트 워크로드, 응답 믹스, 캐시 동작, 객체 크기, 전송 조건 또는 기간을 정의하지 않습니다. 값이 한 대의 어플라이언스, 클러스터, 실험실 구성 또는 배치된 플릿에서 측정되었는지 말하지 않습니다. 동시성, 지연 백분위수 또는 오류 임계값도 제공하지 않습니다. 그 맥락이 없다면, 비교 가능해 보이는 값들이 완전히 다른 조건을 설명할 수 있습니다.

둘째, 활용률 분모가 없습니다. 명시된 최대치를 낼 수 있는 시스템은 평시에 그 극히 일부만으로 운영되어 풍부한 예비를 남길 수도 있고, 실제 트래픽, 방어 통제와 정비를 포함하면 실용적 한계에 가깝게 운영될 수도 있습니다. 공개 기록은 평시 부하, 관측된 최대 부하 또는 사이트별 안전 마진을 공시하지 않습니다. 하루 20억 건의 해석은 하루 전체의 규모 서술에 가까우며, 최고 초, 가장 바쁜 노드 또는 가장 큰 고객 집중을 공개하지 않습니다. 추가 산수로도 빠진 사실을 되찾을 수 없습니다.

셋째, 정상 조건의 용량은 장애 후 용량이 아닙니다. 최대 사이트가 일반 쿼리의 상당 부분을 나른다면, 생존 사이트들은 최대치와 공격에 대한 보호를 유지하면서 그 부하를 감당해야 합니다. 권위적 쿼리 처리가 병목이 되기 전에 데이터베이스 작업, 서명, 모니터링과 경로 변경이 병목이 될 수 있습니다. 주장된 99.999퍼센트 가용성 수준은 그 뒤의 인시던트 모수, 측정 창, 제외 항목 또는 고객 코호트를 보여주지 않습니다. 또한 구매자가 관심을 갖는 특정 시나리오에서 시스템이 어떻게 동작하는지 식별할 수 없습니다.

넷째, 가용성과 회복 가능성은 다릅니다. 분산 DNS 에지는 레지스트리 데이터베이스가 손상된 동안에도 응답을 계속할 수 있습니다. 제어 평면은 복구되는 동안 에지에 오래되었거나 불일치한 데이터가 남을 수 있습니다. 어플라이언스는 로컬 처리량 수치를 충족하면서 호스티드 서비스는 별도의 의존성을 가질 수 있습니다. 성능 주장은 정확한 구성 요소와 장애 시나리오에 붙어야 합니다.

빠진 근거는 간단히 서술할 수 있습니다: 설치 재고, 예비 재고, 일반 및 최대 부하, 네트워크 커밋, 완화 예비, 최대 사이트 비중과 그 사이트를 제거했을 때의 실측 결과. 이 값들이 있으면 구매자는 생존 부하와 잔여 마진을 계산할 수 있습니다. 그것이 없는 한, 마케팅 수치는 공개되지 않은 조건 하의 잠재적 또는 달성된 성능에 관한 주장으로 남습니다. 서비스가 주요 사이트 상실을 흡수할 수 있다는 증명으로 제시되어서는 안 됩니다.

애니캐스트는 라우팅 도구이지 복구 인증서가 아닙니다

애니캐스트는 공시된 설계의 중심입니다. 여러 위치 행이 그것과 연관되어 있으며, 이 기법은 권위적 DNS에 적합합니다. 여러 위치가 동일 주소를 광고할 수 있어 인터넷 라우팅이 경로를 선택할 수 있습니다. 장애 노드가 경로를 깨끗하게 철수하고 정상 위치가 충분한 용량을 갖고 있다면, 트래픽은 문제에서 벗어날 수 있습니다.RFC 4786은 애니캐스트를 유용하나 마법적이지 않게 만드는 운영 특성과 주의사항을 설명합니다.

유리한 시나리오에는 공개 위치 개수가 증명하지 않는 두 가지 조건이 들어 있습니다: 나쁜 경로가 사라져야 하고, 생존 사이트들이 이동된 부하를 감당할 수 있어야 합니다. 비정상 노드가 계속 광고하면 트래픽은 계속 그곳에 도달할 수 있습니다. 철수가 느리거나 불균일하면 어떤 네트워크는 계속 실패한 경로를 선택할 수 있습니다. 생존 노드에 쿼리, 네트워크 또는 완화 용량의 예비가 없다면, 깨끗한 철수는 과부하를 다른 곳으로 옮기기만 합니다.

애니캐스트는 상태를 복구하지도 않습니다. 손상된 레지스트리 데이터베이스를 복원하거나, 잘못된 전역 구성을 되돌리거나, 잃어버린 서명 자료를 재생성하거나, 충돌하는 데이터를 정합화할 수 없습니다. 공통 변경은 위치들이 물리적으로 독립적이더라도 모든 위치를 손상시킬 수 있습니다. 키 관리 결함은 모든 권위적 응답을 중단하지 않으면서 서명에 영향을 줄 수 있습니다. 모니터링 오류는 철수를 지연시킬 수 있습니다. 이들은 공유된 논리적 장애 모드이며, 도시를 더한다고 해서 자동으로 사라지지 않습니다.

올바른 테스트는 관측 가능한 것입니다. 통제된 조건에서 한 위치의 서비스 경로를 철수합니다. 대표 네트워크들로부터의 수렴을 측정합니다. 모든 생존 사이트에서 오류율, 지연과 부하를 추적합니다. 경로가 있어서는 안 될 곳에 남아 있지 않음을 확인합니다. 그다음 위치를 복원하고 재진입이 불일치한 서비스를 만들지 않음을 검증합니다. 가장 쉽거나 가장 작은 노드가 아니라 최대 사이트에 대해 반복합니다.

공개 기록은 그 연습으로부터 날짜가 기재된 결과를 제공하지 않습니다. 따라서 역량에 관한 서술은 지지합니다: ZDNS는 분산 라우팅 설계의 재료를 설명하고 가시적으로 사용합니다. 그러나 입증된 여유에 관한 서술은 지지하지 않습니다: 검토된 출처는 얼마나 많은 트래픽이 옮겨질 수 있는지, 얼마나 빨리 옮겨지는지, 이후 어떤 마진이 남는지를 수량화하지 않습니다.

그렇기에 애니캐스트는 중간 네트워크 및 논리적 서비스 등급을 강화하지만, 그것만으로 약한 물리적 용량과 페일오버 여유 등급을 끌어올릴 수는 없습니다.

DNSSEC과 에스크로 통제는 실행된 결과가 필요합니다

복구 근거는 장비 근거보다 더 많은 것입니다. ZDNS의KSK 관리 부속 자료는 연간 및 비상 키서명키(KSK) 로테이션, HSM과 침입 탐지 모니터링, 대역외 통신, 테이블톱 연습과 사후분석 설계를 설명합니다. 이들은 합리적인 통제 요소입니다. 키 이벤트, 비상 조율과 인시던트 후 학습이 고려되었음을 보여줍니다.

그러나 이 문서는 여전히 작업이 어떻게 수행되도록 의도되었는지에 대한 설명입니다. 가장 최근에 실행된 비상 로테이션, 그 기간, 직면한 문제 또는 달성된 목표를 공개하지 않습니다. 모든 고객이 동일한 보관 합의를 사용한다는 것을 확립하지도 않습니다. 일반적인 통제 설명은 어느 법인이 어느 키를 보유하는지, 특정 서비스에 대해 쿼럼이 어떻게 형성되는지, 백업 자료가 마지막 테스트에서 성공적으로 사용되었는지에 답할 수 없습니다.

에스크로도 비슷한 근거 경계를 갖습니다. Main 신청서는 전체 레지스트리 에스크로 예탁금이 매일 발생하고 실패한 예탁금은 재시도된다고 말합니다. 일일 주기는 유용합니다. 전체 예탁금 사이의 의도된 간격을 줄이고 실패한 제출에 대한 명시적 대응을 만듭니다. 그러나 성공적인 전송은 복구 체인의 한 고리일 뿐입니다. 완전성, 무결성, 복호화 가능성과 복원 환경과의 호환성은 여전히 확립되어야 합니다. 복원된 레지스트리는 이후 정합화되고 운영 가능 상태로 만들어져야 합니다.

달성된 복구 시점 목표는 “매일”에서 추론할 수 없습니다. 가장 최신 예탁금은 검증을 생략하거나 실패할 수 있고; 트랜잭션 시점은 다른 유효 시점을 만들 수 있으며; 복원 팀은 사용 가능한 예탁금이 더 오래되었음을 발견할 수 있습니다. 마찬가지로 달성된 복구 시간 목표는 온콜 약속에서 추론할 수 없습니다. 그 시계에는 접근, 의사결정, 데이터 검색, 복호화, 복원, 검증, 라우팅과 서비스 수용이 포함됩니다.

구매자에게 결정적인 근거는 날짜가 기재된 테스트 기록입니다. 그것은 서비스, 장애 조건, 시작 상태, 인력 역할, 데이터 집합, 키 자료, 경과 단계, 오류, 최종 무결성 검사와 측정된 RTO/RPO를 식별해야 합니다. DNSSEC 비상 기록은 실제로 행해진 로테이션 또는 복구 경로를 보여줘야 합니다. 에스크로 기록은 예탁금이 성공적으로 검증되어 깨끗한 환경에 복원되었음을 보여줘야 합니다. 데이터베이스 연습은 파일 복원만이 아니라 일관성 검사와 애플리케이션 준비 상태를 보여줘야 합니다.

검토된 공개 자료는 그 완전한 결과 집합을 제공하지 않습니다. 따라서 문서화된 통제는 기각되지 않고 설계 근거로 인정받아야 합니다. 그러나 최근의 성공적인 복구 증명으로 격상되어서는 안 됩니다.

로컬 DNS 응답은 로컬 데이터 보관을 확립하지 않습니다

ZDNS의 권위적 서비스는 글로벌 공개 데이터 평면 표면을 갖고 있습니다. 애니캐스트는 주소를 여러 장소에서 도달 가능하게 하고, 흔히 사용자를 네트워크 선호 인스턴스로 유도하도록 설계되었습니다. 그것은 지연과 내결함성을 개선할 수 있습니다. 그러나 오해를 일으키는 직관도 만들 수 있습니다: 응답이 근처 네트워크 위치에서 빠르게 도착했다면, 사용자의 기반 데이터도 근처에 머물렀어야 한다는 직관입니다.

공개 기록은 그 결론을 뒷받침하지 않습니다.

권위적 DNS 응답은 로컬 또는 근처 노드에서 서빙될 수 있으면서, 레지스트리 데이터, 고객 구성, 쿼리 로그, 백업, 키 또는 관리 통제는 다른 곳에 있을 수 있습니다. 에지는 존의 사본을 보유할 수 있지만 갱신은 원격 제어 평면에서 발생합니다. 쿼리 서빙이 국경을 넘지 않더라도 모니터링과 인시던트 접근은 국경을 넘을 수 있습니다. 백업이나 에스크로 예탁금은 활성 서빙 사본과 다른 관할권에 있을 수 있습니다. 키 보관은 자체 위치와 법적 경계를 가질 수 있습니다.

8행 위치 부속 자료는 가능한 데이터 평면 의존 지점을 식별하는 데 도움이 되지만, 이 다른 데이터 클래스들의 배치를 공개하지 않습니다. 레지스트리 데이터베이스를 도시에 매핑하지 않고, 로그 보존 위치를 식별하지 않고, 백업 관할권을 명명하지 않으며, HSM 기반 키가 어디에 보관되는지 보여주지 않습니다. 애니캐스트와 유니캐스트의 구분은 그 자체로 데이터 레지던시에 대해 아무것도 말하지 않습니다.

이것은 고객마다 다르게 작용합니다. 레지스트리 운영자는 등록 데이터, 에스크로와 서명 권한에 집중할 수 있습니다. 기업 DNS 고객은 존 내용, 쿼리 텔레메트리와 관리 접근에 관심을 가질 수 있습니다. 등록인은 레지스트리와 등록기관 층의 정책에 영향을 받을 수 있습니다. 다운스트림 사용자는 주로 해석 가용성에 관심을 가질 수 있습니다. 하나의 지역성 서술이 이 모든 관심을 만족시킬 수 없습니다.

따라서 방어 가능한 지역성 표현은 데이터별이고 기능별이어야 합니다. 권위적 사본이 어디에서 서빙되는지, 진실의 원천이 어디에 저장되는지, 로그가 어디에 보존되는지, 백업이 어디에 보관되는지, 키가 어디에서 통제되는지, 어느 관할권의 관리자가 조치할 수 있는지를 서술해야 합니다. 비상 복원은 다른 위치를 사용할 수 있으므로 평시 운영과 재해 복구를 구분해야 합니다.

그 지도가 없다면, ZDNS의 글로벌 라우팅 표면은 글로벌 도달을 증명할 뿐 로컬 보관을 증명하지 않습니다. 구매자는 양극단 모두를 거부해야 합니다: 근처 응답은 로컬 저장의 증명이 아니지만, 글로벌 분산 DNS 에지도 그 자체로 모든 데이터 클래스가 글로벌 복제된다는 증명이 아닙니다. 근거는 어느 지름길도 지지하지 않습니다.

의존 체인에는 여러 종류의 사용자가 있습니다

DNS 또는 레지스트리 실패의 결과는 단일 고객 수로 환원될 수 없습니다. 레지스트리 운영자, 등록기관, 등록인, 재귀 리졸버, 기업 DNS 고객과 다운스트림 사용자는 시스템의 서로 다른 층에 의존합니다. 그들의 노출은 겹치지만 서로 교환 가능하지는 않습니다.

레지스트리 운영자는 핵심 레지스트리 기능, 위임 데이터, 서명과 에스크로 합의에 의존합니다. 등록기관은 레지스트리 인터페이스와 일관된 데이터에 의존합니다. 등록인은 등록기관 관계와 레지스트리의 지속 운영 양쪽에 의존합니다. 재귀 리졸버는 권위적 가용성과 정확성에 의존합니다. 기업 DNS 고객은 호스티드 권위적 서비스, HTTPDNS 또는 트래픽 관리 기능에 의존할 수 있습니다. 다운스트림 사용자는 도달하려는 애플리케이션과 도메인을 통해 최종 효과를 접합니다.

이 층적 체인이 겉보기에 좁은 인시던트가 광범위한 결과를 가질 수 있는 이유입니다. 권위적 서빙 문제는 레지스트리 기록이 온전히 유지되는 동안 해석을 손상시킬 수 있습니다. 레지스트리 데이터베이스 문제는 변경을 방해하는 동안 캐시된 기존 DNS 응답은 계속될 수 있습니다. 서명 문제는 패킷이 권위적 서비스에 여전히 도달하더라도 일부 사용자에게 검증 실패를 만들 수 있습니다. 공유된 나쁜 구성은 여러 위치를 동시에 영향을 줄 수 있습니다. 가시적 증상이 항상 실패한 층을 식별하지는 않습니다.

이것이 공개 고객 또는 도메인 총계가, 있다 하더라도, 영향받는 사람들 또는 중대 서비스로 깨끗하게 번역되지 않는 이유이기도 합니다. 한 도메인은 가볍게 사용될 수 있고; 다른 도메인은 무거운 의존을 받는 애플리케이션을 지탱할 수 있습니다. 한 고객은 독립적인 세컨더리 DNS를 가질 수 있고; 다른 고객은 없을 수 있습니다. 재귀 캐싱은 시점과 도달 범위를 바꿉니다. 중대성은 관리 중 이름 수뿐만 아니라 도메인이 무엇에 사용되는지와 어떤 대안이 존재하는지에 달려 있습니다.

실사에 유용한 단위는 서비스 의존성입니다. 구매자는 어느 ZDNS 층을 소비하는지, 다른 조직들이 경로에 있는지, 어떤 데이터 또는 키 상태가 필요한지, 동일 장애 도메인 밖에 어떤 대안이 있는지 식별해야 합니다. 그 매핑은 모호한 “DNS 리스크”를 테스트 가능한 시나리오로 바꾸고, 관련 없는 헤드라인 수치가 영향의 대리물로 사용되는 것을 방지합니다.

진지한 구매자가 요청해야 할 증명 패키지

공개 기록의 공백은 메워질 수 있지만, 아키텍처를 운영에 연결하는 근거로만 가능합니다. 강한 실사 패키지는 날짜가 기재된 사이트-기능 매트릭스로 시작해야 합니다. 공시된 모든 행이 나타나야 합니다: 베이징 CSNET, 베이징 주현차오, 청두, 홍콩 HKIX, 로스앤젤레스, 시카고, 프랑크푸르트와 뉴욕. 각 행에 대해 매트릭스는 해당되는 권위적 서빙, 레지스트리 데이터베이스, DNSSEC, WHOIS/RDAP, GSLB, HTTPDNS, 모니터링, 관리와 백업 역할을 식별해야 합니다. 애니캐스트를 유니캐스트와 구분하고 관련 주소 계열과 서빙 그룹을 매핑해야 합니다.

둘째, 패키지에는 귀속 가능한 재고가 포함되어야 합니다. 즉 ZDNS가 통제하거나 계약적으로 이용할 수 있는 서버, 네트워크 장비, HSM, 저장 장치, 전력이 연결된 랙, 포트와 사이트별 예비품. 호스트 시설 총계는 별도로 표시되어야 합니다. 공유 시설 통제가 서비스에 이익이 된다면, 근거는 계약된 서비스 수준과 그것이 보호하는 임차인 경로를 서술해야 합니다. 732랙, 칠러, 탱크와 디젤 발전기는 일부 정의된 몫을 ZDNS와 연결하는 할당 문서가 있기 전까지는 시설 수치로 남아야 합니다.

셋째, 구매자는 부하와 예비 데이터가 필요합니다. 각 서비스와 사이트에 대해, ZDNS는 명시된 기간에 걸친 일반 부하, 관측된 최대, 실용적 한계, 계획된 안전 마진과 최대 사이트 비중을 제공해야 합니다. 관련이 있는 곳에서는 네트워크 커밋과 방어 용량도 포함되어야 합니다. 수치는 마케팅된 서명, 키, WHOIS/RDAP, DNS 해석과 가용성 주장을 해석 가능하게 만드는 워크로드 정의를 사용해야 합니다. 현재 활용률이 없는 용량 수치는 여유를 확립할 수 없습니다.

넷째, 라우팅 복원력은 입증되어야 합니다. 통제된 경로 철수 연습은 선정된 사이트, 프리픽스, 시작 시각, 관측 지점, 수렴, 오류율, 지연, 이동된 부하와 잔여 마진을 기록해야 합니다. 비정상이지만 여전히 광고하는 시나리오도 고려되어야 합니다. 그것은 깨끗한 소멸에 대한 라우팅의 반응만이 아니라 탐지와 철수를 테스트하기 때문입니다. 재진입도 관측되어야 합니다.

다섯째, 최대 사이트 상실 연습은 층을 넘어야 합니다. 관련 부하가 가장 큰 위치를 제거하고 권위적 서비스, 레지스트리 기능, 관리, 모니터링과 서명이 설계대로 계속됨을 보여야 합니다. 일부 기능이 계속되지 않고 의도적으로 복구된다면, 측정된 목표는 명시적이어야 합니다. 생존 사이트는 열, 네트워크, 상태 또는 큐잉 한계를 노출할 만큼 충분히 오래 부하 하에서 측정되어야 합니다.

여섯째, 복원 근거는 데이터베이스와 에스크로 경로 양쪽을 다뤄야 합니다. 깨끗한 환경이 선택된 백업 또는 예탁금을 수령하고, 복호화하고, 적재하고, 정합화하고, 애플리케이션 수준 검사를 통과해야 합니다. 기록은 달성된 데이터 시점과 경과 복구 시간을 서술해야 합니다. 복원 결과 없는 예탁금 수령 증명은 충분하지 않습니다. 기능적 레지스트리 검사 없는 파일 복원은 충분하지 않습니다.

일곱째, DNSSEC 비상 근거는 관련 키, HSM 통제, 인가, 대역외 통신, 공개 절차와 검증 결과가 포함된 실행된 시나리오를 보여줘야 합니다. 연습이 테이블톱이었는지 기술적 실행이었는지 공개해야 합니다; 둘 다 유용하지만 서로 다른 것을 증명합니다. 발견된 문제는 시정 조치와 이후 재테스트에 연결되어야 합니다.

마지막으로, 패키지는 서비스와 지역성 경계를 서술해야 합니다. 어느 근거가 레지스트리 운영, 호스티드 DNS와 고객 자산 장비에 적용되는지 식별해야 합니다. 권위적 사본, 진실의 원천 데이터, 로그, 백업, 키와 관리 접근을 관할권별로 매핑해야 합니다. 그것은 글로벌 에지 존재가 보편적 데이터 위치 주장으로 오해되는 것을 방지합니다.

이 중 어느 것도 민감한 도식을 공개할 것을 요구하지 않습니다. 구매자는 통제된 근거, 편집된 기록 또는 독립적 인증을 검토할 수 있습니다. 중요한 것은 기록이 날짜가 있고, 범위가 정해지고, 구매하는 서비스에 묶여 있다는 것입니다. 목표는 더 큰 문서 더미가 아닙니다. 물리적·계약적 자원에서 가장 중요한 장애 하의 관측된 동작까지의 체인입니다.

두 근거 등급이 실제로 의미하는 것

네트워크 및 논리적 서비스 근거 등급은 중간입니다. 이 등급은 여러 독립적 형태의 가시성에 의해 뒷받침됩니다. ZDNS는 IDN 지원을 포함한 Main, DNS, DNSSEC과 Proxy 서비스에 대해 2026년 ICANN 평가 자료에 나타납니다. 그 신청서와 자사 페이지는 레지스트리와 DNS 기능을 설명합니다. 위치 부속 자료는 8개의 의존 지점을 명명하고 애니캐스트와 유니캐스트 연관을 식별합니다. AS38345는 가시적인 IPv4와 IPv6 라우팅 표면을 제시합니다. IANA 위임은 ZDNS를 식별 가능한 최상위 도메인에 연결하고, 선별된 권위적 주소는 다중 발원지 패턴을 보여줍니다.

“중간”은 의도적으로 “강함”이 아닙니다. 이 평가는 제출물의 검토이지 모든 실제 배치에 대한 지속적 인증이 아닙니다. 위치 행에는 공개된 기능과 주소 지도가 없습니다. 경로 가시성은 애플리케이션 건강이나 물리적 다양성을 공개하지 않습니다. 위임은 고객 격리나 하드웨어를 공개하지 않습니다. 근거는 실제이며 상호 강화되지만, 중대한 구현 세부는 측정되지 않은 채 남습니다.

ZDNS 귀속의 물리적 용량과 사용 가능한 페일오버 여유 근거 등급은 약합니다. 검토된 공개 출처 어느 것도 사이트별 설치 또는 예비 하드웨어를 제공하지 않습니다. 귀속 가능한 랙 수, 전력 할당, 네트워크 포트 일정, 완화 예비 또는 현재 활용률 표가 없습니다. 최대 사이트 비중도 없고, 생존 위치가 마진을 두고 이동된 부하를 감당했음을 보여주는 날짜가 기재된 결과도 없습니다. 이용 가능한 복구 설명은 가장 최근에 달성된 RTO/RPO를 제공하지 않습니다.

“약함”은 서비스가 반드시 약하다는 뜻이 아닙니다. 그 특정 결론에 대한 공개 근거가 약하다는 뜻입니다. ZDNS는 공개되지 않은 상당한 장비와 잘 테스트된 예비를 보유할 수 있습니다. 공개되지 않은 근거에 대한 책임 있는 대응은 자산이 존재하지 않는다는 주장이 아니라 통제된 증명 요청입니다.

두 등급은 평균 내서는 안 됩니다. 가시적 글로벌 네트워크는 비어 있는 장비 일정을 채울 수 없습니다. 732랙 호스트 인증서는 ZDNS의 귀속 용량을 강화하는 데 사용될 수 없습니다. 일일 에스크로 서술은 한 번도 공개된 적 없는 경로 철수 결과를 끌어올릴 수 없습니다. 각 근거 형태는 자신의 주장에 속합니다.

이 분리는 조달에 유용한 이유가 다음 의사결정 관문을 식별하기 때문입니다. 구매자는 ZDNS가 가시적 서비스를 갖고 있는지를 다시 다룰 필요가 없습니다. 구매자는 관련 서비스 뒤의 자원의 양, 독립성과 테스트된 사용 가능성을 검증해야 합니다. ZDNS가 사이트 매트릭스, 재고, 부하 데이터와 실행된 복구 기록을 제공할 수 있다면, 약한 등급은 바뀔 수 있습니다. 그때까지는 약함으로 남아야 합니다.

결정은 “신뢰하거나 거부하거나”가 아니라 “빠진 층을 검증하라”입니다

ZDNS의 공개 존재는 진지한 평가를 받을 만큼 충분히 실질적입니다. 근거는 글로벌하게 가시적인 라우팅, 공시된 위치 의존, 식별 가능한 위임 도메인과 문서화된 통제 의도를 갖춘 실제 레지스트리 및 권위적 DNS 운영을 뒷받침합니다. 그 기록을 마케팅에만 환원하는 것은 부정확할 것입니다.

그 가시성을 자산 주장으로 변환하는 것도 똑같이 부정확할 것입니다. 검토된 자료 어느 것도 외부인이 732랙 베이징 시설의 어떤 몫도 ZDNS에 예약할 수 있게 하지 않습니다. 어느 것도 다른 명명된 위치에서 회사의 장비를 수량화하지 않습니다. 어느 것도 최대 사이트가 제거된 후 남는 예비 용량을 보여주지 않습니다. 어느 것도 경로 수렴, 사이트 간 부하 흡수, 데이터베이스 복원, DNSSEC 비상 처리, 에스크로 검증과 달성된 RTO/RPO에 대한 완전하고 날짜가 기재된 결과 집합을 제공하지 않습니다.

그렇게 남는 것은 명확한 조달 자세입니다. 관측 가능한 것은 인정합니다. 네트워크 및 논리적 서비스 층은 중간 근거로 취급합니다. 귀속 가능한 물리적 용량과 사용 가능한 페일오버 여유는 약하게 유지합니다. ZDNS에 광범위한 보증이 아니라 범위가 정해진 기록으로 공백을 메우도록 요청합니다. 각 기록을 구매하는 레지스트리, 호스티드 DNS 또는 고객 자산 표면에 맞춥니다.

가장 시사적인 질문은 단순합니다: 관련 최대 사이트가 마지막으로 이용 불가능하게 만들어진 때를 보여달라, 그곳의 작업이 어디로 옮겨졌는지, 얼마나 많은 마진이 남았는지, 데이터와 서명 상태가 독립적으로 회복 가능했는지. 만족스러운 답은 8행 지리, 라우팅 설계, 시설 의존과 복구 통제를 하나의 측정된 운영 이야기로 연결할 것입니다.

그 이야기가 나올 때까지, ZDNS는 글로벌하게 가시적이라고 합리적으로 서술될 수 있습니다. 그러나 공개 근거만으로는 호스트의 랙을 배정받거나 입증된 페일오버 여유를 인정받을 수 없습니다.