Alan Adı & DNS

    Cloudflare'de Alan Adı Aktif Olmuyor: Pending Nameserver Update Çözümü

    Cloudflare'de aktifleşmeyen alan adının üç klasik sebebini dig ve WHOIS çıktılarıyla eleyerek çözen pratik teşhis rehberi.

    13 dk okuma Güncellendi: 18 Ağustos 2026

    Cloudflare panelinde alan adınızın yanında turuncu bir bant duruyor: Pending Nameserver Update. Kayıt firmanızın panelinden nameserver'ları üç gün önce değiştirdiniz, "Check nameservers now" düğmesine yirmi kez bastınız, hatta Cloudflare'den "nameserver'larınızı hâlâ güncellemediniz" hatırlatma e-postası bile geldi. Ama zone bir türlü Active olmuyor.

    En sinir bozucu tarafı, görünürde hiçbir şeyin bozuk olmamasıdır. Site açılıyor, DNS kayıtları panelde duruyor, hatta dig çıktısı Cloudflare nameserver'larını gösteriyor olabilir. Buna rağmen turuncu bulut hiçbir işe yaramıyor, Universal SSL sertifikası çıkmıyor, WAF kuralları ve Page Rules uygulanmıyor. Bunun sebebi şu: Cloudflare pending durumdaki bir zone için DNS sorgularına cevap verse bile, o alan adını "trafiğini yöneteceğim alan adı" olarak henüz kabul etmiş değildir. Doğrulama tamamlanmadan proxy katmanı devreye girmez.

    Bu ekranda takılı kalmanın pratikte üç sebebi vardır: kayıt firmasında eski nameserver kayıtlarının tam olarak temizlenmemiş olması, önceki DNS sağlayıcınızdan kalan ve güven zincirini kıran DNSSEC DS kaydı, ve alan adının başka bir Cloudflare hesabında ekli olması yüzünden size verilen NS çiftinin gerçekte delege ettiğiniz çiftle uyuşmaması. Aşağıda bu üçünü sırayla eliyoruz. Her adımda panelin söylediğine değil, dig ve whois çıktısına bakacağız — çünkü kayıt firması panelleri sık sık kaydettiğiniz değeri gösterir, kök sunucuların gerçekten ne bildiğini değil.

    "Pending Nameserver Update" Tam Olarak Ne Demek?#

    Cloudflare her zone'a bir durum (status) atar ve panelde gördüğünüz bant bu durumun karşılığıdır. Anlamlarını karıştırmak yanlış yerde saatler harcamanıza yol açar:

    DurumPanelde görünenAnlamı
    initializingKurulum sürüyorZone yeni eklendi, kayıtlar taranıyor
    pendingPending Nameserver UpdateDelegasyon Cloudflare'e geçmemiş ya da doğrulanamıyor
    activeActiveDelegasyon doğrulandı, proxy ve SSL çalışıyor
    movedMovedZone daha önce aktifti, delegasyon Cloudflare'den çıkarıldı
    deactivatedDeactivatedHesap veya politika kaynaklı olarak devre dışı

    Buradaki kritik ayrım şudur: pending bir zone da DNS cevabı üretir. Cloudflare, size atadığı nameserver'lara gelen sorguları yanıtlar; A, MX ve TXT kayıtlarınız çözümlenir. Bu yüzden "site açılıyor, demek ki geçiş tamam" varsayımı yanıltıcıdır. Aktif olmayan bir zone'da çalışmayan şeyler şunlardır:

    • Turuncu bulutlu (proxied) kayıtlar gerçekte proxy'lenmez, trafik doğrudan origin'e gider
    • Universal SSL sertifikası düzenlenmez, Error 526 veya sertifika uyuşmazlığı görürsünüz
    • WAF, Rate Limiting, Bot Fight Mode, Page Rules ve Transform Rules çalışmaz
    • Analytics ekranı boş kalır
    • Cloudflare tarafında DNSSEC açamazsınız

    Yani pending bir zone, üzerine para ödediğiniz ya da güvendiğiniz her özelliğin kapalı olduğu bir DNS barındırma hizmetinden ibarettir. Bu yüzden "nasılsa çalışıyor" deyip bırakmak, özellikle güvenlik tarafında yanlış bir güven duygusu yaratır.

    Teşhise Nereden Başlanır: Üç Komutluk Ön Kontrol#

    Panele bakarak teşhis koymayın. Aşağıdaki üç komut, üç sebepten hangisinde olduğunuzu neredeyse her zaman ilk denemede söyler. dig komutunun ayrıntıları için dig ve nslookup ile DNS sorgulama yazısına bakabilirsiniz.

    # 1) Üst seviye (TLD) sunucusu delegasyonda neyi görüyor?
    dig ornek.com NS +trace
    
    # 2) Kayıt firmasının kaydettiği nameserver'lar (registry'nin bildiği)
    whois ornek.com | grep -i "name server"
    
    # 3) Delegasyonda DNSSEC imzası (DS kaydı) var mı?
    dig ornek.com DS +short
    

    Çıktıları şöyle okuyun:

    • +trace sonunda hâlâ eski sağlayıcının NS'leri görünüyorsa → Sebep 1'desiniz, delegasyon değişmemiş.
    • DS sorgusu boş değilse ve DNS geçmişinizde başka bir sağlayıcı varsa → Sebep 2'desiniz, DNSSEC bloke ediyor.
    • NS'ler Cloudflare'e ait ama panelde yazan çiftle harf harf aynı değilse → Sebep 3'tesiniz, yanlış NS çifti.

    Bu üç kontrolden hiçbiri sorun göstermiyorsa yazının sonundaki "her şey doğru görünüyor" bölümüne geçin; orada bekleme süresi ve önbellek konusunu ele alıyoruz.

    Sebep 1: Kayıt Firmasında Eski Nameserver'lar Tam Değişmemiş#

    Bu, uzak ara en yaygın sebeptir ve genellikle "değiştirdim ama iki tanesini" hâlinde ortaya çıkar. Cloudflare size tam olarak iki nameserver verir (örneğin dana.ns.cloudflare.com ve rob.ns.cloudflare.com). Kayıt firmalarının çoğu ise dört satırlık bir form gösterir. İlk iki satırı Cloudflare değerleriyle doldurup alttaki iki satırı eski hosting firmanızın ns1.eskihosting.com / ns2.eskihosting.com değerleriyle bırakırsanız, delegasyonda dört nameserver kalır.

    Bu durumda çözümleyiciler zaman zaman eski sunuculara sorar, zaman zaman Cloudflare'e. Site çalışmaya devam ettiği için hiçbir şey fark etmezsiniz, ama Cloudflare doğrulaması "delegasyon bana ait değil" sonucunu verir ve zone pending kalır.

    Delegasyonu Nasıl Doğrularsınız?#

    Kayıt firmasının panelindeki ekran görüntüsü kanıt değildir. Kanıt, üst seviye sunucunun verdiği cevaptır:

    # .com için doğrudan bir TLD sunucusuna sorun (önbelleği atlar)
    dig @a.gtld-servers.net ornek.com NS
    
    # Cevabın AUTHORITY bölümünde yalnızca Cloudflare NS'leri olmalı:
    # ornek.com. 172800 IN NS dana.ns.cloudflare.com.
    # ornek.com. 172800 IN NS rob.ns.cloudflare.com.
    

    Sorunlu bir çıktı şuna benzer — dikkat edin, dört kayıt var ve ikisi eski sağlayıcıya ait:

    ;; AUTHORITY SECTION:
    ornek.com.  172800  IN  NS  dana.ns.cloudflare.com.
    ornek.com.  172800  IN  NS  rob.ns.cloudflare.com.
    ornek.com.  172800  IN  NS  ns1.eskihosting.com.
    ornek.com.  172800  IN  NS  ns2.eskihosting.com.
    

    Yapılacaklar#

    1. Kayıt firmanızın paneline girin, alan adının nameserver / DNS sunucuları bölümünü açın.
    2. Formdaki tüm satırları temizleyin. Bazı paneller boş satır kabul etmez; o zaman üçüncü ve dördüncü alanı silmek için ayrı bir "kaldır" düğmesi ararsınız.
    3. Yalnızca Cloudflare'in verdiği iki değeri, sonunda nokta olmadan ve tamamen küçük harfle yazın.
    4. Kaydedin ve 15 dakika sonra yukarıdaki dig @a.gtld-servers.net komutunu tekrarlayın.

    Bazı özel durumlar:

    • .tr uzantıları: Değişiklik TRABIS üzerinden ilerler ve kayıt firmasının paneline yansıması ile registry'ye işlenmesi arasında birkaç saat fark olabilir. whois ornek.com.tr çıktısı kaynak olarak paneli değil registry'yi gösterdiği için asıl bakılacak yer orasıdır.
    • Kayıt firmasının kendi DNS servisi: Bazı firmalarda "DNS yönetimi bende kalsın" gibi bir anahtar vardır ve açıkken girdiğiniz özel nameserver'lar sessizce yok sayılır. Bu anahtarı kapatmadan yaptığınız değişiklik hiçbir zaman registry'ye gitmez.
    • Child nameserver (glue) kalıntısı: Daha önce ns1.ornek.com gibi kendi alan adınız üzerinden özel nameserver tanımladıysanız, bu glue kayıtları registry'de asılı kalabilir ve bazı registry'ler bunlar silinmeden delegasyon değişikliğini reddeder. Panelde "child nameserver / kişisel nameserver" bölümünü kontrol edip kalanları silin.

    Nameserver değişikliğinin genel akışı ve site kesintisi konusunda nameserver değiştirme yazısında ayrıntı bulabilirsiniz.

    Sebep 2: DNSSEC Açık Kaldı ve Geçişi Blokluyor#

    Bu, "her şeyi doğru yaptım ama olmuyor" vakalarının neredeyse tamamının cevabıdır ve sinsi olmasının sebebi şudur: DNSSEC ayarı Cloudflare'de değil, kayıt firmanızdadır.

    Kısaca hatırlatalım: DNSSEC, DNS cevaplarını kriptografik olarak imzalar. Üst seviyede (registry'de) duran DS kaydı, "bu alan adının imzası şu anahtara ait" diyen parmak izidir. Konunun tamamı için DNSSEC nedir yazısına bakabilirsiniz.

    Eski sağlayıcınızda DNSSEC açıksa, registry'de o sağlayıcının anahtarına işaret eden bir DS kaydı vardır. Nameserver'ları Cloudflare'e çevirdiğinizde şu tablo oluşur:

    • Registry hâlâ "bu bölge şu anahtarla imzalı" diyor
    • Cevapları artık Cloudflare veriyor ve o anahtara sahip değil
    • Doğrulama yapan her çözümleyici zinciri kırık bulup cevabı reddediyor ve SERVFAIL dönüyor

    Sonuç, Cloudflare'in doğrulama isteğinin de aynı duvara toslamasıdır. Zone pending kalır. Daha kötüsü, doğrulayan çözümleyici kullanan ziyaretçiler (Google 8.8.8.8, Cloudflare 1.1.1.1, birçok kurumsal ağ ve mobil operatör) siteyi hiç açamaz — ama doğrulama yapmayan bir çözümleyici kullanan sizde site gayet normal görünür. "Bende çalışıyor ama müşteride açılmıyor" şikâyetinin klasik kaynağıdır.

    DS Kaydı Var mı, Nasıl Bakılır?#

    # Delegasyonda DS kaydı var mı?
    dig ornek.com DS +short
    # Örnek çıktı: 2371 13 2 A1B2C3...  -> DS VAR
    
    # Zinciri gerçekten doğrulayabiliyor mu? (bind-dnsutils içinde gelir)
    delv @1.1.1.1 ornek.com A
    
    # Kırık zincirde tipik sonuç:
    #   ;; resolution failed: SERVFAIL
    

    Ek bir kontrol olarak, doğrulamayı kapatan bir sorgu ile normal sorguyu karşılaştırın. +cd (checking disabled) bayrağı doğrulamayı atlar:

    dig @1.1.1.1 ornek.com A +short        # boş dönerse doğrulama başarısız
    dig @1.1.1.1 ornek.com A +short +cd    # burada cevap geliyorsa sebep DNSSEC
    

    İkinci komut cevap verip birincisi vermiyorsa teşhis kesindir: DNSSEC zinciri kırık.

    DS Kaydını Nasıl Kaldırırsınız?#

    DS kaydı Cloudflare panelinden silinmez; kayıt firmanızın panelinden silinir. Menü adı firmadan firmaya değişir:

    Kayıt firması tipiMenünün bulunduğu yer
    Genel amaçlı panellerAlan Adı Detayı → Gelişmiş DNS / Advanced DNS → DNSSEC
    WHMCS tabanlı bayilerAlan Adım → Yönetim → DNSSEC Yönetimi
    Kurumsal registrar arayüzleriSecurity → DNSSEC → DS Records
    .tr alan adlarıKayıt firmasının TRABIS işlem ekranı → DNSSEC

    Adımlar:

    1. DNSSEC bölümündeki tüm DS kayıtlarını silin. Bir tanesini bırakmak yetmez; zincir tek kırık halkada kopar.
    2. Panelde "DNSSEC'i devre dışı bırak" gibi tek anahtarlık bir seçenek varsa onu kullanın.
    3. Silme işleminin registry'ye işlenmesi ve önbelleklerden düşmesi için bekleyin. DS kayıtlarının TTL'i uzundur; pratikte birkaç saat, en kötü ihtimalle 24 saat sürer. DNS propagasyon süresi yazısında bu bekleme mantığını ayrıntılı anlattık.
    4. dig ornek.com DS +short boş dönmeye başladığında Cloudflare doğrulaması kendiliğinden geçer.

    Zone aktif olduktan sonra DNSSEC'i Cloudflare tarafında yeniden açabilirsiniz: Cloudflare size yeni bir DS kaydı üretir, siz de onu kayıt firmasına girersiniz. Sıralamayı tersine çevirmeyin — önce eskiyi silin, aktifleşmeyi bekleyin, sonra yenisini ekleyin.

    Sebep 3: Alan Adı Başka Bir Cloudflare Hesabında Ekli#

    Bu sebebe genellikle en son bakılır, çünkü akla gelmez. Belirtisi çok belirgindir: NS'ler Cloudflare'e ait görünür ama zone yine de aktif olmaz.

    Cloudflare'in çalışma mantığı şudur: bir alan adı eklediğinizde size sabit bir NS çifti atanır ve doğrulama yalnızca o çift delegasyonda göründüğünde geçer. Başka bir Cloudflare hesabına eklenmiş aynı alan adı için farklı bir çift atanmıştır. Delegasyonda alice.ns.cloudflare.com yazarken sizin panelinizde dana.ns.cloudflare.com yazıyorsa, ikisi de Cloudflare olsa bile doğrulama asla geçmez.

    Bu duruma en sık şu senaryolarla düşülür:

    • Alan adını yıllar önce bir ajans, eski geliştirici ya da kendi ikinci hesabınıza eklemişsiniz ve zone hâlâ orada duruyor
    • Aynı alan adını iki farklı şirket e-postasıyla açılmış iki hesaba eklemişsiniz
    • Zone'u sildiniz, hemen yeniden eklediniz ve yeni bir çift atandı ama kayıt firmasında eski çift duruyor

    Son maddedeki davranışın arkasında bir güvenlik kararı vardır: Cloudflare, alan adı ele geçirme girişimlerini engellemek için, zone oluşturulmadan önce kayıt firmasına Cloudflare nameserver'ları girilmiş alan adlarına farklı bir NS çifti atar. Yani "nasılsa Cloudflare'e geçeceğim, NS'leri baştan yazayım" yaklaşımı doğrudan bu tuzağa götürür. Doğru sıra her zaman şudur: önce zone'u oluştur, sonra sana verilen çifti kayıt firmasına yaz.

    Uyuşmazlığı Nasıl Tespit Edersiniz?#

    Panelde yazan çift ile delegasyondaki çifti yan yana koyun. Göz kararı karşılaştırmayın; isimler birbirine çok benzer:

    # Delegasyondaki gerçek çift
    dig ornek.com NS +short | sort
    
    # Örnek çıktı:
    # alice.ns.cloudflare.com.
    # tim.ns.cloudflare.com.
    

    Cloudflare panelinde Overview sekmesinin altında yazan iki isim ile bu çıktı harf harf aynı değilse sebebi buldunuz demektir.

    Yapılacaklar#

    1. Şirketinizde kullanılmış olabilecek diğer Cloudflare hesaplarına giriş yapıp alan adını arayın. Eski ajans hesabı da buna dahildir.
    2. Bulduğunuz hesapta zone'u Remove Site ile silin. Silmeden önce mevcut DNS kayıtlarının ekran görüntüsünü veya export'unu alın.
    3. Kendi hesabınızda zone'u silip yeniden ekleyin; size güncel bir çift atanacaktır.
    4. Kayıt firmasında NS'leri bu yeni çiftle güncelleyin.
    5. Hiçbir hesaba erişemiyorsanız (ajans kapanmış, eski çalışan gitmiş) Cloudflare destek talebi açın. Alan adı sahipliğini WHOIS üzerinden kanıtlamanız istenir — bu yüzden WHOIS kayıtlarınızın güncel olması işinizi kolaylaştırır. WHOIS nedir yazısında sorgunun nasıl okunacağını anlattık.

    Her Şey Doğru Görünüyor Ama Hâlâ Pending#

    Üç sebebi de elediyseniz geriye iki ihtimal kalır: henüz beklemediniz ya da bir önbellek katmanı eski cevabı tutuyor.

    Cloudflare delegasyonu periyodik olarak kontrol eder; ilk saatlerde sık, sonra seyrekleşen aralıklarla. Paneldeki Check nameservers now düğmesi bu kontrolü elle tetikler ama sınırsız değildir; arka arkaya bastığınızda bir süre pasif hâle gelir. Bekleme mantığı şöyle işler:

    AşamaTipik süreNeyi bekliyorsunuz
    Kayıt firması → registry15 dk – 2 saatDeğişikliğin registry'ye işlenmesi
    Üst seviye NS TTL'i24 – 48 saatEski delegasyonun önbelleklerden düşmesi
    DS kaydı silme4 – 24 saatİmzanın çözümleyicilerden düşmesi
    Cloudflare doğrulamasıKontrolden sonra dakikalarZone'un active olması

    Pratik bir kural: dig @a.gtld-servers.net ornek.com NS çıktısı doğruysa ve dig ornek.com DS +short boşsa, Cloudflare'in aktifleştirmemesi için teknik bir sebep kalmamıştır. Bu durumda 24 saat bekleyin, sonra destek talebi açın.

    Bu arada kendi bilgisayarınızdaki ve ağınızdaki önbelleği temizlemek, gördüğünüz tabloyu netleştirir; adımlar için DNS önbellek temizleme yazısına bakabilirsiniz. Bunun Cloudflare'in kararını değiştirmediğini unutmayın — sadece sizin gördüğünüz cevabı tazeler.

    Hızlı Teşhis Tablosu#

    Elinizin altında dursun diye belirti–sebep–çözüm eşlemesini tek tabloda topladık:

    BelirtiMuhtemel sebepÇözüm
    +trace sonunda eski sağlayıcı NS'leri varDelegasyon değişmemişKayıt firmasında tüm NS satırlarını temizleyip iki Cloudflare değerini yaz
    Delegasyonda 4 NS görünüyorEski NS'ler formda kalmışFazla satırları sil
    dig DS +short dolu, delv SERVFAILEski DNSSEC DS kaydıKayıt firmasında tüm DS kayıtlarını sil, propagasyonu bekle
    +cd ile cevap geliyor, +cd olmadan gelmiyorKırık DNSSEC zinciriAynı şekilde DS kayıtlarını sil
    NS'ler Cloudflare ama panelle aynı değilZone başka hesapta / NS çifti değişmişEski zone'u sil, yeni çifti kayıt firmasına yaz
    Kayıt firması panelinde değişiklik görünüyor ama whois göstermiyorPanelin kendi DNS servisi açık ya da glue kalıntısı varİlgili anahtarı kapat, child nameserver kayıtlarını sil
    Her şey doğru, zone hâlâ pendingÖnbellek / bekleme24 saat bekle, sonra destek talebi aç

    Aktif Olduktan Sonra Yapılması Gerekenler#

    Zone active olduğunda iş bitmiş sayılmaz. Geçişin sessizce bir şeyi bozmadığından emin olmak için şu kontrolleri yapın:

    1. Kayıt envanterini karşılaştırın. Cloudflare zone eklerken mevcut kayıtları otomatik tarar ama bu tarama eksiksiz değildir; özellikle TXT, SRV ve alt alan adları atlanabilir. Eski DNS panelinizin kayıt listesiyle Cloudflare'inkini satır satır karşılaştırın.
    2. E-posta kayıtlarını doğrulayın. MX, SPF, DKIM ve DMARC kayıtlarının hepsinin geldiğinden emin olun; eksik bir SPF kaydı gönderdiğiniz maillerin spam'e düşmesine yeter.
    3. Proxy durumlarını gözden geçirin. Cloudflare tarama sırasında bazı kayıtları turuncu bulutla ekler. mail, ftp, cpanel gibi kayıtlar proxy'lenmemelidir; hangisinin turuncu hangisinin gri olması gerektiğini ayrı bir yazıda kayıt kayıt ele aldık.
    4. SSL/TLS modunu ayarlayın. Origin sunucunuzda geçerli bir sertifika varsa Full (strict) kullanın. Flexible mod, ziyaretçiyle Cloudflare arasını şifreler ama Cloudflare ile sunucunuz arasını açık bırakır ve sık sık yönlendirme döngüsü üretir.
    5. DNSSEC'i yeniden açın. Cloudflare panelinde DNSSEC'i etkinleştirin, ürettiği DS kaydını kayıt firmanıza girin. Böylece 2. sebepte kapattığınız korumayı doğru zincirle geri kazanırsınız.

    Cloudflare'in DNS ve CDN katmanının nasıl çalıştığını, hangi ayarların hangi katmanı etkilediğini Cloudflare DNS ve CDN kullanımı yazısında toparladık.

    Sıkça Sorulan Sorular#

    Cloudflare pending durumdayken sitem çalışıyor, sorun ne?#

    Cloudflare pending bir zone için de DNS cevabı üretir, bu yüzden site açılmaya devam eder. Ancak proxy katmanı devrede değildir: turuncu bulutlu kayıtlarda trafik doğrudan sunucunuza gider, Universal SSL sertifikası düzenlenmez, WAF ve Page Rules kuralları çalışmaz. Yani ödediğiniz veya güvendiğiniz koruma özelliklerinin hiçbiri aktif değildir; sadece DNS barındırma alıyorsunuzdur.

    Pending Nameserver Update ne kadar sürede düzelir?#

    Delegasyon doğru ve DNSSEC kapalıysa Cloudflare genellikle birkaç saat içinde doğrulamayı geçer. Üst seviye NS kayıtlarının TTL'i uzun olduğu için en kötü senaryo 24-48 saattir. Bu sürenin sonunda hâlâ pending ise beklemek çözüm değildir; delegasyonu dig @a.gtld-servers.net alanadi NS ile ve DS kaydını dig alanadi DS +short ile doğrulayıp sorunu bulmanız gerekir.

    DNSSEC'i kapatmak sitemi güvensiz hâle getirir mi?#

    Geçiş süresince evet, ama küçük bir riskle. DNSSEC, DNS cevaplarının değiştirilmesine karşı koruma sağlar; kapalıyken bu koruma yoktur. Buna karşılık kırık bir DNSSEC zinciri sitenizi doğrulama yapan tüm çözümleyicilerde tamamen erişilemez yapar. Doğru yaklaşım, DS kaydını silip zone aktifleştikten sonra DNSSEC'i Cloudflare'in ürettiği yeni DS kaydıyla hemen geri açmaktır.

    Cloudflare nameserver'larımı önceden kayıt firmasına yazabilir miyim?#

    Yazmayın. Cloudflare, alan adı ele geçirme girişimlerini engellemek için zone oluşturulmadan önce nameserver'ları girilmiş alan adlarına farklı bir NS çifti atar. Sonuçta kayıt firmasındaki çift ile panelinizdeki çift uyuşmaz ve zone kalıcı olarak pending kalır. Doğru sıra her zaman önce Cloudflare'de zone'u oluşturmak, sonra size verilen iki değeri kayıt firmasına yazmaktır.

    Alan adım başka bir Cloudflare hesabındaysa ne yapmalıyım?#

    Önce o hesaba erişmeyi deneyin; eski ajans, eski geliştirici veya şirketinizin ikinci e-posta adresiyle açılmış bir hesap olabilir. Eriştiğinizde zone'u Remove Site ile kaldırın, kendi hesabınızda yeniden ekleyin ve size atanan yeni NS çiftini kayıt firmasına girin. Hiçbir şekilde erişemiyorsanız Cloudflare destek talebi açın; alan adı sahipliğini WHOIS kayıtları üzerinden kanıtlamanız istenecektir.

    Nameserver'ları değiştirdim ama whois hâlâ eskisini gösteriyor, neden?#

    İki tipik sebep vardır. Birincisi, kayıt firmasının panelinde "DNS yönetimi bizde kalsın" türü bir seçenek açıktır ve girdiğiniz özel nameserver'lar registry'ye hiç gönderilmez. İkincisi, daha önce kendi alan adınız üzerinden tanımladığınız child nameserver (glue) kayıtları asılı kalmıştır ve registry değişikliği reddetmektedir. Panelde bu iki bölümü kontrol edip temizleyin, ardından değişikliği tekrar kaydedin.

    CloudflareDNSAlan Adı

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.