Alan Adı Güvenliği: Kilit, DNSSEC, Gizlilik ve 2FA

Alan adı güvenliği neden kritik?

Alan adının kayıt veya DNS hesabına erişim kaybı, web sitesi ve e-posta gibi hizmetlerin yönünü değiştirme riski yaratır. Sunucunun çalışması tek başına bu riski gidermez. Ancak transfer, DNS değişikliği ve hesap ele geçirme farklı işlemlerdir; her korumayı hangi işlemi sınırladığına göre değerlendirmek gerekir.

Bu rehber, Registrar Lock, DNSSEC, kayıt verisi gizliliği ve iki faktörlü kimlik doğrulamayı (2FA) birlikte ele alır. Kayıt kuruluşu, yetkili DNS sağlayıcısı ve e-posta hizmeti farklı yerlerde olabilir. Önce bu hizmetlerin hesaplarını ve sorumlularını belirleyin; ardından desteklenen ayarları, kurtarma yollarını ve değişiklik kontrollerini doğrulayın. Bir özelliğin panelde açık görünmesi tek başına uçtan uca koruma kanıtı değildir.

Hangi saldırılara karşı korunmaya çalışıyoruz?

Önce tehdit modelini netleştirelim. Alan adı tarafında tipik olarak şu risklerle karşılaşıyoruz:

• Hesap ele geçirme: Tekrar kullanılan parola, oltalama, çalınmış oturum veya zayıf kurtarma yolu kayıt ve DNS hesaplarını tehlikeye atabilir.
• Yetkisiz transfer: İlgili TLD’nin transfer koşullarının kötüye kullanılması alan adının başka kayıt kuruluşuna taşınmasına yol açabilir; kilit ve yetkilendirme birlikte değerlendirilir.
• DNS değişikliği: A/AAAA, MX veya delegasyon değişiklikleri trafiği farklı hedeflere götürebilir.
• Kayıt verilerinin kötüye kullanımı: Kamusal ya da daha önce sızmış iletişim bilgileri sahte yenileme ve destek mesajlarında kullanılabilir.
• Süre dolumu: Yenileme başarısız olursa hizmet durabilir; silinme ve yeniden kayıt aşamaları TLD ve kayıt kuruluşuna göre değişir.

Bu rehberdeki dört temel mekanizma; Registrar Lock, DNSSEC, Whois gizliliği ve 2FA, yukarıdaki risklerin önemli bir kısmını sistematik şekilde azaltır. Diğer tarafta; alan adınızın süresini yönetme konusunu ayrıca ele aldığımız alan adı süresi dolarsa ne olur rehberini de okumanızı öneririz.

Süre dolumu ve transfer gibi işlemlerde görülen EPP durumlarını anlamak için Alan Adı Durum Kodları: ClientHold ve ServerHold rehberimize de bakabilirsiniz.

Registrar Lock (transfer kilidi) nedir?

Registrar Lock çoğu kullanımda kayıt kuruluşunun yönettiği transfer kilidini ifade eder. EPP kullanan sistemlerde clientTransferProhibited durumu, kilit kaldırılana kadar başka kayıt kuruluşuna transfer isteklerini reddettirir; yalnız izinsiz transferleri ayırt eden bir mekanizma değildir. ICANN Transfer Policy, ilgili gTLD kayıt kuruluşları arasındaki transferleri düzenler. ccTLD’lerin kendi registry kuralları olabilir; her uzantıda aynı EPP/AuthInfo kodu ve işlem sırası bulunduğunu varsaymayın.

AuthInfo/EPP kodu kullanılan transferlerde kodu gizli tutun; kodun varlığı tek başına yetkilendirme veya transfer uygunluğu anlamına gelmez. Transfer kilidi, DNS kayıtlarını, nameserver’ları veya iletişim bilgilerini değiştirmeyi kendiliğinden engellemez. Hesabı ele geçiren kişi kilidi de kaldırabiliyorsa ayrı hesap kontrolleri gerekir. Alan adı transferi planlanmıyorsa desteklenen transfer kilidini etkin tutup gerçek durumunu kontrol edin.

Registrar Lock neden hayati?

Olası bir senaryoda domain sahibi, şifresi çalındığı için alan adı paneline erişimini kaybedebilir; saldırgan transfer kilidini kapatıp diğer transfer koşullarını da sağlayarak domaini başka bir kayıt operatörüne taşıyabilir. Böyle bir transfer tamamlandığında, alan adını geri almak hukuki ve operasyonel açıdan daha zor bir sürece dönüşebilir.

Normal transfer kilidine ek olarak bazı registry ve kayıt kuruluşları Registry Lock sunar. Bu hizmet, kapsamına göre transfer, silme veya kayıt güncellemesini registry tarafında sınırlar; kaldırılması için kayıt kuruluşu ile registry arasında ayrı doğrulama gerekebilir. Her TLD’de sunulmaz. Domain kaydı, nameserver host/glue nesneleri ve DNS bölgesindeki kayıtlar aynı nesne değildir; hangi değişikliklerin kilitlendiğini ve acil kaldırma sürecini hizmet sağlayıcıyla netleştirin. serverTransferProhibited gibi bir durum tek başına ücretli Registry Lock hizmetinin açık olduğunu kanıtlamaz; başka nedenlerle de konabilir.

Registrar Lock nasıl etkinleştirilir? Adım adım

Arayüzü ve kilit desteğini sağlayıcınızdan doğrulayın. Genel kontrol sırası şöyledir:

1. Kayıt kuruluşunun adresini kendiniz açarak doğru hesaba giriş yapın.
2. Alan adının yönetim ekranında desteklenen transfer kilidini bulun.
3. Durumu etkinleştirip kaydedin; panel sonucunu ve varsa ilgili RDAP/EPP durumunu karşılaştırın.
4. Güncelleme veya silme kilidini transfer kilidiyle karıştırmayın. Beklenmedik ya da kaldırılamayan bir durumda nedenini kayıt kuruluşuna sorun.
5. Kilit değişiklik bildirimlerini açın ve yetkili kişileri kaydedin.

DCHost dahil kullandığınız sağlayıcıda ekran adı, varsayılan kilit durumu, ek onay ve Registry Lock desteği değişebilir. İşlemin birkaç tıklamayla yapılacağını varsaymayın; ilgili TLD ve hizmet için güncel destek kapsamını doğrulayın. Bildirim e-postalarını izleyin, fakat mesajdaki bağlantı yerine bildiğiniz panel adresini kullanın.

Transfer yapmanız gerektiğinde ne olacak?

Planlı transferde önce ilgili TLD’nin uygunluk, kimlik doğrulama ve kilit kurallarını kontrol edin. ICANN kapsamındaki gTLD’lerde ilk kayıt, yakın tarihli transfer veya kayıt sahibi değişikliğine bağlı kısıtlar bulunabilir; kullanıcı transfer kilidini kapatmak bunları kaldırmaz. İletişim bilgisi değişikliğinin transfer takvimine etkisini işlemden önce öğrenin. Gerekli AuthInfo kodunu güvenli kanaldan alın, yalnız gerekli kilidi planlı sürede kaldırın ve transfer sonucunu doğruladıktan sonra yeni kayıt kuruluşunda tekrar etkinleştirin. Registrar transferi DNS, web veya posta taşıması değildir; hizmetlerin devamını ayrıca planlayın. Alan adı transferi rehberi bu ayrımı ayrıntılandırır.

DNSSEC: DNS kayıtlarınızı kriptografik olarak imzalamak

DNSSEC, DNS verisinin kaynağını ve bütünlüğünü kriptografik imzalarla doğrulamayı sağlar. Güven zinciri kurulmuş imzalı bölgenin yanıtını DNSSEC doğrulaması yapan çözümleyici denetler; geçersiz veriyi normal yanıt olarak kabul etmez. DNSSEC trafiği şifrelemez, HTTPS’in yerini tutmaz ve yetkili DNS hesabından yapılan geçerli imzalı kötü niyetli değişikliği engellemez. Hesap ve anahtar güvenliği bu nedenle ayrı gereksinimlerdir.

DNSSEC’in temel mantığını ve nasıl çalıştığını daha teknik seviyede öğrenmek isterseniz, DNSSEC nedir rehberimizde kavramları adım adım anlattık. Burada daha çok “nasıl devreye alırım?” ve “nelere dikkat etmeliyim?” tarafına odaklanacağız.

DNSSEC’i hangi durumlarda önceliklendirmelisiniz?

DNSSEC kullanımı, ilgili üst seviye alanın ve hizmet sağlayıcıların desteğine bağlıdır; desteklenen alan adlarında önceliklendirme yapmak işe yarar. Aşağıdaki durumlarda DNSSEC’i kuvvetle öneriyoruz:

• Giriş ve ödeme hizmetleri: DNS yanıtı bütünlüğünü, doğru HTTPS ve uygulama güvenliğiyle birlikte değerlendirin.
• API ve müşteri portalları: DNS hatasının hizmet erişimine etkisini ve istemcilerin kullandığı çözümleme yolunu inceleyin.
• Kritik e-posta: MX ve ilgili DNS kayıtlarının doğrulanması yararlıdır; posta aktarım şifrelemesi ve kimlik doğrulaması ayrıca yapılandırılır.

DNSSEC nasıl etkinleştirilir? Genel akış

Yetkili DNS sağlayıcısı bölgeyi imzalar ve DNSKEY/RRSIG verisini sunar. Üst bölge ise alt bölgenin anahtarına bağlanan DS kaydını yayımlar; kayıtlı bir alan adında bu işlem genellikle kayıt kuruluşu üzerinden ilgili registry’ye iletilir. DNS ve kayıt kuruluşu aynı firma olmak zorunda değildir.

1. Desteği ve sorumluları doğrulayın: DNS sağlayıcısının imzalama ve anahtar yönetimini, üst bölgenin DS desteğini ve kayıt kuruluşunun yayımlama yöntemini kontrol edin. Mevcut DNSKEY/DS durumunu kaydedin; canlı kaydı deneme amacıyla değiştirmeyin.
2. Önce imzalı bölgeyi hazırlayın: Sağlayıcının desteklenen akışıyla DNSSEC’i etkinleştirin. Anahtar ve geçerli imzaların tüm yetkili sunucularda doğru sunulduğunu doğrulamadan DS yayımlamayın.
3. DS’yi üst bölgeye iletin: Sağlayıcının verdiği key tag, algorithm, digest type ve digest değerlerini karşılaştırın. DS’yi yalnız kendi bölgenize eklemek üst bölgedeki güven bağını kurmaz.
4. Zinciri doğrulayın: Üst bölgedeki DS ile yayımlanan DNSKEY ve imzaları kontrol edin. DNSSEC doğrulayıcısı veya DNSViz gibi bir zincir analiz aracıyla sonuçları inceleyin; eski pozitif ve negatif DNS önbelleklerini hesaba katın.

dig +dnssec example.com A DNSSEC verisi ister; tek başına imzaları doğrulamaz. BIND’in delv example.com A aracı kendi doğrulayıcısını kullanır; güncel güven kökü ve çalışan DNS erişimi gerekir. Çıktıda tam doğrulama, imzasız/insecure sonuç ve hata ayrımını okuyun; sadece bir IP dönmesini başarı saymayın. Bu adlar örnektir; gerçek alan adınızı kullanarak kontrolleri planlayın.

DS, DNSKEY ve imzalar birlikte tutarlı olmalıdır. İmza bitişlerini, tüm yetkili sunuculardaki yanıtları ve doğrulama hatalarını izleyin. Anahtar döndürme veya sağlayıcı değişikliğinde önbellek sürelerini ve geri dönüş adımlarını planlayın. DNSSEC key rollover rehberi anahtar geçişini ayrıntılandırır; hiçbir akış koşulsuz kesintisizlik garantisi vermez.

DNSSEC etkinleştirirken dikkat edilmesi gerekenler

Aşağıdaki hatalar, DNSSEC doğrulaması yapan çözümleyicilerde hizmet erişimini etkileyebilir:

• Yanlış DS veya eksik anahtar: Güven zinciri bekleyen doğrulayıcılar yanıtı bogus kabul edip çoğunlukla SERVFAIL döndürür.
• DS olmadan yalnız imzalama: Normal kök güven zinciriyle doğrulama kurulmaz; güvenli biçimde kanıtlanmış imzasız delegasyon, bozuk imzalı delegasyonla aynı değildir.
• Plansız değişiklik: Eski DS önbellekteyken ilgili anahtarı veya imzalamayı kaldırmak kesintiye yol açabilir. İmzaların süresinin dolması da izlenmelidir.

DNS sağlayıcısı değişecekse desteklenen, anahtar sürekliliğini koruyan koordineli geçişi tercih edin. Bu mümkün değilse eski DS’yi kaldırın; üst bölgede kaldırıldığını ve önceki DS TTL’sinin dolduğunu doğrularken eski bölge imzalı kalsın. Ardından delegasyonu değiştirin; yeni delegasyon, imzalı bölge ve önbellek geçişi doğrulandıktan sonra yeni DS’yi yayımlayın. Bu yol geçici olarak DNSSEC korumasını kaldırır. Geri dönüş için de NS/DS sırasını planlayın; rastgele DNSSEC kapatmayın. Yalnız A/AAAA kaydı değiştirmek DNSSEC’i kaldırmayı gerektirmez.

RDAP, Whois Gizliliği ve Kayıt Verileri

gTLD kayıt bilgileri için 28 Ocak 2025’ten itibaren temel sorgulama protokolü RDAP oldu. Whois terimi panellerde veya eski rehberlerde hâlâ görülebilir; ccTLD uygulamaları farklıdır. ICANN Lookup gibi yetkili veriye yönlenen araçlarda kayıt kuruluşu, durumlar ve tarihler incelenebilir; bütün kişi bilgileri kamuya açık olmak zorunda değildir. Whois ve alan adı sorgulama rehberi kayıt verisi kavramlarını açıklar.

Verilerin politika gereği kamuya kapatılması, ayrı bir gizlilik hizmeti ve proxy hizmeti farklı uygulamalardır. Mevcut RDAP çıktısını inceleyin; zaten yayımlanmayan bir alanı ücretli hizmetin kaldırdığını varsaymayın. Gizlilik, açık iletişim verisinden bilgi toplama riskini azaltabilir; eski kayıtları, sızıntıları veya her oltalama yolunu ortadan kaldırmaz.

Whois gizliliği neden önemli?

Alan adı bilgileriniz kamuya açık olduğunda;

• Size özel hazırlanmış, alan adı yenileme veya fatura gibi görünen sahte e-postalar daha ikna edici hale gelir.
• Ad-soyad ve telefon bilgileriniz kullanılarak, destek ekipleri üzerinde sosyal mühendislik denenebilir.
• Şirket içi rolleriniz (teknik sorumlu, finans yetkilisi vb.) ifşa olabilir.

Privacy hizmetinde müşteri kayıt sahibi olarak kalırken alternatif iletişim bilgileri kullanılabilir. Proxy hizmetinde ise sağlayıcı registrant of record olabilir ve müşteriye alan adını sözleşmeyle kullandırır. Bu nedenle “gizlilik hiçbir durumda kayıt sahibi rolünü değiştirmez” demek doğru değildir. Hizmetin sözleşmesini, transfer ve sona erme koşullarını, bildirim iletimini ve veri açıklama sürecini inceleyin; sözleşme ve ödeme belgelerini saklayın. Bunlar belirli bir uyuşmazlığın sonucunu garanti etmez.

Whois gizliliği nasıl açılır?

Genel adımlar şöyledir:

1. Önce güncel kamusal RDAP/kayıt çıktısını ve sağlayıcınızdaki gerçek iletişim bilgilerini kontrol edin.
2. İlgili TLD’de sunulan hizmetin privacy, proxy veya yalnız veri maskeleme olduğunu doğrulayın.
3. Uygun hizmeti sözleşme, ücret, veri açıklama ve erişim kurtarma koşullarını okuyarak etkinleştirin.
4. Sağlayıcının belirttiği güncelleme süresinden sonra çıktıyı tekrar inceleyin; varsa iletişim formu veya aktarma adresinin size ulaştığını test edin.

Bazı üst seviye alan adları (özellikle ülke kodlu ccTLD’ler) gizlilik hizmetini kısıtlı veya farklı kurallarla sunabilir. Bu durumda, hukuki gereklilikler ile güvenlik ihtiyaçlarını dengeleyen bir strateji oluşturmak önemli. Marka ve alan adı portföyünü nasıl konumlandırmanız gerektiğini merak ediyorsanız, alan adı stratejisi rehberimizde farklı senaryoları detaylı biçimde anlattık.

Alan adı panelinde 2FA (iki adımlı doğrulama)

Kayıt kuruluşu, DNS sağlayıcısı ve e-posta hesaplarını ayrı ayrı koruyun. Bu hesaplardan biri ele geçirilirse izin verilen işlemler üzerinden kilit, delegasyon veya kayıt değiştirilebilir. API anahtarları, açık oturumlar ve destek üzerinden kurtarma yolları da hesaba katılmalıdır; yalnız giriş ekranını korumak bütün erişim yollarını korumaz.

2FA, bilgi ve sahiplik gibi farklı faktörleri birleştirir. Parola yanında doğrulama uygulaması ya da güvenlik anahtarı kullanılabilir; desteklenen passkey/WebAuthn akışı cihaz sahipliğini PIN veya biyometrik doğrulamayla birleştirebilir. İki ayrı parola iki faktör değildir. E-postayla gelen kodu da otomatik olarak güçlü ve bağımsız ikinci faktör saymayın.

Hangi 2FA yöntemini tercih etmelisiniz?

• FIDO2/WebAuthn güvenlik anahtarı veya uygun passkey: Doğrulamayı gerçek hizmetin alan adına bağlayarak oltalamaya direnç sağlar. Sağlayıcının desteğini, cihaz doğrulamasını ve kurtarma yöntemini kontrol edin.
• TOTP uygulaması: SMS hattı riskini azaltır, ancak tek kullanımlık kod sahte sitede istenip anlık olarak aktarılabilir; oltalamaya dirençli değildir.
• SMS: SIM değişimi ve mesaj yönlendirme/ele geçirme riskleri vardır. Daha güçlü yöntem yoksa kullanıp yükseltme planlayın.

Destekleniyorsa oltalamaya dirençli FIDO2/WebAuthn yöntemini tercih edin; değilse TOTP pratik bir seçenek olabilir. Yöntem kadar hesap kurtarma akışının güvenliği de önemlidir. Çalınmış oturum, zararlı yazılım veya kötüye kullanılan API anahtarı 2FA’nın dışında kalabilir.

Alan adı panelinde 2FA nasıl kurulur?

Panele göre ekran isimleri değişebilir; genel akış şöyle:

1. Panelin bilinen adresinden hesap güvenliği bölümünü açın ve desteklenen yöntemleri inceleyin.
2. Güvenlik anahtarı/passkey kaydını veya TOTP kurulumunu tamamlayıp doğrulayın. TOTP QR kodunu ve kurulum sırrını paylaşmayın.
3. Destekleniyorsa yedek anahtar ekleyin; kurtarma kodlarını erişimi kontrollü bir yerde saklayın. Tek cihazın kaybı bütün kurtarma yollarını kaybettirmemeli.
4. Mevcut oturumu kapatmadan önce ayrı bir oturumda giriş ve uygun kurtarma yolunu deneyin.
5. Eski cihazları, oturumları ve kullanılmayan API yetkilerini gözden geçirin.

2FA parola ele geçirilmesine karşı ek kontrol sağlar; her yöntemin oltalama dayanımı aynı değildir. Yönetici e-postasında ve ayrı DNS hesabında da güçlü doğrulamayı etkinleştirin. Şüpheli bir girişte yalnız parolayı değiştirmek yerine açık oturumları, token’ları, kayıtlı faktörleri ve kurtarma bilgilerini birlikte inceleyin.

2FA kurarken dikkat etmeniz gerekenler

• Kurtarmayı bağımsız tutun: Alan adının DNS veya posta hizmeti bozulduğunda da ulaşabileceğiniz güvenli bir kurtarma kanalı belirleyin.
• İletişimi izleyin: Yönetim için ayrılmış bir adres yararlı olabilir; asıl gereklilik düzenli izlenmesi, yetkili kişilerce erişilmesi ve korunmasıdır.
• Parola ve kodları koruyun: Benzersiz parolaları ve kurtarma kodlarını kontrollü kasada saklayın; cihaz/kasa kaybına karşı desteklenen kurtarma planını deneyin.

DNS kayıtları, e-posta ve diğer katmanlarla ilişki

E-posta için MX yönlendirmesi, SPF/DKIM/DMARC kimlik doğrulaması ve rDNS teslimat kontrolleri farklı işler yapar. PTR/rDNS tek başına sahte göndereni doğrulamaz; SPF/DKIM/DMARC da posta kutusunun parolasını veya aktarım şifrelemesini korumaz. SPF, DKIM, DMARC ve rDNS rehberi bu katmanları birlikte değerlendirir.

Ayrıca DNS kayıt türlerine hâkim olmak da önemli. Yanlış bir CNAME, eksik bir A kaydı veya hatalı CAA girişi, hem güvenliği hem de erişilebilirliği etkileyebilir. Eğer DNS tarafında kendinizi eksik hissediyorsanız, DNS kayıtları A’dan Z’ye rehberimiz günlük pratikte sık yapılan hataları da örnekleriyle anlatıyor.

Adım adım alan adı güvenlik kontrol listesi

Her alan adı için kayıt kuruluşu, DNS sağlayıcısı, yetkili kullanıcı, yenileme tarihi ve kurtarma sorumlusunu kaydedin. Aşağıdaki listeyi ilgili TLD’nin ve hizmetin desteklediği özelliklere göre uygulayın:

1. Hesap ve e-posta güvenliği

• Kayıt, DNS ve yönetim e-postası hesaplarında benzersiz parola ve desteklenen güçlü doğrulamayı kullanın.
• Alan adının kendi DNS/postasına bağımlı olmayan güvenli kurtarma yolunu doğrulayın.
• Paylaşılan giriş yerine ayrı kullanıcılar ve en az gerekli yetkileri tanımlayın; ayrılan çalışanların oturum ve token erişimini kaldırın.

2. Registrar Lock durumunu kontrol edin

• Desteklenen transfer kilidini, panel ve kayıt durumu üzerinden kontrol edin; transfer planı yoksa etkin tutun.
• Güncelleme, silme ve Registry Lock kısıtlarının kapsamını ayrıca kaydedin.
• Planlı transferde uygunluğu önce doğrulayın; yalnız gerekli kilidi kaldırıp tamamlanınca yeniden kontrol edin.

3. DNSSEC’i planlayın ve devreye alın

• DNS imzalama ve üst bölge DS desteğiyle birlikte işletim sorumlularını belirleyin.
• Test için ayrı bir deneme alanı veya gerçekten delege edilmiş, kendi imzalama ve üst DS bağı olan test alt bölgesi kullanın; sıradan bir alt alan kaydı bu süreci taklit etmez.
• İmzalı bölge hazır olduktan sonra DS yayımlayın; güven zincirini, imza sürelerini ve bütün yetkili sunucuları izleyin. NS/anahtar değişikliği ve geri dönüş planını kaydedin.

4. Whois gizliliğini etkinleştirin

• RDAP’ta yayımlanan verileri inceleyip politika, privacy ve proxy farkını belirleyin.
• Hizmetin kayıt sahibi rolünü ve sözleşmesini doğrulayın; gerekli gerçek kayıt bilgilerini doğru ve güncel tutun.
• Bildirim kanalının çalıştığını test edin; kamusal veri gizliliğini tek başına kimlik ispatı veya oltalama koruması saymayın.

5. 2FA’yı zorunlu politika haline getirin

• Desteklenen FIDO2/WebAuthn yöntemini tercih edin; TOTP kullanılıyorsa kod oltalaması riskini de yönetin.
• Takım üyelerine ayrı hesap, gerekli yetki ve bireysel doğrulama tanımlayın.
• Yedek anahtar ve kurtarma kodlarını güvenle saklayıp erişim kaybı senaryosunu test edin.

6. Alan adı ve DNS değişikliklerini izleyin

• Giriş, kurtarma, transfer kilidi, kayıt sahibi, NS/DS ve DNS değişiklikleri için sunulan bildirimleri açın.
• Değişiklik geçmişini ve DNS bölgesinin bilinen doğru kopyasını saklayın; yetkili sunucu ve doğrulama sonuçlarını izleyin.
• Otomatik yenileme varsa ödeme sonucunu ayrıca kontrol edin; bitiş tarihi, iletişim ve başarısız ödeme uyarıları için sorumlu belirleyin.

7. Şüpheli değişiklikte kurtarma

Temiz bir cihazdan güvenilir iletişim kanalıyla kayıt kuruluşuna ve DNS sağlayıcısına ulaşın. İşlem günlüklerini ve bildirimleri saklayın; yetkisiz transfer sürüyorsa acil müdahale sürecini başlatın. Hesap, e-posta, oturum ve token erişimini güvenceye aldıktan sonra NS/DS ve bölge kayıtlarını bilinen doğru değerlerle, DNSSEC zincirini koruyarak karşılaştırın. Parola, sertifika ve etkilenen hizmet anahtarlarını olay kapsamına göre yenileyin. Kurtarma sonucu ve süresi garanti değildir.

DCHost ile alan adınızı, DNS’inizi ve sunucunuzu birlikte düşünmek

Alan adı güvenliği, DNS ve e-posta hizmetlerinin yanında hosting, VPS, dedicated sunucu veya colocation altyapısının erişilebilirliğini de etkileyebilir. Hizmetleri birlikte değerlendirirken hangi hesabın hangi değişikliği yapabildiğini ve kurtarmadan kimin sorumlu olduğunu açıkça belirleyin.

Bu rehberde; Registrar Lock, DNSSEC, Whois gizliliği ve 2FA’yı tek tek ele aldık. Bir adım öteye geçmek isterseniz, DNS tarafındaki derin güvenlik ve dayanıklılık konularını da işlediğimiz yazılara göz atabilirsiniz. Örneğin, DNSSEC anahtar döndürme süreçleri için DNSSEC key rollover rehberimiz, genel DNS güvenliği ve kayıt türleri için ise DNS kayıtları A’dan Z’ye yazımız iyi birer tamamlayıcıdır.

Her domain için transfer kilidi, DNSSEC zinciri, kamusal kayıt verisi, hesap doğrulaması ve yenileme durumunu kaydedin. Değişiklikleri izleyip kurtarma planını güncel tutun. DCHost hizmetlerini değerlendiriyorsanız ilgili uzantıda kilit, DS yönetimi, gizlilik ve destek seçeneklerinin kapsamını teyit edin; bu kontrollerin varlığını veya kesintisiz sonucu varsaymayın.