Akıllı Sözleşmenin Ötesinde: Web3'te Alan Adı ve DNS Operasyonel Güvenliği

1. Zincir dışı giriş noktası: web3 operasyonel güvenliği nerede başlar

Bir web3 projesinin güvenlik sınırı, uzun süredir akıllı sözleşmelerinin ötesine uzanıyor. Sızdırılmış sunucu anahtarları, kurcalanmış ön uçlar, ele geçirilmiş DNS çözümlemesi — bunlar sözleşmenin dışında gerçekleşir, ancak kullanıcının hangi sayfayı yükleyeceğini ve hangi işlemi imzalayacağını doğrudan değiştirir. Kullanıcı açısından, saldırının zincir üstünde mi yoksa zincir dışında mı gerçekleştiği pek önemli değildir. Önemli olan, yanlış giriş noktasına yönlendirilip yönlendirilmediğidir.

Sözleşme denetimleri kıyasla daha olgunlaşmış durumdadır. Zincir dışı operasyonel güvenlik öyle değildir: proje ekiplerinin sürekli uygulayabileceği ve üçüncü bir tarafın doğrulayabileceği ortak bir çerçeve uzun süredir eksik kalmıştır. Security Alliance tarafından yayınlanan açık operasyonel güvenlik sertifikasyon çerçevesi SEAL Certifications [1], tam olarak bu boşluğun etrafında inşa edilmiştir. Operasyonel güvenliği altı modüle ayırır: çoklu imza işlemleri, hazine işlemleri, olay müdahalesi, DevOps ve altyapı, DNS ve kayıt kuruluşu, kimlik ve hesap yönetimi.

Bu makale, bu ipliği altı modülden birine — DNS ve kayıt kuruluşu — takip eder. Bu modül, kullanıcıların bir projeye ulaşmak için izlediği yolun tam başında yer alır, bu da onu bir saldırganın sözleşme düzeyindeki savunmaları atlatabileceği en doğrudan yol haline getirir. Kapsamlı bir operasyonel güvenlik değerlendirmesi yapmaya çalışmadık. Dışsal bir bakış açısı benimseyerek daha dar bir soru sorduk: lider projelerin kullanıcılarının önüne koyduğu kamuya açık giriş noktaları ne kadar iyi yapılandırılmış durumda?

Bu soruyu yanıtlamak için, SEAL DNS ve kayıt kuruluşu modülü [2] temelinde BlockSec DNS Security Scanner'ı (BDSS) geliştirdik, ardından bunu DefiLlama TVL Top 100 listesine ait 100 benzersiz alan adı üzerinde çalıştırdık — her biri için sekiz standart kontrol, toplamda 800 kontrol. Manuel doğrulama sonrasında, temel eksikliklerin hem yaygın hem de belirli bir avuç kontrolde yoğunlaştığı ortaya çıktı: örneğin sadece %1'i tüm kontrolleri geçti, ve on domainden dokuzundan fazlası en az bir giriş noktası sinyali verdi. %72'sinde CAA kaydı yoktu ve %47'sinde DNSSEC doğrulama kusurları görüldü, e-posta kimlik doğrulaması ve alan adı kilitleme ise kendi başlarına belirgin eksiklikler ortaya koydu.

2. DNS ve kayıt kuruluşu: kullanıcının önündeki güvenlik sınırı

DNS, insan tarafından okunabilir bir alan adını erişilebilir bir hizmet adresine dönüştürür. Kullanıcıların bir projenin web sitesine, ticaret ön ucuna, belgelerine, iş API'lerine ve resmi e-postasına ulaştığı zincir dışı giriş noktasıdır. Çözümleme yolu veya alan adının kontrolü tehlikeye girdiğinde, bir kullanıcı fark etmeden sahte bir sayfaya yönlendirilebilir — ve bunu takip eden her cüzdan bağlantısı, imza ve işlem temelini kaybeder. Bu nedenle DNS ve kayıt kuruluşu, sıradan bir altyapı yapılandırması olarak ele alınmamalı; projenin operasyonel güvenlik sınırının içinde yer almalıdır.

Kamuya açık olaylar riski zaten somutlaştırdı. Curve Finance 2022'de ve yeniden 2025'te DNS ele geçirme saldırısına uğradı [3][4]. Ekim 2023'te, sosyal mühendislik yöntemi kullanan bir saldırgan Galxe'nin kayıt kuruluşu hesabını ele geçirdi ve ziyaretçileri kötü amaçlı bir ön uca yönlendirdi; proje, yaklaşık 1.120 kullanıcının etkilendiğini açıkladı [5]. 2025'te, Aerodrome Finance'ın birincil alan adı bir ön uç saldırısına maruz kaldı [6]. Nisan 2026'da, bir saldırgan CoW Swap'ın alan adının kontrolünü ele geçirdi ve kullanıcıları bir kimlik avı sayfasına yönlendirdi, kayıpların yaklaşık 1,2 milyon dolar olduğu tahmin ediliyor [7]. Daha önceki cBridge BGP rota ele geçirme olayı ise bir başka noktayı ortaya koyuyor: kullanıcılar giriş noktasının bozulduğunu her zaman bir tarayıcı uyarısına güvenerek anlayamayabilir [8]. Bu olayların her birinde zincir üstü sözleşme mutlaka bozulmamıştı, ancak erişim yolu kaybedildiği için kullanıcı fonları yine de risk altındaydı.

Nedenler farklılık gösterir, ancak kullanıcının giriş noktasını doğrudan etkileyen dört saldırı yoluna indirgenebilirler. Birincisi, bir saldırgan DNS kayıtlarını veya çözümleme yolunu değiştirerek ziyaretçileri kötü amaçlı bir ön uca yönlendirir. İkincisi, sertifika verme kontrolleri atlatılır veya yanlış yapılandırılır, bu da sahte bir sitenin tarayıcı tarafından güvenilen bir TLS sertifikası almasına izin verir. Üçüncüsü, bir kayıt kuruluşu hesabı veya alan adı kontrolü ele geçirilir, bu da alan adı transferine veya NS gibi kritik kayıtlarda değişikliklere izin verir. Dördüncüsü, bir saldırgan projenin markasını veya e-postasını taklit ederek kullanıcıları bir kimlik avı sayfasına çeker. Bu dördü de aynı şekilde sonuçlanabilir: kullanıcı yanlış arayüze ulaşır ve yanlış imza, onay veya işlemi tamamlamaya yönlendirilir.

Altta yatan nokta şudur: bir kullanıcı giriş noktası bağımsız bir web sayfası değil, alan adı kontrolü, DNS çözümlemesi, TLS sertifikaları ve resmi iletişimden oluşan bir güven zinciridir. Kusursuz bir zincir üstü sözleşme olsa bile, tek bir bağlantının başarısız olması bir saldırganın projenin kendi alan adını veya markasını kullanarak kullanıcıları yanlış sayfaya ve yanlış işlem akışına yönlendirmesine olanak tanır. Bir proje ekibi için amaç, tek bir ayarı ayrı ayrı düzeltmek değil, alan adının izinsiz transfer edilememesini, çözümlemenin sessizce değiştirilememesini, sertifika vermenin uygun şekilde sınırlandırılmasını ve resmi e-postanın taklit edilmesinin zorlaştırılmasını sağlamaktır. Bunu takip eden dışsal tarama, bu zincirin kamuya açık internetten gözlenebilen bölümünü kapsamaktadır.

3. BDSS: tasarım ve kapsam

Bu giriş noktası risklerini bir ekibin gerçekten üzerinde çalışabileceği işlere dönüştürmek için, BDSS'yi SEAL DNS ve kayıt kuruluşu modülündeki [2] dışsal olarak gözlemlenebilir kontroller etrafında geliştirdik. Bir projenin iç incelemesinin yerini almayı amaçlamaz. Herhangi bir hassas operasyonel materyale dokunmadan kamuya açık yapılandırma eksikliklerini ortaya çıkarmak için bir temel oluşturur.

SEAL DNS ve kayıt kuruluşu modülü [2], hem çözümleme, sertifikalar, e-posta, alan adı kontrolü gibi teknik kontrolleri hem de alan adı varlık yönetimi, hesap erişim kontrolü, değişiklik yönetimi, izleme ve uyarı, olay müdahalesi gibi operasyonel gereksinimleri kapsayan eksiksiz bir değerlendirme çerçevesi ortaya koyar.

BDSS bunu, çözümleme, sertifikalar, e-posta ve kayıt kuruluşu tarafında ölçek genelinde kamuya açık yapılandırma risk sinyallerinin belirlenebilmesi için dışsal olarak gözlemlenebilen ve doğrulanabilen kontrollere indirger. Sekiz standart kontrolü kapsar.

BDSS, bir projenin DNS'inin tam bir güvenlik sertifikasyonuna eşdeğer değildir. Sicil kilidi, değişiklik onayı, kurtarma prosedürleri gibi kamuya açık internetten doğrulanamayan kontroller, hâlâ projenin kendi belgeleri ve süreçlerine karşı incelenmeyi gerektirmektedir.

4. DefiLlama Top 100 genelinde dışsal tarama sonuçları

Değerlendirme, o tarihteki DefiLlama TVL Top 100 listesi kullanılarak 17 Ağustos 2026'da tamamlandı. Birincil alan adları, kullanıcılara sunulan kamuya açık giriş noktalarından başlanarak belirlendi. Yinelenen adaylar, resmi olmayan siteler ve amacı belirlenemeyen alan adları manuel doğrulama sonrasında hariç tutuldu, geriye 100 benzersiz alan adı kaldı. Her biri, kullanıcı giriş noktası risk temeline karşı sekiz standart kontrolden geçirildi. Sonuçlar yalnızca kamuya açık internetten gözlemlenebilen yapılandırma durumunu tanımlar; iç süreçlerin bir değerlendirmesinin veya resmi bir sertifikasyonun yerini tutmaz. Her kontrol üç durumdan birine çözümlenir. PASS (GEÇTİ), kamuya açık şekilde görülebilen yapılandırmanın, ilgili kontrolün uyguladığı ve SEAL DNS ve kayıt kuruluşu modülünden türetilen dışsal olarak gözlemlenebilir ölçütü karşıladığı anlamına gelir. WARN (UYARI), dikkat gerektiren sinyalleri işaret eder — süresi dolmaya yaklaşan bir sertifika veya alan adı, çok sayıda CAA yetkili CA, aşırı uzun bir TTL. FAIL (BAŞARISIZ), bir SEAL kontrolünün açık bir gerekliliğinin karşılanmadığı anlamına gelir (örneğin, DMARC'ın p=reject olarak ayarlanmaması) veya ilgili güvenlik uygulamasının karşılanmadığı anlamına gelir (örneğin, ondan fazla SPF DNS sorgusu).

4.1 Genel sonuçlar

Tarama, her biri sekiz standart kontrole tabi tutulan 100 alan adını kapsadı ve 800 sonuç üretti: 232 FAIL ve 119 WARN. Alan adına göre sayıldığında, 86'sı en az bir FAIL aldı, 13'ünde FAIL yoktu ama en az bir WARN vardı, ve sadece 1'i tüm kontrolleri geçti. Başka bir deyişle, gözlemlenen kamuya açık giriş noktaları arasında, temel DNS operasyonel güvenlik kontrollerinin tam kapsamı hâlâ istisna niteliğinde.

Kontrol türüne göre, FAIL sonuçları üç alanda kümeleniyor — CAA, DNSSEC ve e-posta kimlik doğrulaması — WARN sonuçları ise en sık CAA yetkilendirme kapsamı ve alan adı süre dolumu durumunda görülüyor. Aşağıdaki tablo her kontrol için PASS, WARN ve FAIL dağılımını, her sonucun temel kaynağıyla birlikte vermektedir.

4.2 Temel yapılandırma eksiklikleri

Bir bütün olarak ele alındığında, lider projeler arasındaki kamuya açık DNS yapılandırma temeli hâlâ yetersiz ve eksiklikler tek bir teknik kontrolde yoğunlaşmıyor. Eksik CAA, eksik DNSSEC güven zincirleri, gevşek e-posta kimlik doğrulama politikası ve hâlâ doğrulama gerektiren kayıt kuruluşu tarafı korumaları sırasıyla sertifika verme, çözümleme güvenilirliği, marka iletişimi ve alan adı kontrolünü etkilemektedir. Bunlar bir araya geldiğinde, bir kullanıcının resmi bir giriş noktasına ulaştığında dolaylı olarak güvendiği koşulları oluşturur. Aşağıda dört temsili eksiklik yer almaktadır.

1. CAA verme sınırlamaları büyük ölçüde eksik: 72 alan adında CAA yapılandırılmamıştı. Bir CAA kaydı, hangi CA'ların bir alan adı için TLS sertifikaları verebileceğini sınırlar [9]. Bunun eksikliği bir saldırgana doğrudan bir sertifika vermez, ama projenin DNS aracılığıyla ek bir verme sınırı belirlememiş olduğu anlamına gelir. Alan adı doğrulaması veya ilgili bir kontrol düzlemi ele geçirilirse, sertifika talebini kabul edebilecek CA kümesinin sınırlandırılması o kadar daha zor hale gelir. Web3 ön uçları için CAA esas olarak bileşik saldırı senaryolarında önem taşır: aynı anda alan adı doğrulamasını, DNS çözümlemesini veya trafik yönlendirmesini bozan bir saldırgan, ek bir CA kapsamı sınırlamasıyla karşılaşmaz, bu da sahte bir ön ucun tarayıcı tarafından güvenilen bir sertifika sunabilme olasılığını artırır.

2. DNSSEC güven zincirleri eksik: 47 alan adı doğrulamada başarısız oldu. Başarısızlıklar çoğunlukla eksik bir DNSKEY (34 alan adı) veya eksik bir üst bölge DS'i (40 alan adı) olarak ortaya çıktı, ikisi arasında örtüşme mevcut. Bu kayıtlar olmadan, dışsal bir doğrulayıcı çözücü tam bir DNSSEC güven zinciri oluşturamaz [10]. DNSSEC bir kayıt kuruluşu hesabı ele geçirmesini veya ön uç kodunun kurcalanmasını önlemez, ama bir çözümleme sonucunun sahtelenip sahtelenmediğini veya önbellek zehirlenmesine uğrayıp uğramadığını doğrulamaya yardımcı olur. Kullanıcılardan bir cüzdan bağlaması ve işlem imzalaması istenen protokoller için, bu doğrulama katmanının eksikliği, arayüz görünüşte esasen değişmemiş kalırken bir kullanıcının yanlış adrese, sunucuya veya sözleşmeye yönlendirilebilmesi anlamına gelir.

3. E-posta kimlik doğrulama politikası zayıf: 38 kontrol başarısız oldu. Bazı alan adlarında birkaç sorun aynı anda mevcuttu: 35'i DMARC politikasını p=reject'e yükseltmemişti [11], 6'sında hiç rua toplu raporlama adresi yapılandırılmamıştı, ve 4'ünde aşırı uzun bir SPF yetkilendirme zinciri vardı [12]. Gevşek bir DMARC politikası taklit e-postaya karşı uygulamayı zayıflatır, eksik bir rua sürekli izlemeyi zayıflatır ve SPF sorgu limitini aşmak doğrulama hatalarına yol açabilir. Proje e-postaları düzenli olarak güvenlik bildirimleri, airdrop talimatları ve geçiş bildirimleri taşıdığından, bu eksiklikler taklit e-postayı sahte bir ön uca veya kimlik avı akışına giden daha etkili bir giriş rampası haline getirmektedir.

4. Alan adı kontrolü korumaları hâlâ doğrulama gerektiriyor: 3 alan adında transfer kilidi görülmedi, diğer 90 alan adı için sicil kilidi durumu belirsizdi. Kamuya açık RDAP durumunda, sadece 7 alan adı makul ölçüde eksiksiz bir kilit sinyali kümesi gösterdi; kalanların çoğunda sadece transfer kilidi doğrulanabildi, sicil kilidinin etkin olup olmadığı ise kayıt kuruluşu konsolu veya sicil belgeleri üzerinden kontrol edilmelidir. Transfer kilidi, izinsiz transfere karşı temel önlemdir; sicil kilidi ise birincil ön ucu, belgeleri ve API'leri taşıyan yüksek değerli alan adları için daha uygundur. Yenileme yönetimi de kontrol sürekliliğini etkilemektedir: tarama, 30 günlük uyarı penceresi içinde 2 TLS sertifikası ve 90 günlük süre dolumu hatırlatma penceresi içinde 10 alan adı buldu. Kritik giriş noktalarını taşıyan alan adları için, otomatik yenileme, katmanlı hatırlatmalar ve belirlenmiş birincil ve yedek sahipler gibi kontroller, süresi dolan bir sertifikanın veya alan adının bir hizmet kesintisine veya giriş noktası kontrolünün kaybına dönüşmesini önleyebilir.

5. Sonuçlar web3 DNS güvenliği bugün hakkında ne söylüyor

Tarama, lider DeFi projelerindeki kamuya açık DNS yapılandırma temelinin hâlâ yetersiz şekilde kapsandığını göstermektedir. 100 alan adından yalnızca 1'i tüm kontrolleri geçti ve 86'sı en az bir FAIL aldı. Temel eksiklikler CAA, DNSSEC, e-posta kimlik doğrulaması ve alan adı kilitlerini kapsıyor — bunlar sırasıyla sertifika verme sınırlamalarını, çözümleme doğrulamasını, marka iletişimini ve alan adının kendisinin kontrolünü etkiliyor.

Bu eksiklikler çözümleme katmanıyla veya herhangi bir tek teknik kontrolle sınırlı değildir. Alan adı, çözümleme, sertifika ve e-posta genelinde — kullanıcının giriş yolundaki birkaç farklı bağlantı boyunca — dağılmışlardır. Özellikle CAA ve DNSSEC'in ince kapsamı, alan adı kontrolü, sertifikalar ve çözümleme yolu doğrudan kullanıcıların önünde yer almasına rağmen, bu giriş noktası kontrollerinin örneklem genelinde henüz tutarlı bir şekilde uygulanmadığını göstermektedir. Bu dışsal sinyallerin hiçbiri bir projenin ihlal edildiğini göstermez. Ancak bir saldırgan DNS çözümlemesine müdahale ettiğinde, düzensiz bir süreç aracılığıyla geçerli bir sertifika aldığında, bir kayıt kuruluşu hesabını ele geçirdiğinde veya resmi e-postayı taklit ettiğinde, eksik kontroller mevcut savunmaları zayıflatır ve kullanıcıların sahte bir sayfaya veya kimlik avı akışına yönlendirilmesini kolaylaştırır. Yetersiz sertifika ve alan adı yenileme yönetimi de resmi giriş noktalarını kesintiye uğratabilir.

BDSS, kamuya açık internetten yapılandırma eksikliklerini belirleyebilir ve karşılaştırılabilir bir dışsal güvenlik temeli oluşturabilir. Ancak sicil kilidi, kayıt kuruluşu hesabı MFA'sı, kritik değişiklik onayı, izleme ve uyarı veya olay müdahalesi gibi operasyonel kontrolleri yeterince gösteremez — bunların hiçbiri yalnızca kamuya açık kayıtlardan belirlenemez. Bu nedenle kamuya açık sinyaller, sektörün durumunu tanımlamak ve daha fazla doğrulama gerektiren alanları belirlemek için oldukça uygundur, ancak herhangi bir projenin gerçek operasyonel yeteneği hakkında nihai bir yargı olarak okunmamalıdır. Bu sınır içinde çalışan dışsal tarama ve SEAL Certifications birbirini tamamlar: birincisi kamuya açık yapılandırma eksikliklerini sürekli gözlemlenebilir ve karşılaştırılabilir hale getirir, ikincisi ise alan adı varlıkları, kayıt kuruluşu erişim kontrolü, değişiklik yönetimi ve olay müdahalesi üzerindeki iç kontrolleri doğrulamak için operasyonel belgelerden ve gerçek süreçlerden yararlanır. İlk grup akredite SEAL Certifications denetçisi olarak — ve Asya'daki tek denetçi olarak — BlockSec, projelerin operasyonel güvenliklerini bu çerçeve içinde sistematik olarak değerlendirmelerine yardımcı olabilir.

Referanslar

[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