Custom Domain Protection

Custom Domain Protection nedir?

“Cloudflare offers Custom Domain Protection to customers with a Cloudflare Enterprise plan and high-profile domains who need the highest level of security against domain hijacking.”

Ürün sayfasının kendi tanımı:

“Custom Domain Protection for Cloudflare Registrar, available on the Enterprise plan, protects your organization from domain hijacking with exclusively out-of-band verification of any changes to your Registrar account.”

Savunduğu tehdit

“Hijacked domain — When an attacker hijacks a domain, the owner no longer has control over the site content, email, VoIP, or any other services that rely on the domain name. This is a serious threat to an organization’s brand and reputation.”

“Compromised registrar — One way that domain hijacking occurs is when an attacker compromises a registrar account and changes the nameserver or other registration information. The registrar, believing that the changes originated from an authorized registrant, sends the new information to the registry.”

Cloudflare bu ürünü anlatırken üç gerçek olaya dayanıyor:

New York Times, 2013:

“In 2013, we became intimately familiar with this problem when domains for the New York Times were hijacked and the newspaper’s CTO reached out to us to help get it back. We were able to assist, but the newspaper had its web and email traffic rerouted for hours.”

Ve aynı yazının eklediği not önemli:

“and, it’s worth noting, the New York Times was using one of the supposedly security-focused registrars when their domain was hijacked.”

Cloudflare’in kendi hesabına yapılan saldırılar:

“We ourselves have seen multiple attempts to take control of CloudFlare’s registrar account. Thankfully, none have been successful—but some have gotten closer than we were comfortable with.”

“Unfortunately, in 2013, a hacker was able to compromise several of the systems of the registrar we used and come perilously close to taking over some of our domains.”

Yani ürün, Cloudflare’in kendi başına gelen bir olaydan doğmuş.

Nasıl çalışır?

Dokümanın tamamı üç maddeden ibaret — birebir ve eksiksiz:

• Registry lock: Cloudflare applies Registry Lock, when available, to all domains registered through Custom Domain Protection. Any changes to a domain requires Cloudflare to first unlock the domain at the registry level.
• Out-of-band authentication: All changes to domain ownership or nameserver information are verified and executed manually based on an authentication process defined by the customer.
• No interface: Custom Domain Protection does not offer an interface, to remove the possibility of domain hijack through a compromised account.

Registry lock ile registrar lock farkı

Bu ayrım ürünün tamamını anlamanın anahtarı.

“What is a registry lock? A domain registry lock prohibits deleting, transferring, or updating the nameserver of a domain name without several extra levels of authentication between the registry and the registrar. Registry locks make it much harder for an attacker to successfully hijack a domain.”

“What is a registrar lock? A domain registrar lock is a security feature that prohibits the transfer of a domain from one registrar to another. Registrar locks are indicated by a ‘clientTransferProhibited’ status in a WHOIS record.”

Ve 2016 blogundaki kritik cümle — ürünün varlık sebebi:

“Many registrars support Registrar Lock, which prevents the registry from altering information unless the lock is explicitly removed. The problem is, if an attacker compromises your registrar account, they can unlock it and make whatever changes they want.”

“Registry Lock prevents changes by any registrar until the lock is removed. Unlocking at the registry level requires out-of-band communication between the registrar and Verisign… and is thus very manual. Since most registrars are volume operations, it’s very difficult to find one that takes the time to literally pick up the phone and call Verisign every time someone makes a change.”

Değişiklik akışı

Panel yok, API yok. Süreç şöyle işliyor: hesap ekibine talep → müşterinin önceden tanımladığı yetkilendirme prosedürü (çok kişili, bant dışı) → Cloudflare registry kilidini açıyor → değişikliği elle uyguluyor → kilidi geri koyuyor.

Prosedürü müşteri belirliyor:

“Before any transfers are made, we require both online and offline confirmation from multiple independent sources. And, we can customize the authorization process in order to integrate with our customers’ change control systems. For example, if your organization requires separate authorized users from your security, engineering, and legal departments to approve a domain transfer, CloudFlare Registrar can do that.”

Cloudflare bunun ne kadar ileri gidebileceğini kendi örneğiyle anlatıyor: altı ayrı kişinin, önceden tanımlı numaralardan, sırayla arayıp benzersiz parola kodları okuması şartını bile uygulayacağını söylüyor ve cümleyi “we will enforce that. Literally.” diye bitiriyor.

Yayımlanmayan: bu sürecin SLA’sı veya tamamlanma süresi. Hiçbir resmî kaynakta yok.

Ne zaman kullanılır, ne zaman kullanılmaz

Kullanılır

Cloudflare’in kendi eşiği bundan iyi ifade edilemez:

“CloudFlare Registrar is not designed for the masses. There are plenty of great mass-market registrars. However, if you’re an organization where losing your domains would be a front-page story, then CloudFlare Registrar is for you.”

Yani: alan adının kaybı manşet haber olacaksa mantıklı. Banka, borsa, kamu kurumu, büyük medya, kripto borsası. İlk müşteriler de bunu gösteriyor: dwolla.com ve nasdaqprivatemarket.com.

Kullanılmaz

.tr alan adın varsa. Cloudflare Registrar’a taşıyamıyorsun, dolayısıyla CDP de alamıyorsun. Bu bir “henüz” değil, bugünkü kesin durum.

Türkçe karakterli (IDN) alan adın varsa. Aynı sebep.

Otomasyon planlıyorsan. Panel yok, API yok — kasten.

Hızlı değişiklik yapman gereken bir mimarin varsa. Ürünün amacı hızı öldürmek. Acil bir DNS sağlayıcı geçişi veya failover senaryosunda çok kişili bant dışı prosedür kurtarma süreni uzatıyor. Cloudflare bunu kendisi de kabul ediyor: “not the most scalable solution.”

Asıl riskin DNS kayıtları ise. CDP registrar ve registry katmanını koruyor. Hesabına giren saldırgan A kaydını değiştirip trafiğini yine yönlendirebiliyor.

Alan adı süresinin dolması riski varsa. CDP ödemeni yapmıyor. Yenileme başarısızlığı neredeyse her zaman bir ödeme sorunu ve hiçbir kilit bunu engellemiyor.

ICANN e-posta doğrulamasını yapmadıysan. 15 gün içinde doğrulamazsan hold konuyor ve nameserver’lar parking sunucusuyla değiştiriliyor. Registry lock bunu engellemiyor.

Hukukî bir işlem varsa. Alan adı “administratively locked by Cloudflare… for legal reasons such as a UDRP filing or court order” olabiliyor.

BGP, sertifika veya origin katmanı endişen varsa. Registrar güvenliği bunların hiçbiri için bir şey yapmıyor.

Somut örnekler

EPP durum kodlarını okumak

D=ornek.com

# WHOIS üzerinden
whois "$D" | grep -iE 'domain status|status:'

# RDAP üzerinden — yapılandırılmış ve daha güvenilir
curl -s "https://rdap.org/domain/$D" \
  | python3 -c 'import sys,json; print("status:", json.load(sys.stdin).get("status"))'

Hangi kod ne anlama geliyor

Hesap maruziyetini denetlemek

AUTH=(-H "Authorization: Bearer $CF_API_TOKEN")

# 2FA durumu
curl -s https://api.cloudflare.com/client/v4/user "${AUTH[@]}" \
  | jq '{iki_faktor: .result.two_factor_authentication_enabled,
         zorunlu: .result.two_factor_authentication_locked}'

# Üyeler, rolleri ve 2FA durumları
curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/members?per_page=100" "${AUTH[@]}" \
  | jq -r '.result[] | "\(.user.email)\t\(.status)\t\([.roles[].name]|join(","))\t2FA=\(.user.two_factor_authentication_enabled)"'

# Token'lar — süresiz olan var mı, IP kısıtı var mı
curl -s https://api.cloudflare.com/client/v4/user/tokens "${AUTH[@]}" \
  | jq -r '.result[] | "\(.name)\t\(.status)\tbitis=\(.expires_on // "YOK")\tson_kullanim=\(.last_used_on // "-")\tip_kisiti=\(.condition."request.ip" != null)"'

# Denetim kayıtları
curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit?limit=50" "${AUTH[@]}" | jq .

Demo 1: EPP kilitlerini ölçmek ve sertleştirmek

Adım 1 — Mevcut kilit durumunu oku

D=ornek.com
{
  echo "=== $(date -u) ==="
  echo "--- EPP durumları ---"; whois "$D" | grep -iE 'domain status|status:'
  echo "--- Registrar ---";     whois "$D" | grep -iE 'registrar:|registrar iana'
  echo "--- Tarihler ---";      whois "$D" | grep -iE 'creation|updated|expir'
  echo "--- NS ---";            dig +short NS "$D"
  echo "--- DS ---";            dig +short DS "$D" @1.1.1.1
} | tee kilit-oncesi.txt

whois çıktısında hangi client* ve server* kodlarının bulunduğu

Adım 2 — client* ile server* ayrımını göster

echo "--- REGISTRAR kilitleri (ücretsiz, hesaptan kaldırılabilir) ---"
whois "$D" | grep -io 'client[A-Za-z]*Prohibited' | sort -u

echo "--- REGISTRY kilitleri (CDP'nin uyguladığı) ---"
whois "$D" | grep -io 'server[A-Za-z]*Prohibited' | sort -u

İlk listenin dolu, ikinci listenin muhtemelen boş olduğu çıktı

Adım 3 — DNSSEC zincirini doğrula

# Üst bölgede DS kaydı var mı — zincir gerçekten kurulmuş mu
dig +short DS "$D" @1.1.1.1

# Doğrulama çalışıyor mu — ad bayrağı bekleniyor
dig +dnssec "$D" A @1.1.1.1 | grep -E '^;; flags:'

# Bölgedeki anahtarlar
dig +short DNSKEY "$D" @1.1.1.1

DS kaydının varlığı ve dig yanıtındaki flags satırında ad bayrağı

Adım 4 — Eksik kilitleri talep et ve tekrar ölç

Kayıt operatöründen clientUpdateProhibited ve clientDeleteProhibited de iste. Uygulandıktan sonra Adım 1’i tekrarla ve diff al.

kilit-oncesi.txt ile kilit-sonrasi.txt arasındaki diff; yeni eklenen kodlar

Adım 5 — ICANN e-posta doğrulamasını kontrol et

Registrar panelinde registrant e-postasının doğrulanmış olduğunu gösteren ekran

“Per ICANN requirements, if the registrant email is not verified within 15 days, a hold is placed on the domain and nameservers are replaced with a parking server until verification is complete.”

Bu, “alan adımızı kaybettik” vakalarının saldırı olmayan en yaygın sebebi ve hiçbir kilit onu engellemiyor. Demoda mutlaka göster.

Bu demoda ölçülenler:

Demo 2: Kendi hesabının ele geçirilme maruziyetini denetlemek

CDP’nin savunduğu asıl zafiyet ele geçirilmiş hesap. Bu demo, o zafiyetin kendi hesabında ne kadar açık olduğunu ölçüyor.

Adım 1 — 2FA durumu

curl -s https://api.cloudflare.com/client/v4/user -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq '{iki_faktor: .result.two_factor_authentication_enabled,
         zorunlu: .result.two_factor_authentication_locked}'

two_factor_authentication_enabled değerinin true veya false döndüğü jq çıktısı

false ise CDP’nin savunduğu senaryo tam olarak sende açık.

Adım 2 — Üyeler ve roller

curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/members?per_page=100" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq -r '.result[] | "\(.user.email)\t\([.roles[].name]|join(","))\t2FA=\(.user.two_factor_authentication_enabled)"' \
  | column -t

Süper yönetici rolündeki üyelerin listesi ve hangilerinde 2FA'nın kapalı olduğu

Adım 3 — Token hijyeni

curl -s https://api.cloudflare.com/client/v4/user/tokens -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq -r '.result[] | "\(.name)\t\(.status)\tbitis=\(.expires_on // "SÜRESİZ")\tson=\(.last_used_on // "-")\tip=\(.condition."request.ip" != null)"' \
  | column -t

Süresiz (expires_on null) ve IP kısıtı olmayan token'ların görüldüğü tablo

Aranacaklar: SÜRESİZ yazan token’lar, IP kısıtı olmayanlar, ve son_kullanim çok eski olanlar — sonuncular kullanılmayan ama canlı kimlik bilgileri.

Adım 4 — Denetim kayıtlarını incele

curl -s "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/logs/audit?limit=100" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq -r '.result[] | "\(.when)\t\(.actor.type)\t\(.actor.email // "-")\t\(.action.type)\t\(.resource.type)"' \
  | column -t

actor.type sütununda api_token, dash ve varsa api_key değerlerinin dağılımı

actor.type şu değerleri alıyor: api_token · api_key · dash · oauth · origin_ca_key. Beklemediğin bir api_key (Global API Key) kullanımı görüyorsan alarm ver.

Adım 5 — Zone hold ve DNSSEC

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/hold" \
  -H "Authorization: Bearer $CF_API_TOKEN" | jq .

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dnssec" \
  -H "Authorization: Bearer $CF_API_TOKEN" | jq '{durum: .result.status, ds: .result.ds}'

hold durumunun ve DNSSEC status alanının jq çıktısı

Zone hold plan tablosu: Free ✘ · Pro ✘ · Business ✘ · Enterprise ✅ — ve “Zone holds are enabled by default for all Enterprise zones.”

Adım 6 — Sertleştir ve tekrar ölç

Super Admin ekranında 2FA Enforcement ayarının açıldığı an

Cloudflare’in kendi önerisi: “enable at least two different 2FA factors, as well as safely store backup codes” ve donanım güvenlik anahtarı için “phishing-resistant multifactor authentication”.

Bu demoda ölçülenler:

Fiyatlandırma

Limitler ve plan kapıları

Durum

GA — ama resmî bir GA tarihi yok. Fiili başlangıç 24 Şubat 2016: Cloudflare o gün ICANN akredite registrar’ını Enterprise müşterilere açtı. “Custom Domain Protection” adı ilk kez 27 Eylül 2018 yazısında geçiyor.

Doküman sayfası 24 Nisan 2026’da güncellenmiş — ama Registrar dokümanlarının geneli de aynı gün güncellenmiş, yani toplu bir güncelleme, ürün değişikliği değil.

Lisanslama ve hukuki çerçeve

Hizmet tescillidir ve Cloudflare Hizmet Şartları’na tabidir. Cloudflare ICANN akredite bir kayıt kuruluşudur; CDP bu akreditasyon altında sunulan özel bir hizmet seviyesidir.

Sorumluluk sınırı. Birebir: “Cloudflare does not guarantee against domain loss in the sense of fully indemnifying you for business losses if you lose your domain.” CDP en yüksek koruma seviyesi ama bir sigorta değil.

İdari kilitler. Alan adı “administratively locked by Cloudflare… for legal reasons such as a UDRP filing or court order” olabiliyor. CDP bunu engellemiyor — hukukî süreçler kilit hiyerarşisinin üstünde.

Registrant değişikliği. Ad, soyad, kurum veya e-posta değişikliği ICANN’e göre bir “Change of Registrant” işlemi. Onaylandığında 60 günlük transfer kilidi uygulanıyor (istenmiyorsa “Do not apply 60 day transfer lock” seçilmeli) ve onay 7 gün içinde gelmezse talep iptal oluyor. CDP’li bir alan adında bu süreç ayrıca kendi bant dışı doğrulamandan da geçiyor.

Sık yapılan hatalar

Registrar lock ile registry lock’u eş saymak. clientTransferProhibited ücretsiz ve hesabına giren kişi tarafından kaldırılabiliyor. server*Prohibited registry ile bant dışı iletişim gerektiriyor. Bunlar aynı şey değil.

CDP’yi DNS kaydı koruması sanmak. Kapsam registrar ve registry katmanı. A kaydını değiştiren saldırgan yine trafiğini yönlendiriyor.

2021’deki “Enterprise’a ücretsiz” vaadini CDP’ye atfetmek. O vaat, bugün hiçbir sayfası olmayan farklı bir ürüne aitti.

Registry lock’un her TLD’de olduğunu varsaymak. “not all registries offer Registry Lock as a service.” Sözleşme öncesi alan adı bazında sor.

.tr için CDP planlamak. Cloudflare Registrar TLD listesinde yok.

Registrant e-posta doğrulamasını atlamak. 15 gün sonra hold ve parking. Hiçbir kilit engellemiyor.

Kontak değişikliğinin transfer kilidi doğurduğunu bilmemek. Change of Registrant → 60 gün transfer kilidi; onay 7 günde gelmezse talep iptal.

Yenilemeden hemen sonra transfer etmek. 45 gün içinde transferde registry ek yıl eklemiyor — aynı yıl için iki kez ödüyorsun.

Süresiz ve IP kısıtsız API token’ları bırakmak. CDP’nin savunduğu “ele geçirilmiş hesap” senaryosunun en ucuz girişi bu.

Global API Key kullanmaya devam etmek. Cloudflare’in kendi önerisi: “When possible, use API tokens instead of Global API keys.”

Kullanımdan kaldırılan Registrar ucuna bağımlı script yazmak. GET /accounts/{account_id}/registrar/domains 27 Eylül 2026’da kapanıyor.

Zone hold’u ücretsiz sanmak. Yalnızca Enterprise.