Hosts Dosyası ile Siteyi Test Etme: DNS Değiştirmeden Kontrol

Siteyi yeni sunucuya kopyaladınız, veritabanını yüklediniz, dosyalar yerinde duruyor. Ama alan adını tarayıcıya yazdığınızda hâlâ eski sunucudaki site açılıyor — çünkü dünya için alan adı hâlâ eski IP'yi gösteriyor. Şimdi zor karar: DNS'i değiştirip "umarım çalışır" mı diyeceksiniz, yoksa önce bir yolunu bulup yeni sunucudaki hâlini görecek misiniz? İşte hosts dosyası ile site test etme tam olarak bu ikilemin cevabıdır: DNS değiştirmeden, yalnızca kendi bilgisayarınızda, alan adını yeni sunucunun IP'sine yönlendirirsiniz. Ziyaretçiler eski siteyi görmeye devam eder, siz yenisini gezersiniz.

Bu yazıda hosts dosyasının nerede olduğunu ve nasıl doğru düzenleneceğini Windows, macOS ve Linux için ayrı ayrı anlatıyorum. Ama asıl değerli kısım ondan sonrası: neden Not Defteri'ni normal açtığınızda kaydedemediğiniz, satırı yazdığınız hâlde tarayıcının neden hâlâ eski siteyi gösterdiği, DNS ve tarayıcı önbelleğinin nasıl temizlendiği, HSTS kullanan sitelerde işin neden karıştığı ve — en çok atlanan adım — iş bittiğinde o satırı silmezseniz aylar sonra başınıza ne geleceği. Bunlar taşımayı gerçekten yapan kişinin karşılaştığı sorunlar; tek satırlık örnekle geçiştirilemez.

Hosts Dosyası Nedir ve Neden DNS'ten Önce Gelir#

Hosts dosyası, işletim sisteminin ad çözümlemesinde DNS'ten önce baktığı yerel bir metin dosyasıdır. İçinde bir alan adı için IP adresi tanımlıysa sistem hiç DNS sunucusuna sormaz, doğrudan o IP'ye bağlanır.

Sıralama şöyledir: uygulama bir alan adı ister → sistem çözümleyicisi önce kendi önbelleğine, sonra hosts dosyasına bakar → orada eşleşme yoksa yapılandırılmış DNS sunucusuna sorar. Yani hosts dosyası, DNS'in üstünde çalışan bir "yerel geçersiz kılma" katmanıdır. DNS'in nasıl çalıştığını bilenler için bunun anlamı nettir: alan adının gerçek A kaydına dokunmadan, sadece sizin makineniz için farklı bir cevap üretmiş olursunuz.

Bu, taşıma sırasında üç somut işe yarar:

1. Yeni sunucuyu gerçek alan adıyla test etmek. Birçok yazılım (WordPress, OpenCart, Laravel) veritabanında kayıtlı site adresine göre çalışır. IP ile açtığınızda tema bozulur, yönlendirmeler patlar, çerezler oturmaz. Hosts ile alan adı üzerinden açtığınızda site tam olarak canlıda görüneceği gibi görünür.
2. SSL sertifikasını önceden doğrulamak. Sertifika alan adına verilir, IP'ye değil. Hosts olmadan https:// testi yapamazsınız.
3. Geri dönüşü olan bir test. DNS değiştirdiğinizde hata bulursanız geri alma süreci TTL kadar bekler; hosts dosyasında bir satır silmek yeterlidir.

Hosts dosyasının değiştirmediği tek şey vardır: dünyanın geri kalanı. Google, ziyaretçileriniz, e-posta gönderen sunucular hâlâ gerçek DNS kaydını görür. Bu yüzden hosts, taşımanın kesintisiz olmasını sağlayan adımdır, taşımanın kendisi değil.

Test IP Adresini ve Doğru Satırı Hazırlama#

Başlamadan iki bilgiye ihtiyacınız var: yeni sunucunun IP adresi ve test edeceğiniz alan adı varyantları.

Yeni sunucunun IP'sini nereden bulursunuz:

• Paylaşımlı hostingde cPanel ana sayfasında sağdaki bilgi panelinde "Paylaşılan IP Adresi" veya "Özel IP Adresi" satırında yazar.
• cPanel'de sol menüden Sunucu Bilgileri ekranı da aynı değeri verir.
• VDS/sunucu kullanıyorsanız hosting panelinizdeki sunucu detay sayfasında ya da sunucuda şu komutla:

ip -4 addr show | grep inet
curl -s https://api64.ipify.org; echo

Birinci komut sunucunun kendi arayüzündeki adresi, ikincisi dışarıya çıkarken göründüğü adresi verir. NAT arkasındaki sunucularda bu ikisi farklı olabilir; hosts dosyasına yazacağınız dışarıdan erişilen adrestir.

Hangi satırları yazmalısınız: Sadece çıplak alan adını yazmak yaygın hatadır. Site www ile de açılıyorsa ve yönlendirme test edeceksiniz, ikisini de tanımlayın:

203.0.113.45    orneksite.com
203.0.113.45    www.orneksite.com

Aynı satırda birden fazla ad da yazılabilir; ikisi de geçerlidir:

203.0.113.45    orneksite.com www.orneksite.com

Ayırıcı olarak boşluk ya da sekme kullanın, virgül değil. Satır sonunda # ile yorum bırakmak ileride işinize yarar:

203.0.113.45    orneksite.com www.orneksite.com   # tasima testi - 11.08 bitince sil

Bu yorum size sonra "bu satır neydi" sorusunu sordurmaz. Gerçekten işe yarayan bir alışkanlıktır.

Neyi test etmek istediğinize göre ek satırlar:

Wildcard (*.orneksite.com) hosts dosyasında çalışmaz. Hosts dosyası joker karakter desteklemez; her alt alan adını tek tek yazmanız gerekir. Bu, hosts dosyasının DNS zone dosyasından en belirgin farkıdır.

Windows'ta Hosts Dosyası Düzenleme#

Windows'ta hosts dosyasının yolu şudur:

C:\Windows\System32\drivers\etc\hosts

Uzantısı yoktur, düz metin dosyasıdır. Kritik nokta: bu dizin sistem korumalıdır, Not Defteri'ni normal açarsanız dosyayı kaydedemezsiniz. "Erişim reddedildi" ya da "Farklı Kaydet" penceresi açılır ve dosyayı Belgeler'e kaydeder — siz düzenlediğinizi sanırsınız, sistemdeki dosya hiç değişmemiştir. Türkçe kaynaklarda en çok atlanan ayrıntı budur ve insanların "yaptım ama olmadı" demesinin bir numaralı sebebidir.

Doğru yol:

1. Başlat menüsünde Not Defteri yazın.
2. Sonuca sağ tıklayın → Yönetici olarak çalıştır.
3. Açılan Not Defteri'nde Dosya → Aç.
4. Dosya adı kutusuna yolu doğrudan yapıştırın: C:\Windows\System32\drivers\etc\hosts (Dosya türü filtresi "Metin Belgeleri" olduğu için gözle ararsanız dosyayı göremezsiniz; filtreyi "Tüm Dosyalar" yapmanız gerekir.)
5. Satırlarınızı dosyanın en altına ekleyin.
6. Ctrl+S ile kaydedin. Hiçbir uyarı çıkmadıysa kaydedilmiştir.

PowerShell'i yönetici olarak açıp tek satırda da yapabilirsiniz:

Add-Content -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Value "203.0.113.45`torneksite.com www.orneksite.com`t# tasima testi"

Kontrol için:

Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String "orneksite"

Antivirüs uyarısı gelebilir. Bazı güvenlik yazılımları hosts dosyası değişikliğini zararlı yazılım davranışı sayar — çünkü gerçekten öyle kullanılır. Uyarıya izin verin; yazılım değişikliği geri almışsa dosyayı tekrar kontrol edin.

macOS ve Linux'ta Hosts Dosyası Düzenleme#

macOS ve Linux'ta yol aynıdır:

/etc/hosts

Düzenlemek için root yetkisi gerekir. Terminalde:

sudo nano /etc/hosts

Dosyanın sonuna satırınızı ekleyin, Ctrl+O ile yazın, Enter ile onaylayın, Ctrl+X ile çıkın. vim tercih ediyorsanız sudo vim /etc/hosts, kaydetmek için :wq. Editör kullanmadan eklemek isterseniz:

echo "203.0.113.45  orneksite.com www.orneksite.com  # tasima testi" | sudo tee -a /etc/hosts

Buradaki tee -a kritiktir: sudo echo ... >> /etc/hosts çalışmaz, çünkü yönlendirme operatörü >> sudo'suz kabuk tarafından işlenir ve "Permission denied" alırsınız. Bu, Linux'a yeni geçenlerin klasik takıldığı noktadır.

Kontrol:

grep orneksite /etc/hosts
getent hosts orneksite.com

getent çıktısı yazdığınız IP'yi gösteriyorsa sistem çözümleyicisi satırı okumuş demektir.

macOS'ta bir ek adım vardır: sistem çözümleme önbelleğini yenilemeniz gerekir, aksi halde değişiklik hemen etkili olmaz.

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux'ta çoğu masaüstü dağıtımında systemd-resolved çalışır ve kendi önbelleğini tutar:

sudo systemd-resolve --flush-caches
# yeni sürümlerde:
sudo resolvectl flush-caches

nscd kurulu bir sunucuda ise sudo systemctl restart nscd gerekir.

DNS ve Tarayıcı Önbelleğini Temizleme#

Hosts satırını yazdınız ama site hâlâ eski sunucudan geliyorsa neredeyse her zaman sebep önbellektir. Üç ayrı önbellek katmanı vardır ve üçünü de ayrı ayrı temizlemeniz gerekebilir.

1. İşletim sistemi DNS önbelleği

Windows:

ipconfig /flushdns
ipconfig /displaydns | Select-String orneksite

macOS ve Linux komutları yukarıda. Bu adımı atlarsanız sistem, hosts dosyasından önce kendi önbelleğindeki eski cevabı kullanabilir. DNS önbellek temizleme konusunun ayrıntısı ayrı bir yazıda duruyor.

2. Tarayıcı DNS önbelleği

Chrome ve Edge, işletim sisteminden bağımsız kendi çözümleme önbelleğini tutar. Adres çubuğuna şunu yazın:

chrome://net-internals/#dns

Açılan sayfada Clear host cache düğmesine basın. Aynı sayfanın Sockets bölümünde Flush socket pools de faydalıdır; açık kalan bağlantılar eski sunucuya gitmeye devam edebilir. Firefox'ta about:networking#dns → DNS Önbelleğini Temizle.

3. Tarayıcı içerik önbelleği

Site açılıyor ama eski görünüyorsa bu üçüncü katmandır. En hızlı çözüm gizli/özel pencere kullanmaktır — hem önbellek hem çerezler temiz gelir. Zorunlu yenileme Ctrl+F5 (macOS'ta Cmd+Shift+R) çoğu zaman yeterlidir.

Uygulamalar ayrı davranır. Tarayıcı doğru sunucuyu gösterirken curl, Postman veya bir mobil uygulama farklı sonuç verebilir. Terminalden test ederken:

curl -sI https://orneksite.com | head -n 5
curl -sI --resolve orneksite.com:443:203.0.113.45 https://orneksite.com | head -n 5

İkinci komut hosts dosyasına hiç dokunmadan tek seferlik test yapar; hosts satırınızın doğru IP'yi verip vermediğini karşılaştırmak için mükemmeldir.

Değişikliğin Gerçekten Çalıştığını Doğrulama#

Gözle "site açıldı" demek yetmez; hangi sunucudan geldiğini kanıtlamalısınız. Üç yöntem:

Ping ile IP kontrolü:

ping orneksite.com

Çıktının ilk satırında parantez içinde görünen IP, yazdığınız test IP'si olmalıdır. Değilse hosts satırı okunmuyordur.

⚠️ nslookup orneksite.com ve dig orneksite.com hosts dosyasını okumaz. Bu iki araç doğrudan DNS sunucusuna sorar, sistem çözümleyicisini atlar. Yani hosts satırınız mükemmel çalışırken dig size hâlâ eski IP'yi gösterir ve siz "olmamış" sanırsınız. Bu, insanların saatini yiyen bir tuzaktır. Sistem çözümlemesini test etmek için ping, getent hosts ya da curl kullanın.

HTTP başlığından sunucu kimliği:

curl -sI http://orneksite.com

Server: başlığı iki sunucuda farklıysa (örneğin biri Apache diğeri LiteSpeed) hangisine bağlandığınız anlaşılır.

Kanıt dosyası yöntemi — en kesin olanı: Yeni sunucudaki site kökine küçük bir dosya bırakın:

echo "yeni-sunucu-ok" > /home/kullanici/public_html/kontrol-9182.txt

Sonra tarayıcıdan https://orneksite.com/kontrol-9182.txt adresini açın. İçerik geliyorsa kesinlikle yeni sunucudasınız; 404 alıyorsanız eskisindesiniz. Bu yöntem tüm önbellek ve araç tartışmalarını bitirir. Test bitince dosyayı silmeyi unutmayın.

HSTS, SSL ve Sitenin Yine de Açılmadığı Durumlar#

Her şeyi doğru yaptığınız hâlde tarayıcı sertifika hatası veriyorsa ya da siteyi hiç açmıyorsa, sebep genellikle HTTPS katmanındadır.

Sertifika henüz yeni sunucuda yok. Site eski sunucuda geçerli sertifikayla çalışıyor ama yeni sunucuda henüz Let's Encrypt sertifikası alınmamışsa tarayıcı "Bağlantınız gizli değil" der. Bu bir hata değil, beklenen durumdur — sertifika doğrulaması alan adının gerçek DNS kaydına bakar ve alan adı hâlâ eski sunucuyu gösterdiği için yeni sunucuda otomatik sertifika alınamaz. Genelde DNS geçişinden sonra çözülür. Test aşamasında uyarıyı Gelişmiş → Yine de devam et ile geçebilirsiniz.

HSTS varsa uyarıyı geçemezsiniz. Site daha önce Strict-Transport-Security başlığı gönderdiyse tarayıcı o alan adı için sertifika uyarısını atlamayı reddeder — "Yine de devam et" bağlantısı hiç görünmez. HSTS'in ne yaptığını bilmiyorsanız bu tamamen anlaşılmaz bir duvardır. Üç çıkış yolu var:

1. Yeni sunucuda alan adı için geçerli bir sertifika kurun (eski sunucudan cert.pem + privkey.pem kopyalamak en pratiği).
2. Test için http:// üzerinden gidin — ancak site HTTPS'e zorluyorsa bu da işe yaramaz.
3. Chrome'da chrome://net-internals/#hsts sayfasında "Delete domain security policies" kutusuna alan adını yazıp silin. Bu yalnızca kendi tarayıcınızı etkiler ve site tekrar HSTS başlığı gönderdiğinde geri gelir.

Sunucu alan adını tanımıyor. Doğru IP'ye gidiyorsunuz ama "Sunucunun varsayılan sayfası" ya da başka bir site açılıyorsa, yeni sunucuda o alan adı için vhost tanımlı değildir. Paylaşımlı hostingde alan adı hesaba eklenmemiştir; VDS'te Apache/Nginx yapılandırmasında ServerName / server_name eksiktir. Nginx'te kontrol:

nginx -T | grep -A2 server_name | grep orneksite

Yönlendirme zinciri sizi eski sunucuya atıyor. Yeni sunucudaki .htaccess içinde canlı adrese mutlak bir yönlendirme kalmış olabilir. curl -sIL ile zinciri izleyin:

curl -sIL http://orneksite.com | grep -E "^(HTTP|Location)"

Bu, DNS değişti ama site eski sunucudan geliyor durumunun test aşamasındaki karşılığıdır.

Hosts Kaydını Silmeyi Unutmayın#

Test bittiğinde eklediğiniz satırları mutlaka silin. Bu adım rehberlerde nadiren yazılır ve aylar sonra çok kafa karıştırıcı sorunlara yol açar.

Ne olur: DNS'i değiştirdiniz, taşıma bitti, her şey yolunda. Ama sizin bilgisayarınız alan adını hâlâ hosts dosyasındaki eski test IP'sine gönderiyor. Aylar sonra sunucu değiştirirsiniz, IP değişir, siz siteyi açamazsınız ama başkası açar. "Bende açılmıyor, sende açılıyor mu" konuşması buradan çıkar. Daha kötüsü: eski test sunucusu kapatılmışsa site sizin için tamamen erişilemez hâle gelir ve sebebi bulmak günler alabilir.

Temizlik komutları:

# Windows (yonetici PowerShell)
(Get-Content "$env:SystemRoot\System32\drivers\etc\hosts") -notmatch 'orneksite' | Set-Content "$env:SystemRoot\System32\drivers\etc\hosts"
ipconfig /flushdns

# macOS / Linux
sudo sed -i.bak '/orneksite/d' /etc/hosts
grep orneksite /etc/hosts   # cikti bos olmali

macOS'ta sed -i.bak yedek bırakır; Linux'ta sed -i yeterlidir. Silme sonrası DNS önbelleğini tekrar temizleyin, yoksa satır gitmiş olsa bile eski cevap önbellekte kalabilir.

Ekipçe çalışıyorsanız kimlerin hosts satırı eklediğini bir yere not edin. Beş kişilik bir ekipte üç kişinin makinesinde unutulmuş satır kalması, taşımadan sonraki "bazılarında açılıyor bazılarında açılmıyor" şikâyetinin en yaygın sebebidir.

Hosts Dosyasının Yetmediği Durumlar#

Hosts dosyası her senaryoyu kurtarmaz. Sınırlarını bilmek zaman kazandırır.

Özellikle son üç satır kritiktir. Sanal POS entegrasyonu, webhook alan bir servis ya da harici bir API sizin makinenizdeki hosts dosyasını göremez; onlar gerçek DNS'e bakar. Bu tür entegrasyonların testi ancak DNS geçişinden sonra ya da geçici bir alt alan adı üzerinden yapılabilir.

Müşteriye ya da ekibe önizleme gerekiyorsa en temiz yöntem geçici alt alan adıdır: DNS panelinizde yeni.orneksite.com için yeni sunucunun IP'sine bir A kaydı açarsınız, herkes oradan bakar, canlı site hiç etkilenmez. Bu yaklaşımın tek dezavantajı, site yazılımının kendi adresini veritabanından okuyup yönlendirme yapmasıdır; WordPress'te bunun için wp-config.php içine geçici olarak WP_HOME ve WP_SITEURL tanımlamak gerekir. Nameserver değişikliğinin site erişimini nasıl etkilediği konusu da bu kararda yardımcı olur.

Sıkça Sorulan Sorular#

Hosts dosyası nerede bulunur#

Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts yolundadır. Dosyanın uzantısı yoktur ve düz metin biçimindedir. Windows'ta dosyayı açarken Not Defteri'nin dosya türü filtresini "Tüm Dosyalar" yapmanız gerekir, aksi halde klasörde göremezsiniz. Her üç sistemde de dosyayı düzenlemek yönetici veya root yetkisi ister.

Hosts dosyasını düzenleyip kaydedemiyorum ne yapmalıyım#

Not Defteri'ni yönetici olarak açmadığınız için kaydedemiyorsunuz. Başlat menüsünde Not Defteri'ne sağ tıklayıp "Yönetici olarak çalıştır" seçtikten sonra dosyayı içeriden Dosya → Aç ile açın; bu şekilde kaydetme çalışır. macOS ve Linux'ta aynı sorun sudo kullanmadığınızda çıkar, çözümü sudo nano /etc/hosts komutudur. Ayrıca sudo echo ... >> /etc/hosts biçimi Linux'ta çalışmaz, sudo tee -a kullanmanız gerekir.

Hosts dosyasına yazdım ama site hâlâ eski sunucudan açılıyor#

Neredeyse her zaman önbellek sorunudur ve üç katmanı da temizlemeniz gerekir. Önce işletim sistemi DNS önbelleğini temizleyin (Windows'ta ipconfig /flushdns, macOS'ta dscacheutil -flushcache), sonra tarayıcının kendi DNS önbelleğini chrome://net-internals/#dns sayfasından silin, son olarak gizli pencerede deneyin. Kalıcı olarak çalışmıyorsa ping orneksite.com komutuyla hangi IP'ye gittiğinizi kontrol edin; hâlâ eski IP görünüyorsa satır sözdizimi bozuktur veya dosya kaydedilmemiştir.

Hosts dosyası değişikliği ziyaretçileri etkiler mi#

Hayır, yalnızca o satırın yazıldığı bilgisayarı etkiler. Hosts dosyası tamamen yerel bir dosyadır, hiçbir DNS sunucusuna yayılmaz ve internetteki hiç kimse onu göremez. Ziyaretçileriniz, arama motorları ve e-posta gönderen sunucular alan adının gerçek DNS kayıtlarını görmeye devam eder. Tam olarak bu yüzden taşıma testi için güvenlidir.

Hosts dosyasında wildcard alt alan adı tanımlanabilir mi#

Hayır, hosts dosyası joker karakter desteklemez. *.orneksite.com biçiminde bir satır hiçbir işe yaramaz, sistem onu geçersiz sayar. Test etmek istediğiniz her alt alan adını ayrı ayrı yazmanız gerekir: blog.orneksite.com, shop.orneksite.com gibi. Çok sayıda alt alan adı varsa hosts yerine geçici bir DNS kaydı açmak daha pratiktir.

dig ve nslookup neden hosts dosyasındaki IP'yi göstermiyor#

Çünkü bu iki araç sistem çözümleyicisini atlayıp doğrudan DNS sunucusuna sorar. Hosts dosyası işletim sisteminin ad çözümleme zincirinin parçasıdır, DNS protokolünün değil; dig ve nslookup ise saf DNS istemcisidir. Hosts satırınızın çalıştığını test etmek için ping orneksite.com, getent hosts orneksite.com veya curl kullanın. Bu ayrımı bilmeyen çok kişi doğru yapılandırdığı hâlde "olmadı" sanıp geri alıyor.

HSTS kullanan sitede sertifika uyarısını nasıl geçerim#

Geçemezsiniz; HSTS'in amacı zaten bunu engellemektir. Tarayıcı, o alan adı için daha önce Strict-Transport-Security başlığı gördüyse sertifika hatasında "Yine de devam et" seçeneğini hiç göstermez. En temiz çözüm yeni sunucuda geçerli bir sertifika bulundurmaktır; eski sunucudaki sertifika ve özel anahtar dosyalarını yeni sunucuya kopyalayabilirsiniz. Geçici olarak Chrome'da chrome://net-internals/#hsts sayfasından alan adının güvenlik politikasını silmek de yalnızca kendi tarayıcınız için çalışır.

Test bittikten sonra hosts satırını silmek zorunda mıyım#

Evet, kesinlikle silmelisiniz. Satır kalırsa bilgisayarınız alan adını sonsuza kadar o eski IP'ye göndermeye devam eder; sunucu ilerde değişirse siz siteyi açamazken herkes açabilir ve sorunu bulmak günler alır. Silme işleminden sonra DNS önbelleğini de temizleyin, çünkü satır gitse bile önbellekteki eski cevap bir süre daha kullanılabilir. Satırın sonuna eklediğiniz # tasima testi yorumu ilerde neyi sileceğinizi hatırlamanızı kolaylaştırır.

Kapanış#

Hosts dosyası ile site test etme, taşımayı "umarım çalışır" olmaktan çıkarıp kontrollü bir işleme dönüştüren adımdır. Yapması beş dakika sürer ama doğru yapılması dört şeye bağlıdır: dosyayı yönetici yetkisiyle düzenlemek, üç önbellek katmanını da temizlemek, doğrulamayı dig ile değil ping veya kanıt dosyasıyla yapmak ve iş bitince satırı silmek. Bu dördünü uygularsanız yeni sunucudaki siteyi canlıya hiç dokunmadan, gerçek alan adıyla, SSL dahil test etmiş olursunuz. HSTS duvarına çarparsanız da bunun bir hata değil, sertifika sırasının doğal sonucu olduğunu bilirsiniz.

Taşımayı kendiniz yürütmek istemiyor ya da e-posta kutuları, cron görevleri ve veritabanı gibi parçaların hiçbirini atlamak istemiyorsanız site taşıma hizmeti tüm süreci sizin yerinize yürütür — hosts testi, DNS geçişi ve geçiş sonrası kontroller dahil. Yeni sunucunuzu henüz seçmediyseniz paylaşımlı hosting paketleri küçük ve orta ölçekli siteler için, VDS sunucular ise kendi yapılandırmanızı yönetmek istediğiniz projeler için uygun başlangıçtır. Alan adı yönetimini de aynı yerde toplamak isterseniz alan adı işlemleri sayfasından transfer ve DNS yönetimini tek panelden yürütebilirsiniz.