Alan Adı Güvenliği: Transfer Kilidi, Yenileme ve WHOIS

Alan adı güvenliği dört ayara dayanır: transfer kilidi etkin, otomatik yenileme açık, kayıt sahibinin bilgileri gizli ve kayıt firması hesabında iki adımlı doğrulama. Dördü de kayıt firmasının panelinde dakikalar süren işlerdir. Ama fabrika ayarında açık gelmeyebilirler. Aynı kayıt firmasındaki yedi alan adımızın altısında transfer kilidi kapalıydı.

DNS nedir yazısında alan adını bir telefon numarasına, kayıt firmasını da o numarayı tahsis eden operatöre benzetmiştik. Alan adı güvenliği, numaranın elinizden gitmemesidir. Numara üç yoldan gider: sizden habersiz başka operatöre taşınır, faturası ödenmediği için kapatılıp başkasına verilir ya da operatördeki hesabınızın şifresini ele geçiren biri hattın ayarlarını değiştirir.

Bu yazıda kendi alan adlarımızdan pingeverything.com’u kilitledim ve değişikliği kayıt otoritesinin herkese açık kaydında izledim. Ekranlar bu alan adının gerçek kayıt firması panelinden. Kurumsal ağlarda alan adı ve DNS düzenini kurumsal ağ kurulumu hizmetimiz kapsamında kuruyoruz.

Alan Adı Neden Korunur? Elden Çıkmanın Üç Yolu

Alan adı korunur, çünkü onu kontrol eden kişi sitenizi, mailinizi ve kimliğinizi kontrol eder. DNS kayıtlarını yazabilen biri sitenin hangi sunucuya gideceğine, mailin hangi sunucuya düşeceğine ve SPF, DKIM ve DMARC kayıtlarıyla kimin adınıza mail gönderebileceğine karar verir. Alan adı üç yoldan elden çıkar:

1. Yetkisiz transfer. Alan adı sizden habersiz başka bir kayıt firmasına taşınır. Taşındığı anda kayıtlar da yeni tarafın elindedir.
2. Süresinin dolması. Alan adı süreli bir tahsistir. Yenilenmezse önce çözümlemesi kesilir, sonra silinir ve başkası kaydedebilir.
3. Kayıt firması hesabının ele geçirilmesi. Panele giren biri nameserver’ları değiştirir ve alan adını hiç taşımadan bütün trafiği başka yere yönlendirir.

Üçüncü yol en sinsi olanıdır, çünkü alan adı kâğıt üstünde hâlâ sizindir. ABD’nin siber güvenlik ajansı CISA, 2019’da devlet kurumlarına bu saldırı için acil bir yönerge yayımladı. ED 19-01 saldırının ilk adımını DNS kayıtlarını değiştirebilen bir hesabın credential’larının (kimlik bilgileri) ele geçirilmesi olarak tarif ediyor. Yönerge bugün kapatılmış durumda, ama tarif ettiği zincir değişmedi.

Bir alan adının bugünkü kilit durumu herkese açıktır. Kayıt otoritesinin RDAP kaydı (eski adıyla WHOIS’in yerini alan sorgulama hizmeti) alan adının durum kodlarını listeler. Kilitsiz bir .com alan adında bu liste tek kelimedir: active. Kendi alan adlarımızın yedisini sorguladım, altısı böyle çıktı.

Alan Adı Güvenliği Nasıl Olmalı?

Doğru düzende alan adı kurumun kendi hesabında durur, transfer kilidi etkindir, yenileme otomatiktir ve yenileme uyarıları alan adının dışındaki bir adrese gider. Panel hesabında iki adımlı doğrulama açıktır. Bu düzeni üç birinci el kaynak birlikte tarif ediyor:

1. ICANN SSAC, SAC044, bölüm 7.3.1. ICANN’in güvenlik danışma komitesinin alan adı sahiplerine yazdığı rehber, transfer kilidinin (clientTransferProhibited) etkin olduğundan emin olunmasını öneriyor. Hemen ardından gelen 7.3.2. bölüm ikinci bir katman olarak registry lock’u da değerlendirmeye çağırıyor.
2. SAC044, bölüm 5.1, 7. madde. Alan adının iletişim adresleri, o alan adının dışında adlandırılmış mail sunucularına bağlanmalı. Aynı bölüm iki adımlı doğrulama destekleniyorsa kullanılmasını, her hesap için ayrı credential’ı ve personel değişince eski bilgilerin iptalini istiyor.
3. CISA ED 19-01, Üçüncü Eylem. DNS kayıtlarını değiştirebilen her hesapta çok faktörlü doğrulama zorunluydu. Yönerge SMS ile yapılan doğrulamayı önermiyordu.

Kaynakların hiçbiri otomatik yenilemeyi ayrıca şart koşmuyor. SAC044 yenileme uyarılarının bir personel işini tetiklemesini istiyor. Otomatik yenilemeyi yine de öneriyorum, çünkü uyarıyı okuyacak kişinin o hafta izinde olması alan adını tek başına düşürmez. Yenileme kendiliğinden yapılır.

Registry Lock: google.com’un Altı Kilidi

Transfer kilidinin iki katmanı vardır ve RDAP ikisini ayrı gösterir. ICANN’in durum kodları sayfası farkı tek cümlede veriyor: client ile başlayan kodları kayıt firması, server ile başlayanları kayıt otoritesi koyar ve server kodları öncelikli sayılır. Aynı gün birkaç büyük alan adını sorguladım:

İlk satırdaki altı kilidin üçü registry lock’tur. .com uzantısını işleten Verisign’ın Registry Lock sayfasına göre bu kilit ancak kayıt firmasındaki yetkili kişiye telefonla ulaşılıp bir güvenlik parolası söylenince açılıyor. Panele giren bir saldırgan kayıt firmasının kilidini kaldırabilir, ama bu telefon adımını atlayamaz.

Kurumların çoğu için kayıt firmasının transfer kilidi asgari düzendir ve bizim kayıt firmamızda ücretsiz etkinleşti. Registry lock, gelirin doğrudan alan adına bağlı olduğu yerde değerlendirilir: e-ticaret sitesi, ödeme sayfası, müşteri portalı. Her kayıt firması bu hizmeti sunmuyor, bu yüzden önce kayıt firmanıza sormanız gerekir.

Transfer Kilidi Nasıl Etkinleştirilir? Panel ve RDAP

Transfer kilidi kayıt firmasının panelinde, alan adının yönetim sayfasından etkinleştirilir. Bizim kayıt firmamızda menünün adı Transfer Korumasını Aç’tı. Sizin panelinizde Transfer Lock, Domain Lock, Domain Kilidi ya da Transfer Kilidi olarak geçebilir. Adımlar şunlardır:

1. Panelde alan adınızın yönetim sayfasını açın.
2. Transfer bölümünde durumun Transfer Edilebilir olduğunu görün ve Transfer Korumasını Aç’a basın.
3. Açılan pencerede Transfer Edilemez’i seçin ve Kaydet’e basın.

Kaydedince panelin Transfer bölümü yeni durumu gösterir. Bağlantının adı da Transfer Korumasını Kapat olur, yani kilidi kaldırmak aynı yerden tek tıkla yapılır:

Transfer Kilidini RDAP ile Doğrulamak: Dakikasında Geçti

Panel bir şey söyler, kayıt otoritesi başka bir şey söyleyebilir. Kilidin gerçekten işlediğini görmek için pingeverything.com’u dışarıdan, RDAP ile sorguladım. Kilitten önce ve sonra kayıt şöyleydi:

Kaydın son değişiklik zamanı, Kaydet’e basıldığı dakikayı gösteriyor ve 38 saniye sonraki ilk sorgumda kilit görünüyordu. Beklenecek bir yayılma süresi yok, çünkü değişen şey DNS’teki gibi önbellekler arasında dolaşan bir kayıt değil, kayıt otoritesinin kendi veritabanındaki bir alan.

Transfer Kilidi Neyi Engeller, Neyi Engellemez?

Kilit yalnız taşımayı durdurur. EPP standardı RFC 5731 bu kod için tek şey söylüyor: transfer istekleri reddedilmek zorunda. Nameserver değişikliği, DNS kayıtları ve yenileme bundan etkilenmez. Kilitlediğim alan adının sitesi on dakika sonra da 200 dönüyordu.

Alan adını gerçekten taşımak istediğiniz gün kilidi aynı pencereden kaldırır, kayıt firmasından transfer kodunu alır ve kodu yeni firmaya verirsiniz. Telefon benzetmesinin koptuğu yer burasıdır. Numaranızı taşırken yeni operatör kimliğinizi görür. Alan adı transferinde ise kapıyı açan asıl şey kilidin kalkması ve transfer kodudur, bu yüzden kod bir parola gibi saklanır.

Taşımanın iki takvim kuralı vardır. ICANN’in bugün yürürlükteki transfer policy’si (I.A.3.7.5 ve 3.7.6) kayıt firmasına, kayıttan sonraki ve bir transferden sonraki ilk 60 gün içindeki transfer isteğini reddetme hakkı veriyor. ICANN yönetim kurulu 7 Haziran 2026’da bu süreleri 720 saate, yani 30 güne indiren yeni policy’yi kabul etti. Ama bu yazının yazıldığı gün o policy henüz uygulamaya alınmamıştı.

Alan Adı Yenileme: Süre Dolunca Ne Olur?

Kilit yetkisiz taşımayı durdurur, ama süresi dolan bir alan adını korumaz. Alan adı yenilenmezse ICANN’in süresi dolan alan adları policy’si .com gibi uzantılarda şu takvimi işletir:

1. Bitişten önce iki hatırlatma. Kayıt firması biri yaklaşık bir ay, biri yaklaşık bir hafta önce uyarı gönderir.
2. Bitişten sonra bir hatırlatma. Bitişten sonraki beş gün içinde bir uyarı daha gelir.
3. DNS çözümlemesi kesilir. Alan adı hâlâ yenilenebilirken, en azından son sekiz gün boyunca çözümleme kesilir. Site ve mail bu noktada durur.
4. Silinirse 30 günlük geri alım dönemi başlar. ICANN’in durum kodları sayfasına göre bu dönem bittikten beş takvim günü sonra alan adı kayıttan silinir ve isteyen kaydedebilir.

Telefon benzetmesinde bu, faturası ödenmeyen hattın önce kesilip sonra numarasının başkasına verilmesidir.

Bu takvimin önündeki ilk engel otomatik yenilemedir. Kontrol ettiğim alan adlarının en az dördünde otomatik yenileme kapalıydı ve panel bunu kırmızı bir bağlantıyla gösteriyordu:

Otomatik yenileme açık olsa bile yenilemeyi iki şey durdurabilir:

1. Kayıtlı kartın süresi dolar. Yenileme günü ödeme alınamaz ve alan adı bitiş takvimine girer.
2. Uyarı okunmayan bir adrese gider. Kart sorununu haber veren mail kimsenin bakmadığı bir posta kutusunda bekler.

ICANN’in aynı policy’si ikinci tuzağı açıkça yazıyor: uyarılar normalde süresi dolan alan adının kendi mail adresine gidiyorsa ve çözümleme kesildiği için teslim edilemiyorsa, başka bir adrese gönderilmeli. İletişim adresini alan adının dışında tutmanın sebebi budur. sirket.com’un yenileme uyarısı muhasebe@sirket.com’a gidiyorsa, alan adı düştüğü gün o uyarıyı okuyacak posta kutusu da düşmüştür.

WHOIS Gizliliği: Kayıt Sahibinin Bilgileri Kimde Görünür?

Kayıt sahibinin adı, adresi ve telefonu kayıt firmasında durur, ama herkese açık kayıtta görünmeyebilir. ICANN’in 21 Ağustos 2025’te yürürlüğe giren kayıt verisi policy’si bu bilgilerin gizlenmesini yasanın gerektirdiği yerde zorunlu, kayıt firmasının makul bir gerekçesi olduğu yerde serbest kılıyor. Ülke bilgisi her durumda görünür kalıyor. E-posta adresi ise açıkça yazılmıyor, yerine kayıt sahibine ulaştıran bir form ya da anonim bir adres konuyor.

Telefon benzetmesinde bu, numaranın rehberde adınız olmadan listelenmesidir. Numara herkese görünür, sahibi görünmez. Kendi alan adımızın herkese açık kaydında kayıt sahibinin bilgileri boş geldi. Panelde sebebi görünüyordu: kimlik koruma seçeneği fabrika ayarında açıktı.

Gizlilik açıkken bile kayıt firmasındaki bilgilerin doğru olması gerekir. Sahipliği kanıtlamanız gereken gün, örneğin hesabınıza erişimi kaybettiğinizde, kayıt firması kayıt sahibi olarak yazılan kişiyi ya da şirketi tanır. Alan adı bir çalışanın adına kayıtlıysa, o gün karşınıza çıkacak kişi odur.

Kayıt Firması Hesabı: Bütün Ayarların Anahtarı

Kilit, yenileme ve gizlilik aynı panelde durur ve panele giren biri üçünü de değiştirebilir. Bu yüzden asıl koruma panelin kendisidir. Kayıt firması hesabı için sırayla şunlara bakılır:

1. İki adımlı doğrulama açık mı? Bizim iki kayıt firmamızdan birinde açıktı, ötekinde kapalıydı. Alan adlarını açık olana taşıyoruz. Hangi yöntemin neye karşı koruduğunu iki adımlı doğrulama yazısında anlattık.
2. Hesap kimin? Alan adı kurumun kendi hesabında durmalı, ajansın ya da bir çalışanın kişisel hesabında değil.
3. Erişim kişiye mi role mi verilmiş? SAC044 iletişim kişilerinin rolle tanımlanmasını ve personel değişince eski credential’ların iptal edilmesini istiyor.
4. DNS’in tutulduğu ikinci panel korunuyor mu? Nameserver’larınız başka bir hizmetteyse kayıtlar orada değişir. DNS nedir yazısında anlattığımız ayrımın güvenlik karşılığı budur: iki ayrı panel, iki ayrı anahtar.

Alan Adı Güvenliği Nasıl Kontrol Edilir?

Panelde gördüğünüzü dışarıdan doğrulamak tek komut ister. .com ve .net alan adlarının RDAP kaydını Verisign yayımlar. PowerShell’de alan adının durum kodlarını ve tarihlerini şöyle okursunuz:

$r = Invoke-RestMethod https://rdap.verisign.com/com/v1/domain/example.com
$r.status
$r.events | Select-Object eventAction, eventDate

client delete prohibited
client transfer prohibited
client update prohibited

eventAction                  eventDate
-----------                  ---------
registration                 1995-08-14T04:00:00Z
expiration                   2027-08-13T04:00:00Z
last changed                 2026-08-14T08:01:43Z
last update of RDAP database 2026-10-07T04:38:03Z

Çıktıda bakılacak yerler şunlardır:

1. client transfer prohibited satırı olmalı. Yalnız active görüyorsanız kilit kapalıdır.
2. expiration tarihi takviminizde olmalı. Bitişe bir aydan az kaldıysa ve otomatik yenileme açık değilse bugün yenileyin.
3. last changed tarihi sizin bildiğiniz bir değişikliğe denk gelmeli. Hatırlamadığınız bir tarih, hesaba başka birinin girdiğinin ilk işareti olabilir.

.com dışındaki genel uzantılar için ICANN’in kayıt verisi sorgulama aracı aynı bilgiyi tarayıcıda verir. Aynı kayıttaki $r.nameservers.ldhName alanı nameserver’ları listeler. Hangi panelin geçerli olduğunu bulmanın yolu da budur.

Alan Adı Güvenliğinde Sık Yapılan Hatalar

Aşağıdaki hataların her biri tek başına alan adını kaybettirebilir ve hiçbiri teknik bir açık değildir:

1. Alan adını ajansın ya da çalışanın hesabında bırakmak. Ajansla yollar ayrıldığında ya da çalışan ayrıldığında alan adının yenilemesi de, kilidi de onunla gider.
2. İletişim adresini aynı alan adında tutmak. Alan adı düştüğünde onu kurtaracak uyarılar da düşen alan adının posta kutusuna gider.
3. Taşımadan sonra kilidi yeniden etkinleştirmemek. Taşıma biter, yeni kayıt firmasında kilit fabrika ayarında kapalı kalabilir ve kimse bakmaz.
4. Yalnız kayıt firmasını korumak. DNS başka bir hizmette tutuluyorsa o hesabın iki adımlı doğrulaması da aynı ağırlıktadır.
5. Otomatik yenilemeye güvenip kartı unutmak. Otomatik yenileme açıktır, ama kayıtlı kartın süresi bitişten önce dolmuştur.

Sonuç: Numarayı Koruyan Şey Paneldeki Dört Ayardır

Alan adınızı koruyan şey teknik bir sistem değil, kayıt firmasının panelinde dört ayardır: transfer kilidi, otomatik yenileme, kimlik koruma ve hesabın iki adımlı doğrulaması. Telefon numarası benzetmesinde bunlar numaranın taşınmasını kilitlemek, faturayı otomatiğe bağlamak, rehberde adınızı gizlemek ve operatördeki hesabınızın şifresini korumaktır. Ölçümden iki sonuç çıktı:

1. Kilit fabrika ayarında kapalıydı. Aynı kayıt firmasındaki yedi alan adımızın altısında durum kodu yalnız active’ti.
2. Kilit anında geçti. Kaydet’e basıldığı dakikada kayıt otoritesinin kaydı değişti, beklenecek bir yayılma süresi yoktu.

Alan adının kayıt firması ile DNS’inin tutulduğu yer arasındaki ayrımı DNS nedir yazısında, mail kimliğini koruyan kayıtları SPF, DKIM ve DMARC yazısında anlattık. Kurumunuzun alan adlarını ve DNS düzenini kurumsal ağ kurulumu hizmetimiz kapsamında kuruyor ve izliyoruz.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn