스마트 컨트랙트를 넘어서: Web3에서의 도메인 및 DNS 운영 보안

1. 오프체인 진입점: web3 운영 보안이 시작되는 곳

web3 프로젝트의 보안 경계는 오래전부터 스마트 컨트랙트를 넘어 확장되어 왔습니다. 유출된 서버 키, 변조된 프론트엔드, 하이재킹된 DNS 확인 — 이러한 일들은 컨트랙트 외부에서 발생하지만, 사용자가 어떤 페이지를 불러오고 어떤 트랜잭션에 서명하는지를 직접적으로 바꿔놓습니다. 사용자 입장에서는 공격이 온체인에서 일어났는지 오프체인에서 일어났는지는 거의 중요하지 않습니다. 중요한 것은 잘못된 진입점으로 유도되었는지 여부입니다.

컨트랙트 감사는 비교적 성숙한 편입니다. 오프체인 운영 보안은 그렇지 않습니다: 프로젝트 팀이 지속적으로 적용할 수 있고 제3자가 검증할 수 있는 공통 프레임워크가 오랫동안 부재했습니다. Security Alliance가 발표한 개방형 운영 보안 인증 프레임워크인 SEAL Certifications [1]은 바로 이 공백을 겨냥해 만들어졌습니다. 이 프레임워크는 운영 보안을 멀티시그 운영, 트레저리 운영, 인시던트 대응, 데브옵스 및 인프라, DNS 및 등록기관, 신원 및 계정 관리라는 6개 모듈로 나눕니다.

이 글은 그 흐름을 따라 여섯 가지 중 하나인 DNS 및 등록기관을 살펴봅니다. 이는 사용자가 프로젝트에 도달하는 경로의 가장 앞단에 위치하며, 그렇기에 공격자가 컨트랙트 수준의 방어를 우회하는 가장 직접적인 방법이 됩니다. 우리는 운영 보안에 대한 전수 평가를 시도하지 않았습니다. 외부 관점을 취해 더 좁은 질문을 던졌습니다: 주요 프로젝트들이 사용자 앞에 내놓는 공개 진입점은 얼마나 잘 구성되어 있는가?

이 질문에 답하기 위해, 우리는 SEAL DNS 및 등록기관 모듈 [2]을 기반으로 BlockSec DNS Security Scanner(BDSS)를 개발한 뒤, DefiLlama TVL Top 100에 속한 100개의 고유 도메인을 대상으로 실행했습니다 — 각 도메인당 8개의 표준화된 점검, 총 800건의 점검입니다. 수동 확인을 거친 결과, 기준선 격차는 광범위하면서도 몇 가지 통제 항목에 집중되어 있는 것으로 드러났습니다: 표본 중 단 1%만이 모든 점검을 통과했으며, 열 개 중 아홉 개 이상의 도메인이 최소 하나 이상의 진입점 신호를 드러냈습니다. 72%는 CAA 레코드가 없었고 47%는 DNSSEC 검증 결함을 보였으며, 이메일 인증과 도메인 잠금에서도 뚜렷한 부족함이 드러났습니다.

2. DNS 및 등록기관: 사용자 앞에 놓인 보안 경계

DNS는 사람이 읽을 수 있는 도메인을 접근 가능한 서비스 주소로 변환합니다. 이는 사용자가 프로젝트의 웹사이트, 트레이딩 프론트엔드, 문서, 비즈니스 API, 공식 이메일에 도달하는 오프체인 진입점입니다. 확인 경로나 도메인에 대한 통제권이 침해되면, 사용자는 눈치채지 못한 채 위조된 페이지로 이동할 수 있으며 — 이후에 이어지는 모든 지갑 연결, 서명, 트랜잭션은 그 기반을 잃게 됩니다. 따라서 DNS와 등록기관은 일반적인 인프라 설정으로 취급되어서는 안 되며, 프로젝트의 운영 보안 경계 안에 포함되어야 합니다.

공개된 사건들은 이미 이 위험을 구체적으로 보여주었습니다. Curve Finance는 2022년과 2025년에 각각 DNS 하이재킹을 당했습니다 [3][4]. 2023년 10월, 사회공학적 공격자가 Galxe의 등록기관 계정을 탈취하여 방문자를 악성 프론트엔드로 유도했고, 프로젝트 측은 약 1,120명의 사용자가 영향을 받았다고 공개했습니다 [5]. 2025년에는 Aerodrome Finance의 주요 도메인이 프론트엔드 공격을 당했습니다 [6]. 2026년 4월에는 공격자가 CoW Swap의 도메인을 장악하여 사용자를 피싱 페이지로 유도했고, 피해 규모는 약 120만 달러로 추정됩니다 [7]. 앞서 발생한 cBridge BGP 경로 하이재킹 사건은 또 다른 점을 시사합니다: 사용자는 브라우저 경고에만 의존해서는 진입점이 잘못되었음을 항상 알 수 없다는 것입니다 [8]. 이 각각의 사례에서 온체인 컨트랙트 자체가 반드시 손상된 것은 아니었지만, 접근 경로를 잃었다는 이유만으로 사용자 자금이 위험에 처했습니다.

원인은 저마다 다르지만, 사용자 진입점에 직접적으로 관련된 네 가지 공격 경로로 귀결됩니다. 첫째, 공격자가 DNS 레코드나 확인 경로를 변경하여 방문자를 악성 프론트엔드로 유도합니다. 둘째, 인증서 발급 통제가 우회되거나 잘못 구성되어, 위조된 사이트가 브라우저가 신뢰하는 TLS 인증서를 획득하게 됩니다. 셋째, 등록기관 계정이나 도메인 통제권이 탈취되어 도메인 이전이나 NS 등 핵심 레코드 변경이 가능해집니다. 넷째, 공격자가 프로젝트의 브랜드나 이메일을 사칭하여 사용자를 피싱 페이지로 유인합니다. 이 네 가지 모두 같은 결과로 끝날 수 있습니다: 사용자가 잘못된 인터페이스에 도달하여 잘못된 서명, 승인, 또는 트랜잭션을 완료하도록 유도됩니다.

근본적인 요지는 이렇습니다: 사용자 진입점은 독립된 웹페이지가 아니라, 도메인 통제, DNS 확인, TLS 인증서, 공식 커뮤니케이션으로 구성된 신뢰의 사슬입니다. 온체인 컨트랙트가 완벽하더라도, 한 고리라도 실패하면 공격자는 프로젝트 자체의 도메인이나 브랜드를 이용해 사용자를 잘못된 페이지와 잘못된 트랜잭션 흐름으로 유도할 수 있습니다. 프로젝트 팀 입장에서 목표는 단 하나의 설정을 개별적으로 수정하는 것이 아니라, 도메인이 무단으로 이전될 수 없도록 하고, 확인이 조용히 변경될 수 없도록 하며, 인증서 발급이 적절히 제한되고, 공식 이메일이 사칭하기 어렵도록 하는 것입니다. 이어지는 외부 스캔은 공개 인터넷에서 관찰 가능한 이 사슬의 부분을 다룹니다.

3. BDSS: 설계와 범위

이러한 진입점 위험을 팀이 실제로 실행에 옮길 수 있는 작업으로 전환하기 위해, 우리는 SEAL DNS 및 등록기관 모듈 [2]에서 외부적으로 관찰 가능한 통제 항목들을 중심으로 BDSS를 구축했습니다. 이는 프로젝트의 내부 검토를 대체하려는 것이 아닙니다. 민감한 운영 자료를 건드리지 않고 공개적인 구성 격차를 드러내는 기준선을 세우는 것입니다.

SEAL DNS 및 등록기관 모듈 [2]은 완전한 평가 프레임워크를 제시하며, 확인, 인증서, 이메일, 도메인 통제와 같은 기술적 통제뿐 아니라 도메인 자산 관리, 계정 접근 통제, 변경 관리, 모니터링 및 경보, 인시던트 대응 등의 운영 요건까지 포괄합니다.

BDSS는 이를 외부에서 관찰하고 검증할 수 있는 통제 항목으로 좁혀, 확인, 인증서, 이메일, 등록기관 측면에서 공개적으로 드러나는 구성 위험 신호를 대규모로 식별할 수 있도록 합니다. 여기에는 8개의 표준화된 점검이 포함됩니다.

BDSS는 프로젝트 DNS에 대한 완전한 보안 인증에 해당하지 않습니다. 레지스트리 잠금, 변경 승인, 복구 절차 등 공개 인터넷에서 검증할 수 없는 통제 항목은 여전히 프로젝트 자체의 문서 및 프로세스를 대조해 검토할 필요가 있습니다.

4. DefiLlama Top 100 전반의 외부 스캔 결과

이 평가는 2026년 8월 17일 당시의 DefiLlama TVL Top 100을 대상으로 완료되었습니다. 주요 도메인은 사용자에게 제공되는 공개 진입점을 시작점으로 삼아 식별되었습니다. 중복 후보, 비공식 사이트, 용도를 확인할 수 없는 도메인은 수동 확인을 거쳐 제외되었으며, 100개의 고유 도메인이 남았습니다. 각 도메인은 사용자 진입점 위험 기준선에 대해 8개의 표준화된 점검을 통해 실행되었습니다. 결과는 공개 인터넷에서 관찰 가능한 구성 상태만을 설명하며, 내부 프로세스 평가나 공식 인증을 대체하지 않습니다. 각 점검은 세 가지 상태 중 하나로 귀결됩니다. PASS는 공개적으로 확인 가능한 구성이 SEAL DNS 및 등록기관 모듈에서 파생된, 개별 점검이 구현하는 외부적으로 관찰 가능한 기준을 충족했음을 의미합니다. WARN은 주의가 필요한 신호를 표시합니다 — 만료가 임박한 인증서나 도메인, 다수의 CAA 승인 CA, 지나치게 긴 TTL 등입니다. FAIL은 SEAL 통제의 명시적 요구사항이 충족되지 않았음을 의미하거나(예: DMARC가 p=reject로 설정되지 않음), 해당 보안 구현이 충족되지 않았음을 의미합니다(예: SPF DNS 조회가 10회를 초과).

4.1 전체 결과

이번 스캔은 100개 도메인을 대상으로 각각 8개의 표준화된 점검을 실시하여 총 800건의 결과를 산출했으며, 그중 FAIL이 232건, WARN이 119건이었습니다. 도메인 단위로 집계하면, 86개는 최소 하나 이상의 FAIL을 기록했고, 13개는 FAIL 없이 최소 하나 이상의 WARN을 기록했으며, 단 1개만이 모든 점검을 통과했습니다. 다시 말해, 관찰된 공개 진입점 중에서 DNS 운영 보안 기준선 통제를 완전히 충족하는 경우는 여전히 예외적입니다.

점검 유형별로 보면, FAIL 결과는 CAA, DNSSEC, 이메일 인증이라는 세 영역에 집중되어 있으며, WARN 결과는 CAA 권한 범위와 도메인 만료 상태에서 가장 자주 나타났습니다. 아래 표는 각 점검 항목의 PASS, WARN, FAIL 분포와 각 결과의 주된 원인을 보여줍니다.

4.2 주요 구성 격차

종합하면, 주요 프로젝트들의 공개 DNS 구성 기준선은 여전히 불충분한 수준이며, 격차는 특정 하나의 기술적 통제에 집중되어 있지 않습니다. CAA 누락, 불완전한 DNSSEC 신뢰 사슬, 관대한 이메일 인증 정책, 그리고 여전히 검증이 필요한 등록기관 측 보호 조치는 각각 인증서 발급, 확인 신뢰성, 브랜드 커뮤니케이션, 도메인 통제에 영향을 미칩니다. 이들을 종합하면 사용자가 공식 진입점에 도달할 때 암묵적으로 의존하는 조건들을 구성합니다. 다음은 네 가지 대표적인 격차입니다.

1. CAA 발급 제약이 전반적으로 부재합니다: 72개 도메인에 CAA가 구성되어 있지 않았습니다. CAA 레코드는 어떤 CA가 도메인에 대해 TLS 인증서를 발급할 수 있는지를 제한합니다 [9]. 이것이 없다고 해서 공격자에게 곧바로 인증서를 넘겨주는 것은 아니지만, 프로젝트가 DNS를 통한 추가적인 발급 경계를 설정하지 않았다는 것을 의미합니다. 도메인 검증이나 관련 제어 평면이 침해될 경우, 인증서 요청을 수락할 수 있는 CA의 범위를 제한하기가 그만큼 더 어려워집니다. web3 프론트엔드의 경우, CAA는 주로 복합 공격 시나리오에서 중요해집니다: 도메인 검증, DNS 확인, 트래픽 전달을 동시에 방해하는 공격자는 추가적인 CA 범위 제약에 직면하지 않게 되어, 위조된 프론트엔드가 브라우저가 신뢰하는 인증서를 제시할 가능성이 커집니다.

2. DNSSEC 신뢰 사슬이 불완전합니다: 47개 도메인이 검증에 실패했습니다. 실패는 주로 DNSKEY 누락(34개 도메인) 또는 상위 존의 DS 누락(40개 도메인)으로 나타났으며, 두 경우가 서로 겹치기도 했습니다. 이러한 레코드가 없으면 외부 검증 리졸버가 완전한 DNSSEC 신뢰 사슬을 구축할 수 없습니다 [10]. DNSSEC이 등록기관 계정 탈취나 프론트엔드 코드 변조를 막아주지는 않지만, 확인 결과가 위조되거나 캐시 포이즈닝을 당했는지 검증하는 데는 도움이 됩니다. 사용자에게 지갑 연결과 트랜잭션 서명을 요구하는 프로토콜의 경우, 이 검증 계층이 부재하다는 것은 인터페이스가 본질적으로 달라 보이지 않는데도 사용자가 잘못된 주소, 서버, 컨트랙트로 유도될 수 있음을 의미합니다.

3. 이메일 인증 정책이 취약합니다: 38건이 점검에 실패했습니다. 일부 도메인은 여러 문제를 동시에 안고 있었습니다: 35개는 DMARC 정책을 p=reject로 올리지 않았고 [11], 6개는 rua 집계 보고 주소가 구성되어 있지 않았으며, 4개는 SPF 권한 체인이 지나치게 길었습니다 [12]. 관대한 DMARC 정책은 사칭 메일에 대한 강제력을 약화시키고, rua의 부재는 지속적인 모니터링을 저해하며, SPF 조회 한도를 초과하면 검증 오류가 발생할 수 있습니다. 프로젝트 이메일이 보안 권고, 에어드랍 안내, 마이그레이션 공지를 일상적으로 전달한다는 점을 고려하면, 이러한 격차는 사칭 메일을 위조된 프론트엔드나 피싱 흐름으로 유도하는 더 효과적인 통로로 만듭니다.

4. 도메인 통제 보호 조치는 여전히 검증이 필요합니다: 3개 도메인은 이전 잠금이 없었고, 다른 90개 도메인은 레지스트리 잠금 상태가 불확정이었습니다. 공개 RDAP 상태에서 비교적 완전한 잠금 신호 세트를 보인 도메인은 단 7개뿐이었으며, 나머지 대부분은 이전 잠금만 확인할 수 있었고, 레지스트리 잠금이 활성화되어 있는지는 등록기관 콘솔이나 레지스트리 문서를 통해 확인해야 합니다. 이전 잠금은 무단 이전에 대한 기본적인 조치이며, 레지스트리 잠금은 주요 프론트엔드, 문서, API를 담당하는 고가치 도메인에 더 적합합니다. 갱신 관리도 통제권의 연속성에 영향을 미칩니다: 이번 스캔에서 30일 경보 창 내에 있는 TLS 인증서 2개, 90일 만료 알림 창 내에 있는 도메인 10개를 발견했습니다. 핵심 진입점을 담당하는 도메인의 경우, 자동 갱신, 단계별 알림, 지정된 주 소유자 및 백업 소유자와 같은 통제 조치를 통해 만료되는 인증서나 도메인이 서비스 중단이나 진입점 통제권 상실로 이어지지 않도록 할 수 있습니다.

5. 이번 결과가 오늘날 web3 DNS 보안에 대해 말해주는 것

이번 스캔은 주요 DeFi 프로젝트들의 공개 DNS 구성 기준선이 여전히 불충분하게 커버되고 있음을 보여줍니다. 100개 도메인 중 단 1개만이 모든 점검을 통과했고, 86개는 최소 하나 이상의 FAIL을 기록했습니다. 주요 격차는 CAA, DNSSEC, 이메일 인증, 도메인 잠금과 관련되어 있으며 — 이는 각각 인증서 발급 제약, 확인 검증, 브랜드 커뮤니케이션, 도메인 자체에 대한 통제에 영향을 미칩니다.

이러한 격차는 확인 계층이나 어느 하나의 기술적 통제에 국한되지 않습니다. 도메인, 확인, 인증서, 이메일이라는 사용자 진입 경로상의 여러 서로 다른 고리에 걸쳐 퍼져 있습니다. 특히 CAA와 DNSSEC의 얕은 커버리지는 도메인 통제, 인증서, 확인 경로가 사용자 바로 앞에 놓여 있음에도 불구하고, 이러한 진입점 통제가 표본 전반에 걸쳐 아직 일관되게 배포되어 있지 않다는 것을 보여줍니다. 이러한 외부 신호들 중 어느 것도 프로젝트가 침해당했음을 나타내지는 않습니다. 하지만 공격자가 DNS 확인을 방해하거나, 비정상적인 절차로 유효한 인증서를 획득하거나, 등록기관 계정을 탈취하거나, 공식 이메일을 사칭할 때, 부재한 통제는 이미 마련된 방어를 약화시켜 사용자가 위조된 페이지나 피싱 흐름으로 유도되기 쉽게 만듭니다. 인증서 및 도메인 갱신 관리가 부적절할 경우 공식 진입점 자체가 중단될 수도 있습니다.

BDSS는 공개 인터넷에서 구성 격차를 식별하고 비교 가능한 외부 보안 기준선을 세울 수 있습니다. 그러나 레지스트리 잠금, 등록기관 계정 MFA, 핵심 변경 확인, 모니터링 및 경보, 인시던트 대응과 같은 운영 통제는 적절히 입증할 수 없습니다 — 이들 중 어느 것도 공개 기록만으로는 확립될 수 없기 때문입니다. 따라서 공개 신호는 업계의 상태를 설명하고 추가 검증이 필요한 영역을 식별하는 데는 적합하지만, 어떤 프로젝트의 실제 운영 역량에 대한 최종 판단으로 읽혀서는 안 됩니다. 이러한 경계 안에서 작동할 때, 외부 스캔과 SEAL Certifications는 서로를 보완합니다: 전자는 공개 구성 격차를 지속적으로 관찰 가능하고 비교 가능하게 만들며, 후자는 운영 문서와 실제 프로세스를 바탕으로 도메인 자산, 등록기관 접근 통제, 변경 관리, 인시던트 대응에 대한 내부 통제를 검증합니다. SEAL Certifications의 1기 공인 감사기관이자 — 아시아 유일의 공인 감사기관으로서 — BlockSec은 이 프레임워크 안에서 프로젝트가 자신의 운영 보안을 체계적으로 평가하도록 도울 수 있습니다.

References

[1] Security Alliance. SEAL Certifications Overview. https://frameworks.securityalliance.org/certs/overview/

[2] Security Alliance. SEAL Certification Framework: DNS Registrar. https://frameworks.securityalliance.org/certs/sfc-dns-registrar/

[3] Curve Finance. 2022 DNS incident statement. https://x.com/CurveFinance/status/1557505570533478403

[4] Curve Finance. 2025 domain incident statement. https://news.curve.finance/curve-domain-incident/

[5] Galxe. October 6th DNS Security Incident Statement & Guide. https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide

[6] Aerodrome Finance. Domain incident statement. https://x.com/AerodromeFi/status/1992097133869375783

[7] CoW Swap. Domain incident statement. https://x.com/CoWSwap/status/2044924940886163780

[8] Celer Network. cBridge routing incident statement. https://x.com/CelerNetwork/status/1560022871564775424

[9] Hallam-Baker and Stradling. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. https://www.rfc-editor.org/rfc/rfc8659.html

[10] Arends et al. RFC 4033: DNS Security Introduction and Requirements. https://www.rfc-editor.org/rfc/rfc4033.html

[11] Kucherawy and Zwicky. RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://www.rfc-editor.org/rfc/rfc7489.html

[12] Kitterman. RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. https://www.rfc-editor.org/rfc/rfc7208.html