DNS

DNS nedir?

Resmî tanım:

“Cloudflare DNS is a fast, resilient, and easy-to-manage authoritative DNS service. It delivers excellent performance and reliability to your domain while also protecting your business from DDoS attacks and route leaks and hijacking.”

Tüm planlarda kullanılabilir.

Çözdüğü şey dört başlıkta toplanıyor: anycast ağdan küresel yanıt, DNS katmanının kendisine yönelik DDoS’a dayanıklılık, tamamen API ve Terraform ile yönetilebilirlik, ve — çoğu kaynağın atladığı dördüncüsü — Cloudflare’in ters proxy’sini hostname bazında açıp kapatan kontrol noktası olması. Turuncu bulut buradan çalışır.

Nasıl çalışır?

Dört zone kurulum tipi

Resmî ifade net: “If you are on a Free or Pro plan, primary setup (full) is the only one available.”

Partial (CNAME) kurulum ve üç uyarısı

Üç adım: panelde Convert to CNAME DNS Setup (veya API’de "type": "partial"), gerçek DNS sağlayıcında doğrulama TXT kaydı, ve her proxy’li hostname için {hostname}.cdn.cloudflare.net’e CNAME.

Doğrulama kaydı kalıcıdır: “The verification record must remain in place for as long as your domain is active on a CNAME setup on Cloudflare.”

Proxy durumu — turuncu bulut

“Only records used for IP address resolution — A, AAAA, and CNAME records — can be proxied. Other record types (such as MX or TXT) are always DNS-only.”

Proxy’li kayıt sorgulandığında Cloudflare anycast IP’leri döner. DNS-only kayıt sorgulandığında gerçek origin IP’si döner — ve “This exposes your origin IP address to anyone who queries the record.”

Panelden alan adı eklerken proxy varsayılan olarak açıktır.

Cloudflare bazı kayıtları proxy’lemeyi doğrudan engelliyor — çoğu e-posta doğrulama kaydı:

Diğer proxy kısıtları:

• NTLM ve Kerberos çalışmaz. “Because Microsoft Integrated Windows Authentication, NTLM, and Kerberos violate HTTP/1.1 specifications, they are not compatible with proxied DNS records.”
• Standart dışı port veya TCP/UDP için Spectrum gerekiyor.
• Zone aktifleşene kadar hiçbir şey proxy’lenmiyor — turuncu bulut açık görünse bile.
• Aktivasyon sonrası öneri: “we recommend rolling your origin IP addresses at your hosting provider after your zone has been activated. This action prevents your origin IPs from being leaked during onboarding.”

Proxy’lemenin bedava bir yan faydası var:

“For proxied records, if your domain has HTTP/2 or HTTP/3 enabled and is also using Universal SSL, Cloudflare automatically generates HTTPS Service (HTTPS) records on the fly. These DNS records provide clients with information about how to connect to your server upfront, without the need for an initial plaintext HTTP connection to discover supported protocols.”

TTL davranışı

“By default, all proxied records have a TTL of Auto, which is set to 300 seconds. This value cannot be edited.”

Gerekçesi: Cloudflare kayda atadığı anycast IP’sini değiştirirse, çözümleyiciler eski adresi beş dakikadan uzun tutmasın.

DNS-only kayıtlarda aralık 30 saniye (Enterprise) veya 60 saniye (diğer planlar) ile 1 gün arası. Nameserver TTL’i ayrı bir ayardır ve yalnızca Foundation DNS’te düzenlenebilir (varsayılan 86.400 saniye, aralık 30–86.400).

CNAME flattening

“CNAME flattening speeds up CNAME resolution and allows you to use a CNAME record at your zone apex (example.com).”

Cloudflare CNAME’in işaret ettiği IP’yi bulur ve CNAME yerine nihai IP’yi döndürür. Proxy’li CNAME’ler zaten varsayılan olarak flatten edilir. Cloudflare Pages’te kök alan adı kullanmayı mümkün kılan da budur.

İki tuzak:

• “If a CNAME target is being used to verify a domain for a third-party service, turning on CNAME flattening for all CNAME records may cause the verification to fail since the CNAME record itself will not be returned directly.”
• “If the final CNAME target has no A/AAAA records (a dangling CNAME), CNAME flattening returns an empty response (NODATA)… This can make it appear as if the DNS record is not propagating.”

DNSSEC

Cloudflare zone’u imzalar, açık anahtarları yayımlar ve DS kaydını üretir. Tercih edilen algoritma 13’tür ve registrar’ında bu adla listelenmemişse “it may also be called ECDSA Curve P-256 with SHA-256.”

Cloudflare Registrar kullanıcıları ile .ch ve .cz alan adlarında DS kaydı otomatik ekleniyor. .tr bu otomasyonun dışında — DS kaydını Türk registrar’ında elle eklemen gerekiyor.

Multi-signer DNSSEC (RFC 8901) bu zorunluluğu kaldıran yoldur: “allows you to migrate zones to Cloudflare without having to disable DNSSEC.” İki model destekleniyor — Model 1’de tek KSK zone sahibinde, Model 2’de her sağlayıcı kendi KSK’siyle imzalıyor ve DS her ikisine referans veriyor. Mevcut sağlayıcın dış DNSKEY kaydı kabul ediyorsa sıfır kesintili göç mümkün.

NSEC3 Haziran 2025’ten beri Enterprise’da mevcut, hem live-signed hem pre-signed zone’larda.

Zone transfer ve secondary DNS

“Authoritative zone transfer (AXFR): Copies the entire zone from the primary to the secondary provider, even if only one record changes.”

“Incremental zone transfer (IXFR): Transfers only the changes since the last transfer, rather than the entire zone.”

Cloudflare ikisini de destekliyor. Zone başına en fazla 30 peer, her peer yalnızca bir TSIG ile. Tamamı Enterprise.

Bir tuzak: Cloudflare’i secondary olarak kullanıp Secondary DNS Overrides ile kayıtları proxy’li yapıyorsan, “opting for Pre-signed DNSSEC will cause Cloudflare to treat your records as DNS-only.”

DNS Firewall — yetkili DNS değil

Bu ayrı bir Enterprise eklentisi ve sık karıştırılıyor:

“Cloudflare DNS Firewall proxies all DNS queries to your nameservers through Cloudflare’s global network. This action protects upstream nameservers from DDoS attacks and reduces load by caching DNS responses.”

“DNS Firewall is for customers who need to speed up and protect entire authoritative nameservers. If you need to speed up and protect individual zones, refer to Cloudflare DNS Setups.”

Yani kendi BIND’ini bırakmak istemeyen kurumlar için. İki dikkat çekici davranışı var: cache’te yer varsa TTL dolsa bile kayıt zorla silinmiyor — “This feature allows Cloudflare to serve stale objects from cache if your nameservers are offline.” Ve ECS desteğinin bir bedeli var: “EDNS limits the effectiveness of the DNS cache.”

Veri merkezi seçimi konusunda önemli bir cümle: “Queries go to the Cloudflare data center that is closest to the website visitor. This is determined by the location of the DNS resolver.”

Kayıt tipleri

Proxy’lenebilir: A, AAAA, CNAME. E-posta: MX artı TXT tabanlı DKIM/SPF/DMARC. Özel: TXT, CAA, SRV, SVCB, HTTPS, PTR, SOA, NS, DS, DNSKEY. Daha az yaygın olanlar: URI, NAPTR, SSHFP, TLSA, SMIMEA, CERT.

ANAME desteklenmiyor — dokümantasyon bu soruyu CNAME flattening’e yönlendiriyor.

NS kaydı sınırı: “Cloudflare supports up to 10 NS records per delegation name, but the best practice is to keep the set at seven or fewer.”

Nameserver seçenekleri

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

Kullanılır

• Ücretsiz, ölçümsüz ve hızlı bir yetkili DNS istiyorsan. Self-servis planlarda sorgu başına ücret yok, tavan yok.
• Cloudflare’in proxy’sini kullanacaksan. Zaten mecbursun — turuncu bulut DNS kaydının bir özelliği.
• Altyapıyı kodla yönetiyorsan. API ve Terraform tam kapsamlı; batch endpoint’i tek işlemde yüzlerce kaydı değiştiriyor.
• DNS katmanına gelen saldırıdan korunmak istiyorsan — ama yalnızca full setup’ta.
• Apex’te CNAME gerekiyorsa. CNAME flattening bunun için var.

Kullanılmaz

Bu bölümü uzun tutuyorum çünkü Cloudflare DNS’in eksikleri genellikle yazılmıyor.

DNS’in kendisinde coğrafi, ağırlıklı veya gecikme tabanlı yönlendirme yok. DNS ürününde trafik yönlendiren bir kayıt tipi yok. Cloudflare’in cevabı ayrı ücretli Load Balancing. Route 53 geolocation, geoproximity, latency, weighted, multivalue-answer ve failover’ı DNS servisinin içinde veriyor; NS1 iş modelini Filter Chains üzerine kurmuş. Mimarin “kullanıcıyı beş bölgeden en yakınına yalnızca DNS katmanında yönlendir” ise, rakipler bunu doğal olarak yapıyor, Cloudflare ekstra faturalıyor.

ALIAS/ANAME kaydı yok. CNAME flattening iyi ama aynı primitif değil. dnsimple’ın ALIAS’ı ve Route 53’ün alias-to-AWS-resource semantiği (alias hedefine ücretsiz sorgu, health check entegrasyonu) Cloudflare’de yok.

Secondary DNS yalnızca Enterprise ve teklif bazlı. İki DNS sağlayıcısıyla dayanıklılık isteyen orta ölçekli bir şirket yapısal olarak uyuşmuyor; dnsimple, NS1 ve Route 53 bunu satış görüşmesi olmadan satıyor.

Partial (CNAME) kurulum Business ve üstü. Mevcut yetkili sağlayıcını koruyup subdomain proxy’lemenin giriş fiyatı yıllık ödemede ayda 200 dolar. Fastly ve Akamai bir hostname’i her katmanda NS delegasyonu istemeden öne alıyor.

Nameserver ataması kontrol edilemiyor ve sonradan düzeltilemiyor.

Standart planlarda yalnızca iki nameserver. Foundation DNS’te üç, Route 53’te varsayılan dört.

Enterprise altında DNS katmanında failover yok. DNS Firewall ve secondary DNS — bir şey bozulduğunda çözümlemeyi ayakta tutan iki şey — ikisi de Enterprise.

Ücretsiz plan kayıt tavanı 200. Kiracı başına subdomain üreten veya yoğun ACME DNS-01 otomasyonu olan bir yapı için gerçekten düşük. Route 53 hosted zone başına varsayılan 10.000 veriyor ve yükseltilebiliyor.

DNSSEC anahtar kontrolü sınırlı. Hesaba özgü ZSK/KSK Foundation DNS’te; diğer herkes Cloudflare’in anahtarlarını paylaşıyor.

Enterprise DNS fiyatı sorgu hacmine göre ölçülüyor. Ünlü “ölçümsüz DNS” self-servise ait; ölçekte sorgu başına ödüyorsun, sadece opak biçimde. Route 53 milyon başına $0.40’ı yayımlıyor.

NTLM ve Kerberos proxy’yle uyumsuz — o hostname’ler için DNS-only’ye düşmek ve tüm Cloudflare faydalarından vazgeçmek zorundasın.

Somut örnekler

Apex’i yalnızca hostname veren bir PaaS’a yöneltmek

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"type":"CNAME","name":"@","content":"cname.vercel-dns.com","proxied":true,"ttl":1}'

ttl: 1 Auto demektir. CNAME flattening RFC’ye aykırı olan apex CNAME’i mümkün kılıyor. Doğrulama: dig +short ornek.com.tr A CNAME değil, Cloudflare anycast IP’leri döndürmeli.

Wildcard sertifika için ACME DNS-01

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"type":"TXT","name":"_acme-challenge","content":"\"<TOKEN>\"","ttl":60}'

TTL 60, Enterprise dışı planlarda DNS-only kayıtlar için taban değerdir.

Asla proxy’lenmemesi gereken e-posta kayıtları

MX ve TXT zaten hep DNS-only’dir; kritik olan MX’in işaret ettiği A kaydının da DNS-only olmasıdır.

500 kaydı tek işlemde taşımak

Tek tek POST atarsan 5 dakikada 1.200 istek sınırına çarparsın. Doğru yol batch endpoint’i: /zones/{zone_id}/dns_records/batch — tek çağrıda silme, güncelleme ve ekleme birlikte.

Tüm hesabı DNS-only’ye zorlamak

curl --request PATCH \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/dns_settings" \
  --header "Content-Type: application/json" \
  --data '{"zone_defaults":{"zone_mode":"dns_only"}}'

Nisan 2026’da gelen bu ayar, kademeli geçiş veya uyumluluk gereği için işe yarıyor. Kapsam dışında kalanlar: Spectrum uygulamaları, Tunnel CNAME’leri, R2 custom domain’leri, Web3 gateway’leri ve Workers custom domain’leri normal çalışmaya devam ediyor.

Demo 1: Bir zone’u uçtan uca taşımak ve her adımı dig ile doğrulamak

Bu demonun amacı taşımayı yapmak değil — her adımda tam olarak neyin değiştiğini kanıtlamak. Panele yalnızca iki tık için gireceğiz.

Adım 1 — Hiçbir şeye dokunmadan başlangıç durumunu kaydet

export DOM=ornek.com.tr

# Şu anda kim yetkili? TLD sunucularından sor, kendi cache'ini atla
dig +norecurse @$(dig +short tr. NS | head -1) $DOM NS +short

# Mevcut sağlayıcı ne sunuyor?
OLDNS=$(dig +short $DOM NS | head -1)
dig @$OLDNS $DOM SOA +noall +answer
dig @$OLDNS $DOM A   +noall +answer
dig @$OLDNS www.$DOM +noall +answer
dig @$OLDNS $DOM MX  +noall +answer
dig @$OLDNS $DOM TXT +noall +answer

# KRİTİK: ebeveynde DNSSEC canlı mı?
dig $DOM DS +noall +answer

dig komutlarının çıktıları; mevcut NS seti, SOA serial, A/MX/TXT kayıtları ve DS kaydı sorgusunun sonucu

Bir de gecikme referansı al:

for i in $(seq 1 20); do dig @$OLDNS $DOM A | awk '/Query time/{print $4}'; done \
  | sort -n | awk '{a[NR]=$1} END{print "min",a[1],"medyan",a[int(NR/2)],"maks",a[NR]}'

Adım 2 — Zone’u oluştur ve kayıtları içe aktar

ZONE_ID=$(curl -s "https://api.cloudflare.com/client/v4/zones" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json "{\"name\":\"$DOM\",\"account\":{\"id\":\"$ACCOUNT_ID\"}}" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["id"])')

# Cloudflare'in tarayıcısı kayıtları bulmaya çalışsın
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/scan" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN"

# Bulduklarını oku ve adım 1'deki dökümle KARŞILAŞTIR
curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?per_page=500" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  | python3 -c 'import sys,json;[print(r["type"],r["name"],r["content"],r["proxied"]) for r in json.load(sys.stdin)["result"]]' \
  | sort

Cloudflare'in bulduğu kayıt listesi ve adım 1'deki dig çıktılarıyla yapılan karşılaştırma; eksik kayıtlar işaretlenmiş

Bu, herkesin atladığı adım. Cloudflare’in kendi uyarısı: “the quick scan is not guaranteed to find all existing DNS records” ve “If you activate your domain on Cloudflare without setting up the correct DNS records for your domain, your visitors may experience DNS_PROBE_FINISHED_NXDOMAIN errors.” Satır satır karşılaştır, eksikleri devam etmeden önce ekle.

Adım 3 — Atanan nameserver’ları al ve delegasyondan ÖNCE prova yap

CFNS=$(curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID" \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["name_servers"][0])')

# Zone daha delege EDİLMEDEN Cloudflare'e doğrudan sor
dig @$CFNS $DOM A   +noall +answer
dig @$CFNS www.$DOM +noall +answer
dig @$CFNS $DOM MX  +noall +answer

Cloudflare nameserver'ına doğrudan yapılan dig sorgularının doğru kayıtları döndürdüğü çıktı

Bu sıfır riskli provadır. Cloudflare henüz kendisine delege edilmemiş bir zone için cevap veriyor (dokümantasyon bunu doğruluyor). Burada bir şey yanlışsa taşıma bozulacaktı — şimdi hiçbir maliyet ödemeden düzeltiyorsun.

Adım 4 — Registrar’da NS’leri değiştir ve delegasyonun döndüğünü izle

while true; do
  date -u +%H:%M:%S
  dig +norecurse @$(dig +short tr. NS | head -1) $DOM NS +short
  sleep 60
done

Döngünün çıktısı; TLD cevabının eski NS setinden *.ns.cloudflare.com'a döndüğü an

Taşımanın yetkili anı budur — laptop’unun çözümleyicisinin ne dediği değil.

Zone durumu ayrı ilerliyor:

API'den veya panelden zone durumu; pending → active geçişi ve Overview sayfasındaki banner değişimi

Adım 5 — Turuncu bulutu üç ayrı kanıtla göster

İki test kaydı oluştur, biri proxy’li biri değil, ve farkı gör:

dig +noall +answer proxy-test.$DOM A
dig +noall +answer dnsonly-test.$DOM A

Beklenen — turuncu bulutun tamamı üç satırda:

proxy-test.ornek.com.tr.    300  IN  A  104.21.x.x     <- Cloudflare anycast, TTL 300'e sabitlenmiş
proxy-test.ornek.com.tr.    300  IN  A  172.67.x.x     <- ikinci anycast IP
dnsonly-test.ornek.com.tr.  300  IN  A  192.0.2.10     <- gerçek origin IP'n, AÇIKTA

İki dig komutunun çıktısı yan yana; proxy'lide Cloudflare IP'leri, DNS-only'de gerçek origin IP'si

İkinci kanıt — TTL artık senin değil. Proxy’li kaydın TTL’ini 3600 yapmayı dene:

PATCH isteğinin reddedildiği veya TTL'in sessizce 300'de kaldığı API yanıtı

Üçüncü kanıt — HTTP başlıkları yalnızca proxy’liyken var:

curl -sSI https://www.$DOM | grep -iE 'server|cf-ray|cf-cache-status'

curl -I çıktısı; server: cloudflare, cf-ray ve cf-cache-status başlıkları. cf-ray'in son üç karakteri veri merkezi kodu

cf-ray başlığının son üç karakteri IATA kodudur. Türkiye’den bakıyorsan -IST veya -ADB görmen beklenir.

Adım 6 — Cloudflare’in kendi debug uçlarıyla nerede olduğunu öğren

dig @$CFNS chaos txt id.server +short        # DNS'ine bakan veri merkezi
dig @$CFNS chaos txt version.bind +short     # yetkili DNS yazılım sürümü
dig @$CFNS txt whoami.cloudflare.net +short  # IP'n, ASN'in, ülke kodun

Üç dig komutunun çıktısı; id.server'da veri merkezi kodu, whoami'de Türk ASN'i ve TR ülke kodu

Adım 7 — Gecikme farkını ölç ve panelde analitiği gör

for i in $(seq 1 20); do dig @$CFNS $DOM A | awk '/Query time/{print $4}'; done \
  | sort -n | awk '{a[NR]=$1} END{print "min",a[1],"medyan",a[int(NR/2)],"maks",a[NR]}'

Adım 1 ve adım 7'deki iki ölçümün yan yana karşılaştırması

DNS → Analytics ekranı; toplam sorgu, saniyede ortalama sorgu, veri merkezine göre sorgu haritası

Bu demoda ölçülenler: TLD’deki delegasyonun döndüğü an · zone durumunun active’e geçiş süresi · proxy’li ve DNS-only kayıtların dig farkı · TTL’in 300’de kilitli olduğu · cf-ray veri merkezi kodu · taşıma öncesi ve sonrası sorgu gecikmesi.

Demo 2: DNSSEC’i açmak, doğrulamak ve güvenle geri alabilmek

Ön koşul: zone Cloudflare’de active durumda.

Adım 1 — Şu anda kapalı olduğunu kanıtla

dig $DOM DS +short                 # boş dönmeli
dig @$CFNS $DOM DNSKEY +short      # boş dönmeli
delv $DOM A                        # "; unsigned answer" demeli
dig $DOM A +dnssec | grep -c RRSIG # 0 dönmeli

Dört komutun çıktısı; DS ve DNSKEY boş, delv unsigned answer diyor, RRSIG sayısı sıfır

Adım 2 — İmzalamayı aç

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dnssec" --request PATCH \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"status":"active"}' | python3 -m json.tool

API yanıtı; algorithm 13, digest, digest_type 2, ds dizesi, key_tag, flags 257 ve status pending-ds

Yanıttaki her alan registrar’a gireceğin bilgidir. Panelden de aynı bilgiye DNS → Settings → DNSSEC altından ulaşabilirsin.

Adım 3 — Registrar’a dokunmadan Cloudflare’in imzaladığını doğrula

dig @$CFNS $DOM DNSKEY +noall +answer     # 256 ve 257 flag'li anahtarlar
dig @$CFNS $DOM A +dnssec +noall +answer  # artık RRSIG içeriyor

DNSKEY sorgusunda iki anahtar, A sorgusunda RRSIG kaydı; ama dig $DOM DS hâlâ boş

Burası güvenli penceredir. RRSIG’ler var ama ebeveynde DS yok, yani güven zinciri henüz kapanmadı ve kullanıcılar için hiçbir şey bozulmadı.

Adım 4 — Registrar’da DS kaydını yayımla

Algoritma 13, Digest Type 2 (SHA-256), adım 2’deki key tag ve digest.

Registrar arayüzünde DNSSEC/DS kaydı ekleme ekranı; algoritma, digest type, key tag ve digest alanları doldurulmuş

Adım 5 — Güven zincirinin kapandığını izle

while true; do
  date -u +%H:%M:%S
  echo -n "Ebeveynde DS: "; dig $DOM DS +short | tr '\n' ' '; echo
  echo -n "Cloudflare durumu: "; curl -s ".../zones/$ZONE_ID/dnssec" \
    --header "Authorization: Bearer $CF_API_TOKEN" \
    | python3 -c 'import sys,json;print(json.load(sys.stdin)["result"]["status"])'
  sleep 120
done

Döngü çıktısı; DS kaydının ebeveynde görünmeye başladığı ve API durumunun pending-ds'ten active'e döndüğü an

Adım 6 — Doğrulamanın gerçekten çalıştığını kanıtla

delv $DOM A
# Başarı şöyle görünür:
#   ; fully validated
#   ornek.com.tr.  300  IN  A  104.21.x.x
#   ornek.com.tr.  300  IN  RRSIG A 13 3 300 ...

dig @1.1.1.1 $DOM A +dnssec | grep -E 'flags:|RRSIG'
# flags satırındaki 'ad' = Authenticated Data = çözümleyici doğruladı

delv çıktısında 'fully validated' satırı ve dig çıktısındaki flags satırında ad bayrağı

Negatif kanıt da al — doğrulayan bir çözümleyici bilerek bozulmuş bir zone’u reddetmeli:

dig @1.1.1.1 dnssec-failed.org A     # SERVFAIL bekleniyor
dig @1.1.1.1 +cd dnssec-failed.org A # +cd kontrolü kapatır, şimdi cevap gelir

dnssec-failed.org sorgusunun SERVFAIL döndüğü ve +cd ile cevap verdiği iki çıktı

Adım 7 — Geri alma provası

dig çıktısında DS kaydının TTL sütunu; geri alma senaryosunda beklenecek süre

Bu demoda ölçülenler: imzalama açılmadan önceki ve sonraki RRSIG sayısı · pending-ds’ten active’e geçiş süresi · DS kaydının ebeveynde görünme süresi · delv’in doğrulama sonucu · ad bayrağının varlığı · DS TTL’i (geri alma penceresi).

Fiyatlandırma

Yetkili DNS ücretsizdir

“Cloudflare never limits or caps DNS queries, but the pricing depends on your plan level. For customers on Free, Pro, or Business plans, Cloudflare does not charge for DNS queries. For customers on Enterprise plans, Cloudflare uses the number of monthly DNS queries as a pricing input to generate a custom quote.”

Kayıt kotası

“Cloudflare limits the number of DNS records you can create. Depending on your plan, this limit is enforced either per zone or per account — not both.”

Dikkat: “DNS records that other Cloudflare services create on your behalf — for example, the TXT and MX records added by Email Routing — also count toward your quota.”

Diğer limitler

API rate limitleri

“If you exceed this limit, all API calls for the next five minutes will be blocked, receiving a HTTP 429 - Too Many Requests response.”

Bu sınır, yüzlerce kaydı tek tek POST ederek taşımaya çalışanların çarptığı duvardır — batch endpoint’i tam olarak bunun için var.

DNS Analytics saklama

Özellik kapıları

Lisanslama ve hukuki çerçeve

Hizmet tescillidir ve Cloudflare Hizmet Şartları’na tabidir.

.tr alan adları için pratik tablo şudur: alan adın nic.tr/TRABIS akredite bir kayıt operatöründe kalır, Cloudflare yalnızca yetkili DNS olarak devreye girer. Bunun üç sonucu var. Birincisi, Cloudflare Registrar’ın “maliyetine, marjsız” fiyatlandırması .tr için geçerli değil. İkincisi, DS kaydı otomasyonu yalnızca Cloudflare Registrar ile .ch/.cz için çalıştığından DNSSEC’i elle kurman gerekiyor. Üçüncüsü — bu iyi haber — “Partial setups are not supported on Cloudflare Registrar domains” kısıtı seni etkilemiyor; Business veya Enterprise’daysan .com.tr alan adında partial (CNAME) kurulum kullanabilirsin.

Veri yerelliği açısından DNS ilginç bir konumda. Sorgular anycast ile en yakın veri merkezinde cevaplanıyor ama bu merkez çözümleyicinin konumuna göre seçiliyor, kullanıcının değil. Türkiye Data Localization Suite’te Regional Services bölgesi olarak destekleniyor — yani HTTPS trafiğinin Türkiye’deki veri merkezlerinde çözülmesini zorlayabiliyorsun — ama Customer Metadata Boundary Türkiye’yi desteklemiyor, dolayısıyla DNS analitiğin ve logların Türkiye’de saklanamıyor. Ayrıntı için Analytics.

KVKK açısından DNS sorgu logları kaynak IP içerir ve bu kişisel veri sayılabilir. DNS Analytics boyutları arasında Source IP ve Destination IP var. Bu veriye kimlerin eriştiğini ve ne kadar saklandığını (plan tablosuna bakınız) aydınlatma metninde değerlendirmen gerekir.

Türkçe arayüz ve TRY faturalama. cloudflare.com’un dil değiştiricisinde Türkçe bulunmamaktadır. Panelde Türkçe olup olmadığı resmî kaynaklarda belgelenmemiştir. Tüm yayımlanan fiyatlar USD’dir; TRY ile faturalama konusunda resmî bir kaynak bulunamamıştır.

Sık yapılan hatalar

Taşıma sırasında registrar’da DNSSEC’i açık bırakmak. Tamamen ölü alan adının bir numaralı sebebi. Önce DS’i kaldır, TTL’ini bekle.

DKIM veya doğrulama CNAME’ini proxy’lemek. Cloudflare bilinen bir listeyi engelliyor ama her sağlayıcıyı değil. Alan adı sahipliğini kanıtlayan kayıtlar proxy’lenmemeli.

“Tüm CNAME’leri flatten et” seçeneğini açıp üçüncü taraf doğrulamasını kırmak.

Otomatik taramaya güvenmek. “the quick scan is not guaranteed to find all existing DNS records.”

Eski origin IP’lerini keşfedilebilir bırakmak. Cloudflare aktivasyondan sonra IP’leri değiştirmeyi öneriyor.

Partial kurulumun doğrulama TXT kaydını silmek. Kurulum aktif olduğu sürece kalmalı.

Farklı bir Cloudflare hesabındaki hostname’e CNAME vermek. Error 1014.

Pending durumdaki zone’u üretim trafiğine açmak. “make sure not to use pending zones for production traffic.”

“Moved” bildirimini görmezden gelmek. Yeterince uzun süre Moved durumunda kalan alan adı siliniyor ve “Cloudflare support is unable to restore DNS or settings for deleted domains.”

Bir delegasyon için 10’dan fazla NS kaydı oluşturmak. Reddediliyor veya doğrulamada kalıyor.

NTLM veya Kerberos kullanan bir hostname’i proxy’lemek. Tekrarlayan kimlik doğrulama istemleri veya döngü.

Planlı değişiklikten önce TTL’i düşürmemek. Cloudflare tarafı beş dakikada yayılıyor ama dünyadaki çözümleyiciler eski TTL dolana kadar eski cevabı tutuyor.