[ OK ]Kernel başlatılıyor...
~/im/blog
Beni İşe Alın

Konuşalım

Çözülmesi gereken bir altyapı probleminiz mi var veya projeniz için desteğe mi ihtiyacınız var? Yeni projeler için bana ulaşabilirsiniz.

İletişime geç

Bağlantılar

Beni sosyal medyada ve profesyonel ağlarda bulun.

© 2026 Irfan Miral. Tüm hakları saklıdır.Geliştiren:Irfan Miral
Gizlilik PolitikasıŞartlar & Koşullar
Ana SayfaHizmetlerHakkımda/ÖzgeçmişBlogİletişimAraçlar
2026-06-04• 5 dk okuma süresi

Gerçekten Önem Taşıyan DNS Kayıtları

Hosting DNS Server Administration Web Hosting

Reklam

Bir müşterinin DNS paneline ne zaman ilk kez girsem, aynı manzarayla karşılaşıyorum: Bir kez denenmiş ve bir daha hiç silinmemiş servislerin kalıntıları, iki önceki mail sağlayıcısından kalma dokunulmamış bir SPF kaydı ve genellikle arka planda sessizce sorun çıkaran eksik veya hatalı yapılandırılmış kritik bir kayıt.

DNS bölgeleri zamanla çöplüğe döner. Çünkü kimse ne işe yaradığını bilmese bile, bir kaydı silmek onu orada bırakmaktan daha riskli hissettirir. İşte benim kendi kontrol ettiğim ve sırasıyla baktığım asıl liste budur.

A ve AAAA: Temeller

A kaydı (IPv4) nadiren eksik olur. Ancak AAAA (IPv6) kaydı genellikle ya hiç yoktur ya da -çok daha kötüsü- artık var olmayan eski bir IPv6 adresini gösterir. Ölü bir AAAA kaydı demek, hem IPv4 hem de IPv6 destekleyen (dual-stack) istemcilerin önce IPv6'yı denemesi, başarısız olması ve ardından IPv4'e düşmesi demektir. Bu da her bağlantıya devasa bir gecikme ekler.

Eğer sunucunuzda aktif olarak IPv6 kullanmıyorsanız, bozuk bir AAAA kaydı olmasındansa hiç olmaması çok daha iyidir.

MX ve maillerle ilgili TXT kayıtları

Eğer domain e-posta gönderip alıyorsa, MX kayıtları mail sunucusunu işaret eder. SPF, DKIM ve DMARC (bunların hepsi TXT kaydıdır) ise o domain adına gönderilen e-postaların güvenilir olup olmadığını belirler.

Bunların nasıl doğru şekilde kurulacağı hakkında daha önce yazmıştım, ancak buradaki kontrol daha basittir: Bu kayıtlar hala güncel gerçeği yansıtıyor mu? Eski bir mail sağlayıcısını listeleyen bir SPF kaydı sadece işe yaramaz bir çöp değildir; mevcut sağlayıcıdan giden yasal e-postalarınızın SPF hizalamasında (alignment) başarısız olmasına ve doğrudan spam klasörüne düşmesine neden olur.

NS kayıtları: Kayıt firmasıyla eşleşiyor mu?

Çok temel gelebilir ancak alan adı için sorgulanan (zone) NS kayıtlarının, domain kayıt firmasında (registrar) yapılandırılan NS'lerle eşleşip eşleşmediğini her zaman teyit edin.

Buradaki bir uyumsuzluk genellikle tam olarak bitirilmemiş bir DNS sağlayıcısı taşıma işleminden arta kalır. Bunun anlamı, önbellekleme (caching) durumuna göre bazı çözümleyicilerin (resolvers) eski sağlayıcının kayıtlarını, bazılarının ise yenininkileri görmesidir. Eğer ilk başta bunu kontrol etmezseniz, "bende açılıyor ama onlarda açılmıyor" şeklindeki bu hata türünün kaynağını bulmak saatlerinizi alır.

dig NS ornek.com
whois ornek.com | grep -i "name server"

CAA: Neredeyse her zaman eksik olan kolay bir adım

CAA (Certification Authority Authorization) kayıtları, domain'iniz için hangi sertifika otoritelerinin (CA) SSL sertifikası üretebileceğini açıkça belirtir. Neredeyse kimse bunu ayarlamaz.

ornek.com.  CAA  0 issue "letsencrypt.org"

Bu ayar her saldırıyı engellemez ancak hayatınızda hiç kullanmadığınız CA'lerden gelebilecek sahte sertifika üretimi riskini tamamen ortadan kaldırır. Maliyeti, sadece sertifika otoritenizi değiştirirseniz güncellemeniz gereken tek bir satırdır. Zahmetsizdir, gerçekten işe yarar ve o DNS bölgesini kim kurduysa ne yaptığını bildiğinin en net göstergesidir.

TTL: Değişiklik yaparken düşük, stabilken yüksek

Bu bir kayıt türü değildir ancak insanları sürekli tuzağa düşürür. Bir taşıma (migration) işlemi sırasında düşük bir TTL (örneğin 300 saniye), bir şeyleri geri almanız gerektiğinde değişikliklerin hızlıca yayılmasını sağlar.

İşler stabil hale geldiğinde, daha yüksek bir TTL (birkaç saatten bir güne kadar), DNS sağlayıcınızın üzerindeki sorgu yükünü azaltır ve son kullanıcıların yerel çözümleyicileri cevabı daha uzun süre önbelleğe (cache) alacağı için sayfa açılışlarını bir miktar hızlandırır. En sık gördüğüm hata, aylar önce bitmiş bir taşıma işleminden kalma kalıcı olarak düşük bırakılmış TTL'dir. Zararsızdır ancak toz bulutu dağıldıktan sonra kimsenin dönüp ortalığı temizlemediğinin açık bir işaretidir.

Edinilmesi gereken alışkanlık

Bu kayıtların hiçbiri egzotik değildir ve bunları kontrol etmek dig komutu ile beş dakikadan fazla zaman gerektirmez. Asıl değer, bir DNS bölgesini (zone) domain'e daha önce dokunmuş tüm servislerin kalıntılarını barındıran bir arkeolojik kazı alanı olarak değil, mevcut gerçeği yansıtması gereken canlı bir alan olarak görmektir.

DNS içeren bir projeyi bitirdiğimde, artık kullanılmayan kayıtları silmek otuz saniyemi alır. Ve benden sonra gelen kişinin (ki genelde aylar sonra yine ben olurum) "acaba bu gizemli TXT kaydını silsem bir şey patlar mı" diye kara kara düşünmesini engeller.

Reklam

ÖncekiGerçekten Geri Yükleyebileceğiniz PostgreSQL Yedekleri: pgBackRest KurulumuSonraki Yeni Bir VPS'te İlk Bir Saat: Sunucu Güvenliği Kontrol Listem