Alan adını satın alıp nameserver ayarlarını yaptığınız anda, aslında görünmeyen ama kritik bir dünya devreye giriyor: DNS yönetimi. Web sitenizin açılması, e-posta adreslerinizin doğru çalışması, blog, panel, API gibi alt alan adlarınızın doğru sunucuya gitmesi tamamen doğru yapılandırılmış DNS kayıtlarına bağlı. Küçük bir yazım hatası bile sitenizin açılmamasına, mail’lerinizin kaybolmasına veya SSL doğrulamasının başarısız olmasına neden olabiliyor.
Bu yazıda kendi projelerimde ve müşterilerimin sistemlerinde sıkça karşılaştığım senaryolar üzerinden gideceğim. Amacım, DNS ekranına baktığınızda “Bu A kaydı ne işe yarıyordu? MX’i nereye yazıyorduk?” gibi soruların tamamını netleştirmek. Eğer daha önce sadece alan adını alıp <a href="https://www.DCHost.com/tr/web-hosting”>Hosting firmasının varsayılan ayarlarına dokunmadıysanız, bu rehberden sonra DNS panelini bilinçli şekilde kullanabilir, web sitenizi, e-posta sisteminizi ve alt alan adlarınızı planlı şekilde kurgulayabilirsiniz.
DNS kayıtlarının temel türlerini daha önce anlattığım DNS kayıtları nedir, A, AAAA, CNAME, MX, TXT ve SPF kayıtları rehberinde detaylıca ele almıştım. Bu yazıda ise daha çok pratik yönetim tarafına odaklanacağız: Hangi senaryoda hangi kayıt kullanılmalı, neyi nereye yönlendirmelisiniz ve hataları nasıl önlersiniz?
DNS Yönetiminin Temeli: Yetkili Nameserver ve Sorumluluğu
DNS yönetimine başlamadan önce bilmeniz gereken ilk şey, alan adınızın hangi DNS sunucuları (nameserver) üzerinden yönetildiği. Çünkü DNS kayıtlarını nereden değiştireceğiniz, tamamen alan adınızın yetkili nameserver’larının nerede olduğuna bağlı.
Genel olarak üç senaryo vardır:
- Alan adı firmasının DNS’i kullanılıyor: Nameserver’lar genelde ns1.registrar.com benzeri olur. DNS yönetimini domain panelinizden yaparsınız.
- Hosting firmasının DNS’i kullanılıyor: Nameserver’lar hosting sağlayıcınızın sunucularına işaret eder. Örneğin bir projede, tüm DNS kayıtlarını hosting panelindeki DNS yönetimi üzerinden yönetmeniz istenebilir. DCHost gibi bir sağlayıcı kullanıyorsanız, alan adını başka yerde tutsanız bile DNS tarafını DCHost paneline devredebilirsiniz.
- Harici DNS hizmeti kullanılıyor: Alan adı başka yerde, DNS kayıtları ise sadece DNS hizmeti veren farklı bir sağlayıcıdadır.
Pratik kural şu: Nerede yetkili nameserver tanımlıysa, DNS kayıtlarını oradan yönetirsiniz. Alan adınızı transfer etmeden önce DNS taşıma planı yaparken, daha önce yayınladığım alan adı transfer rehberini de gözden geçirmenizi öneririm.
Web Sitesini Doğru Sunucuya Yönlendirme (A ve AAAA Kayıtları)
Web sitenizin açılması için en kritik DNS kayıtları A ve varsa AAAA (IPv6) kayıtlarıdır. Temel mantık basit: Alan adınızı, sitenizin barındırıldığı sunucunun IP adresine yönlendirirsiniz.
Temel A kaydı senaryosu
Diyelim ki elinizde şu bilgiler var:
- Alan adınız: ornekdomain.com
- Sunucu IP: 185.10.10.10
DNS panelinizde genellikle şu şekilde kayıt açarsınız:
- Ad / Host: @ (kök alan adı)
- Tür: A
- Değer: 185.10.10.10
- TTL: Örneğin 3600 (saniye)
Bu, ornekdomain.com adresine gelen isteklerin 185.10.10.10 IP’li sunucuya gitmesini sağlar. Çoğu zaman ayrıca www için de yönlendirme yapmak istersiniz.
www için A mı CNAME mi kullanmalı?
İki yaygın yaklaşım var:
- www için CNAME: Host: www, Tür: CNAME, Değer: ornekdomain.com. Böylece ana alan adınız nereye giderse, www de oraya gider.
- www için ayrı A kaydı: Host: www, Tür: A, Değer: sitenin IP adresi.
Ben pratikte çoğunlukla www için CNAME kullanmayı tercih ediyorum. Böylece ileride IP değiştiğinde sadece kök alan adının A kaydını güncelliyorum, www otomatik olarak yeni IP’yi takip ediyor.
Eğer DNS kayıt türlerine daha derinlemesine hakim olmak isterseniz, mutlaka DNS kayıtları A’dan Z’ye yönetim rehberine de göz atın. Bu yazıdaki pratik adımlar oradaki teorik kısmı tamamlayacaktır.
E-Postayı Ayrı Bir Sunucuya Yönlendirme (MX, SPF, DKIM, DMARC)
Günümüzde sık kullanılan senaryolardan biri de web sitesi ile e-postanın farklı sunucularda barındırılması. Örneğin web siteniz bir hosting paketinde, e-posta ise profesyonel bir e-posta hizmetinde olabilir. Bu durumda DNS üzerinde hem MX hem de bazı TXT kayıtlarını doğru ayarlamanız gerekir.
MX kaydı ile e-posta yönlendirme
MX (Mail Exchanger) kaydı, “Bu alan adına gelen mail’ler şu sunucuya gidecek” bilgisini taşır. Tipik bir yapı şöyle olur:
- Ad / Host: @
- Tür: MX
- Öncelik (Priority): Örneğin 10
- Değer: mail.ornekdomain.com veya hizmet sağlayıcınızın verdiği FQDN
Burada en sık yapılan hatalardan biri, MX kaydına IP adresi yazmak. MX kayıtları IP değil, kesin alan adı (FQDN) alır. IP yazarsanız bir kısım istemci çalışabilir, bazıları çalışmaz, test araçları sürekli uyarı verir.
SPF, DKIM ve DMARC için TXT kayıtları
E-posta tarafını gerçekten profesyonel hale getirmek istiyorsanız, SPF, DKIM ve DMARC kayıtlarını da tanımlamanız şart. Bunlar da DNS üzerinde genellikle TXT kaydı olarak oluşturulur.
Bu konuyu daha önce oldukça detaylı işlediğim alan adınızla profesyonel e-posta kurulumu rehberi ve SPF, DKIM ve DMARC ayarları yazısında adım adım anlattım. DNS yönetimi tarafında yapmanız gerekenler özetle şunlar:
- SPF: Hangi sunucuların sizin adınıza mail göndermeye yetkili olduğunu belirtir.
- DKIM: Mail’leri kriptografik olarak imzalamak için kullanılan genel anahtarı içerir.
- DMARC: SPF/DKIM başarısız olursa, alıcı sunucunun nasıl davranması gerektiğini tarif eder.
Bu kayıtları yanlış ya da eksik yapılandırmak, mail’lerinizin spam’e düşmesine veya hiç teslim edilmemesine neden olabilir. DNS ekranında yazdığınız her satırın mail teslimatını direkt etkilediğini aklınızdan çıkarmayın.
Alt Alan Adı (Subdomain) Yönlendirme: Blog, Panel, API, CDN
Gerçek projelerde en çok vakit harcanan yerlerden biri de alt alan adlarının planlanması. Örneğin:
- blog.ornekdomain.com – Ayrı bir WordPress sunucusu
- panel.ornekdomain.com – Yönetim paneli
- api.ornekdomain.com – API servisi
- cdn.ornekdomain.com – Statik içerik servisi
Burada hangi DNS kaydını kullanacağınız, alt alan adının arkasındaki yapıya göre değişir.
A kaydı ile alt alan adı yönlendirme
Eğer alt alan adınız doğrudan bir sunucu IP’sine gidiyorsa, genellikle A kaydı kullanırsınız. Örneğin blog için ayrı bir sunucu IP’niz varsa:
- Ad / Host: blog
- Tür: A
- Değer: 185.20.20.20
Böylece blog.ornekdomain.com adresi bu IP’ye yönlenir. Aynı mantıkla panel, api gibi alt alanlar da ayrı ayrı IP’lere veya aynı sunucuya işaret edebilir.
CNAME ile alt alan adı yönlendirme
Alt alan adınız bir başka alan adını referans alacaksa (örneğin harici bir servis, SaaS paneli, vb.), CNAME kullanırsınız. Örnek:
- Ad / Host: panel
- Tür: CNAME
- Değer: customer.hostedpanel.com
Bu durumda panel.ornekdomain.com, DNS seviyesinde customer.hostedpanel.com’a alias olur. IP değiştiğinde CNAME’in gösterdiği tarafı güncellemeniz yeterlidir.
Önemli not: Kök alan adı (@) için CNAME kullanmayın. Bu, birçok DNS sisteminde desteklenmez ve başka kayıtlarla çakışır. Kök alan adı için her zaman A (ve varsa AAAA) kaydı kullanın.
DNS ile SSL, HTTPS ve Güvenlik Süreçlerini Yönetmek
DNS sadece yönlendirme için değil, SSL doğrulama ve güvenlik süreçlerinde de karşımıza çıkıyor. Özellikle Let’s Encrypt ve benzeri SSL sağlayıcıları, bazen alan adınızın sahibi olduğunuzu kanıtlamak için DNS üzerinden doğrulama (DNS-01) isteyebiliyor.
Eğer SSL ile yeni ilgileniyorsanız, önce Let’s Encrypt ile ücretsiz SSL sertifikası kurulumu rehberine, ardından da HTTP’den HTTPS’ye geçiş rehberine mutlaka göz atın. Orada uygulamalı olarak panel tarafını anlatıyorum; bu yazıda ise DNS boyutuna değineyim.
DNS tarafında tipik olarak şu adımlarla karşılaşırsınız:
- SSL sağlayıcısı size _acme-challenge.ornekdomain.com gibi özel bir alt alan adı ve TXT değeri verir.
- DNS panelinizde bu isimle bir TXT kaydı açıp, verilen değeri girersiniz.
- DNS yayılımı tamamlanınca SSL sağlayıcısı kaydı doğrular ve sertifikanız üretilir.
Burada en sık gördüğüm hata, TXT kaydını yanlış host ismiyle açmak veya TTL’i çok yüksek tutup doğrulamanın gecikmesine neden olmak. SSL geçişlerinde zaten SEO’yu korumak için dikkatli olmanız gerekiyor; bunun detaylarını da HTTPS geçiş kontrol listesi rehberinde adım adım yazdım.
TTL, Yayılım Süresi ve Test Araçları
DNS yönetiminde ikinci kritik kavram TTL (Time To Live). Kısaca, bir DNS kaydının önbellekte kaç saniye tutulacağını belirler. Örneğin TTL 3600 ise, sorguyu yapan DNS sunucuları bu kaydı 1 saat boyunca cache’leyebilir.
Pratikte şu stratejiyi kullanabilirsiniz:
- Yeni bir geçiş (IP değişimi, mail taşıma, vb.) yapacaksanız, önce TTL’i düşürün (300–600 saniye gibi).
- Geçişi yapın, test edin, her şey yolundaysa TTL’i tekrar 3600 veya 7200 gibi daha makul bir değere yükseltin.
DNS yayılım süresi teoride TTL kadar sürse de pratikte bazı ISP’ler daha uzun cache tutabiliyor. O yüzden “DNS değişiklikleriniz 24 saate kadar sürebilir” cümlesi tamamen yalan değil. Kritik taşımalarda asla son dakikaya bırakmamanızı öneririm.
Yaptığınız değişiklikleri kontrol etmek için çeşitli DNS lookup araçlarını kullanabilirsiniz. Farklı lokasyonlardan sorgu yaparak, değişikliklerin gerçekten tüm dünyaya yayılıp yayılmadığını görebilirsiniz. Özellikle web sitesi taşıma operasyonlarında, daha önce detaylıca anlattığım kesintisiz hosting taşıma rehberi ile bu DNS adımlarını birleştirirseniz, neredeyse sıfır kesintiyle geçiş yapmanız mümkün.
En Sık Yapılan DNS Hataları ve Nasıl Önlenir?
Sahada gördüğüm tipik DNS hatalarını ve bunlardan nasıl kaçınabileceğinizi hızlıca özetleyeyim:
- Yanlış nameserver kullanımı: Alan adı farklı, DNS farklı, hosting farklı; ama siz yanlış panelden kayıt değiştirmeye çalışıyorsunuz. Çözüm: Önce Whois veya DNS sorgu aracıyla yetkili nameserver’ı tespit edin.
- CNAME ve diğer kayıt çakışmaları: Aynı host için hem CNAME hem A/MX kaydı açmaya çalışmak. Çoğu DNS sistemi buna izin vermez. Çözüm: Bir host adı için ya CNAME ya diğer kayıtları kullanın.
- SPF kaydını abartmak: Çok fazla “include” veya yanlış IP aralıkları ekleyip SPF’yi 512 byte sınırına yaklaştırmak. Çözüm: SPF politikanızı sade ve net tutun.
- MX kaydına IP yazmak: Bazı eski paneller izin verse de bu best practice değildir. Çözüm: Her zaman tam alan adı kullanın (mail.ornekdomain.com gibi).
- TTL’i gereksiz yüksek tutmak: Özellikle taşıma dönemlerinde 86400 (24 saat) gibi TTL’ler başınıza bela olabilir. Çözüm: Değişiklik öncesi TTL düşürmeyi unutmayın.
DNS yönetimi ilk bakışta karışık görünse de, her kaydın net bir amacı olduğunu unutmayın. Web, e-posta ve alt alan adını ayrı ayrı düşünerek planlama yaptığınızda, işler çok daha düzenli ilerliyor.
Hangi Durumda DNS’i Nereden Yönetmelisiniz?
Bir noktada şu soruyla mutlaka karşılaşıyorsunuz: “DNS’i alan adı firmasından mı, hosting’den mi, yoksa ayrı bir DNS sağlayıcısından mı yönetmeliyim?” Bu aslında mimari ve operasyonel bir tercih.
Kendi projelerimde şöyle bir yol izliyorum:
- Küçük projeler ve basit siteler: Genelde hosting firmasının DNS’ini kullanmak daha pratik. Örneğin DCHost üzerinde bir hosting paketi açtıysam, çoğu zaman nameserver’ları direkt DCHost’a çevirip tüm DNS’i tek panelden yönetiyorum.
- Birden fazla sunucu, karmaşık yapı: Web başka yerde, mail başka yerde, CDN ayrı, API ayrı ise; merkezi bir DNS yönetimi tercih ediyorum. Böylece tüm kayıtlar tek panelde toplanıyor.
- Kritik uptime gereksinimi olan projeler: Global ölçekte yaygın DNS altyapısı olan, SLA sunan DNS servisleri tercih edilebilir; ama burada da yine DNS yönetimini sade tutmak önemli.
Önemli olan, hangi paneli kullanırsanız kullanın, DNS mimarinizi belgelemek: Hangi alt alan adı nereye gidiyor, hangi kayıt ne işe yarıyor, SPF’de hangi IP’ler tanımlı gibi bilgileri bir diyagram veya doküman halinde tutmak, özellikle büyüyen takımlarda hayat kurtarıyor.
Özet ve İleri Adımlar
Alan adı DNS yönetimi, teknik tarafta en sık ihmal edilen ama en çok sorun çıkaran başlıklardan biri. Web sitenizin açılması, e-posta sisteminizin düzgün çalışması, SSL sertifikanızın sorunsuz yenilenmesi ve alt alan adlarınızın doğru yerde sonlanması hep bu görünmez katmanda çözülüyor. Doğru yapılandırılmış A, AAAA, CNAME, MX, TXT ve diğer kayıtlar, hem performans hem de güvenilirlik açısından temeliniz.
Bu rehberde, web sitesi, e-posta ve alt alan adı senaryolarının çoğunu pratik örneklerle anlatmaya çalıştım. Bir sonraki adımda, kendi alan adınız için küçük bir DNS envanteri çıkarmanızı öneririm: Şu an hangi kayıtlar var, hangileri gereksiz, hangileri eksik? Ardından, burada anlattığım prensiplerle kayıtlarınızı sadeleştirebilirsiniz.
Eğer yeni bir sunucuya geçmeyi veya altyapınızı büyütmeyi düşünüyorsanız, DCHost gibi yönetimi kolay bir hosting veya sunucu ortamı üzerinde DNS’i merkezileştirmek işleri ciddi anlamda basitleştiriyor. İleri seviyeye geçmek isterseniz, VPS sunucu yönetimi rehberi ve VPS güvenliği yazılarına göz atarak DNS’in arkasındaki sunucu katmanını da güçlendirebilirsiniz.
Sonuç olarak, DNS ekranına korkarak bakan biri olmaktan çıkıp, hangi kaydın ne işe yaradığını bilen biri olduğunuzda, hem sorun çözme süreniz kısalıyor hem de yeni projeleri çok daha özgüvenli hayata geçirebiliyorsunuz.
