DNS kayıtları sorgulama, bir web sitesinin hangi sunucuda çalıştığını öğrenmek için kullanılan basit bir araç gibi görünür. Oysa işletmelerde DNS, web trafiği, e-posta teslimi, alan adı doğrulaması, sertifika işlemleri ve üçüncü taraf hizmet bağlantılarının ortak kontrol katmanıdır. Bir kaydın yanlış hedefe işaret etmesi ziyaretçiyi farklı bir siteye götürebilir, MX kaydındaki hata e-postayı durdurabilir veya TXT kaydındaki eksik bir doğrulama yeni bir hizmetin etkinleştirilmesini engelleyebilir. Bu nedenle iyi bir denetim, kayıtları listelemekten çok beklenen tasarım ile gözlenen yanıt arasındaki farkı arar.
Türkiye'de küçük işletmeler ve ajanslar için arama niyeti genellikle "DNS kayıtları nasıl kontrol edilir", "MX kaydı sorgulama", "DNS değişikliği ne zaman yayılır" veya "DNSSEC nedir" biçiminde ortaya çıkar. Bu soruların her biri farklı bir operasyon anına işaret eder: yeni site kurulumu, e-posta taşıması, alan adı sağlayıcısı değişimi veya güvenlik incelemesi. Denetim planını bu amaca göre kurmak önemlidir. Her kaydı aynı önem seviyesinde ele almak yerine, müşterinin kullandığı web, e-posta ve doğrulama hizmetlerine göre beklenen kayıt envanterini oluşturun.
DNS kayıt türlerini görevlerine göre okuyun
A kaydı bir adın IPv4 adresini, AAAA kaydı IPv6 adresini gösterir. CNAME, bir adı başka bir ada yönlendiren takma addır ve hedefin kendi DNS çözümlemesine ihtiyaç duyar. MX kayıtları e-posta tesliminde kullanılacak posta sunucularını öncelik numarasıyla belirtir. NS kayıtları alan adının yetkili sunucularını gösterir. TXT kayıtlarında SPF, alan adı doğrulaması, DKIM anahtarı veya servis sahipliği gibi farklı metinler bulunabilir. Bu türler aynı soruya cevap vermez. Örneğin A kaydının doğru olması, MX kaydının veya DKIM TXT kaydının da doğru olduğu anlamına gelmez.
- Web sitesi için A ve AAAA kayıtlarını, varsa CNAME zincirini kontrol edin.
- E-posta için MX hedeflerini ve her hedefin ayrıca çözümlenebildiğini doğrulayın.
- NS kayıtlarının beklenen yetkili DNS sunucularıyla tutarlı olup olmadığını karşılaştırın.
- TXT kayıtlarını amacıyla birlikte okuyun, uzun değerleri gözle kopyalamak yerine araç çıktısını saklayın.
- Wildcard kayıtların alt alan adlarında beklenmedik cevap üretip üretmediğini test edin.
Yetkili sunucu ile genel çözümleyiciyi karşılaştırma
DNS değişikliği yaptığınızda iki farklı sonucu ayırmanız gerekir. Yetkili nameserver, alan adının yayımlanan ana kaynağıdır. Genel çözümleyiciler ise TTL değerine göre daha önceki cevabı önbellekten sunabilir. DNS sorgulama aracı ile görülen cevap ile DNS yayılımı denetleyicisi üzerinde görülen cevap aynı değilse bu her zaman hata anlamına gelmez. Önce NS delegasyonunu, sonra TTL'yi, ardından değişikliğin gerçekten yetkili sunucuda yapılıp yapılmadığını kontrol edin. Bir çözümleyicinin eski kaydı göstermesi, tüm internetin aynı kaydı gördüğünü kanıtlamaz.
Yayılımı beklerken aynı kaydı tekrar tekrar değiştirmek sorunu büyütebilir. Kısa TTL belirlemek, önbelleklerin anında boşalacağı anlamına gelmez; bazı çözümleyiciler ve istemciler kendi davranışlarına sahip olabilir. Taşıma öncesinde TTL'yi makul biçimde düşürün, değişiklik penceresini ve geri dönüş kaydını yazılı hale getirin, ardından yeni kayıtları en az birkaç farklı çözümleyici ve istemci senaryosunda kontrol edin. Bir e-posta taşımasında MX ile birlikte SPF, DKIM ve DMARC kayıtlarının da güncellenmesi gerektiğini unutmayın.
İşletme için DNS denetim senaryoları
Yeni bir web sitesi açılırken beklenen envanter basittir: ana alan adı, www adı, gerekli uygulama alt alan adları, web sunucusunun adresleri ve sertifika kapsamı. E-posta kullanılıyorsa MX, SPF ve DKIM seçicileri eklenir. Ödeme, CRM, müşteri portalı veya doğrulama platformu gibi hizmetler ayrı CNAME veya TXT kayıtları isteyebilir. Bu listeyi sağlayıcıların kurulum ekranında bırakmak yerine alan adı envanterinde sahip, amaç, son doğrulama tarihi ve beklenen değer olarak saklayın. Böylece denetim sırasında "bu kayıt neden var" sorusunun cevabı bulunur.
Alan adı taşımasında ise NS delegasyonu birinci kontrol noktasıdır. Yeni sağlayıcıda kayıtlar oluşturulmadan nameserver değiştirilirse site veya e-posta bir süre tamamen kaybolabilir. Nameserver değişiminden önce A, AAAA, MX ve TXT kayıtlarını dışa aktarın, eski ve yeni bölge dosyasını satır satır karşılaştırın ve üçüncü taraf doğrulama kayıtlarını eksik bırakmayın. DNS geçmişi varsa geçmiş gözlemleri, değişikliğin beklenen zamanla uyumlu olup olmadığını görmek için yararlı bir bağlam sağlar. Geçmiş veri mevcut durumu kanıtlamaz, fakat açıklanamayan sapmaları araştırmaya yardımcı olur.
DNSSEC neyi çözer, neyi çözmez?
DNSSEC, DNS cevabının yetkili kaynaktan geldiğini ve imza zincirinin bütünlüğünü doğrulamaya yönelik bir mekanizmadır. TRABİS'in resmî açıklamasında .tr alanı ve ikinci seviye alanlarda DNSSEC uygulamasının amacı veri kaynağı kimlik doğrulaması ve veri bütünlüğüdür. Bu, DNS çözümlemesindeki belirli manipülasyon risklerine karşı önemlidir. Ancak DNSSEC web uygulamasındaki güvenlik açığını, yanlış A kaydını veya kötü yazılmış bir e-posta politikasını otomatik olarak düzeltmez. Denetimde "imzalı" sonucunu tek başına güvenlik puanı gibi sunmayın; DS ve DNSKEY zincirinin doğrulanması, kayıtların beklenen değerleri ve sertifika kontrolleri birlikte ele alınmalıdır.
DNS cevabının doğrulanması ile cevabın işletme açısından doğru olması farklı kontrollerdir.
DNS denetimi için pratik ayrım
Hatalı kayıtları sınıflandırma
Bir DNS uyarısını doğrudan kesinti olarak etiketlemek yerine önce hata türünü sınıflandırın. NXDOMAIN, ismin mevcut olmadığını gösteren bir yanıttır, fakat yanlış yazım veya henüz oluşturulmamış alt alan adı da aynı sonucu üretebilir. SERVFAIL, çözümleme zincirinde veya imza doğrulamasında sorun olabileceğini belirtir. NODATA ise adın mevcut olup istenen kayıt türünün bulunmadığını gösterebilir. Timeout, rate limit veya geçici çözümleyici hatası da farklı bir kategoridir. Uygulamanız bu durumları tek bir "DNS başarısız" etiketi altında birleştirirse ekip yanlış kişiyi, yanlış zamanda alarma geçirir.
- İstenen kaydı ve alan adının normalleştirilmiş biçimini doğrulayın.
- NS delegasyonunu ve yetkili sunucudan gelen cevabı kontrol edin.
- Genel çözümleyicilerdeki TTL ve cevap yaşını göz önünde bulundurun.
- Yanıt kodunu NXDOMAIN, NODATA, SERVFAIL, timeout veya geçerli cevap olarak ayırın.
- DNSSEC kullanılıyorsa imza zincirini ve DS eşleşmesini ayrı kaydedin.
- Düzeltme sonrası web, e-posta ve doğrulama akışlarıyla gerçek sonucu test edin.
DNS kontrollerini API ile düzenli hale getirme
Bir ajans veya platform onlarca müşterinin alan adını yönetiyorsa manuel sorgu, değişikliklerin arasında kaybolur. DNS API ile beklenen kayıt türlerini programlı olarak çağırabilir, sonuçları alınma zamanı ve gözlenen değerle saklayabilirsiniz. Toplu kontrol sırasında her alan adı için aynı kayıt türlerini istemek yerine envanterde tanımlı amaçları kullanın. Bir müşterinin e-posta sağlayıcısı değiştiğinde eski SPF include değerinin silinip silinmediğini, DKIM seçicisinin cevap verip vermediğini ve MX önceliğinin bekleneni gösterdiğini otomatik olarak kontrol edin. Sonuçları "geçerli, beklenmeyen, bilinmiyor, kontrol edilmedi" şeklinde ayırmak, geçici dış kaynak sorunlarının müşteriye yanlış alarm olarak yansımasını önler.
Son kontrol: DNS kaydı iş hedefiyle uyumlu mu?
İyi bir DNS denetiminin çıktısı yalnızca uzun bir kayıt listesi değildir. Her kritik kayıt için beklenen hedef, amaç, sorumlu ekip, son doğrulama tarihi ve sapma durumunu gösteren kısa bir rapor hazırlayın. Web hizmeti için kullanıcı deneyimini, e-posta için teslim ve kimlik doğrulamayı, güvenlik için DNSSEC ve hassas alt alan adlarını ayrı değerlendirin. Değişikliklerin geçmişi tutulduğunda, yanlış yapılandırma ile normal taşıma arasındaki fark daha hızlı anlaşılır. Bu çalışma özellikle Türkiye'de farklı kayıt kuruluşları, yerel alan adı uzantıları ve birden fazla e-posta hizmeti kullanan KOBİ'lerde önemli zaman kazandırır.
DNS değişiklikleri için kanıt dosyası
Planlı bir DNS değişikliğinde yalnızca yeni değeri kaydetmek yerine değişiklik öncesi ve sonrası kanıt dosyası oluşturun. Eski ve yeni NS, A, AAAA, MX ve TXT kayıtlarını, TTL değerlerini, değişiklik zamanını ve onaylayan kişiyi yazın. Yayılım sırasında farklı çözümleyicilerden alınan cevapları ayrı satırlarda gösterin. Bu kayıt, müşterinin ne zaman düzeldi sorusuna yanıt verirken eski önbellek ile yanlış yapılandırmayı ayırmaya yardım eder. Geri dönüş gerekirse ekip hangi değerin güvenli son durum olduğunu bilir ve rastgele bir eski yedeği uygulamaz.
DNS envanterini uygulama bağımlılıklarıyla eşleştirin. A veya CNAME hedefi bir web sunucusuna, MX hedefi posta platformuna, TXT değeri ise doğrulama veya e-posta güvenliği akışına bağlı olabilir. Kayıt silmeden önce bu bağımlılıkların sahibiyle iletişim kurun. Bir TXT satırı artık gereksiz görünse de faturalama, sertifika veya e-posta teslim sürecinde kullanılabilir. Kayıt adını ve amacını açıklayan bir dokümantasyon, ekip değişikliğinde yanlış silme riskini azaltır. Teknik değer kadar, değerin neden var olduğu da işletme için kanıttır.
- Değişiklik talebi ve onaylayan kişi.
- Önceki ve hedef DNS değerleri.
- TTL ve planlanan yayılım penceresi.
- Yetkili sunucu ve genel çözümleyici sonuçları.
- Bağımlı web, e-posta veya doğrulama hizmetleri.
- Düzeltme, geri dönüş ve kapanış kanıtı.
Bir işletmede DNS sahipliği birden fazla sağlayıcıya dağılmışsa, hangi panelin yetkili olduğunu baştan doğrulayın. Web sunucusundaki değişiklik DNS bölgesini güncellemez; kayıt kuruluşundaki nameserver değişikliği de yeni sağlayıcıda kayıtların hazır olduğu anlamına gelmez. Yetkili sunucudan beklenen sonucu alamıyorsanız önce delegasyonu, sonra bölge içeriğini, ardından çözümleyici önbelleğini inceleyin. Bu sıralama, yanlış panelde yapılan düzeltmelerin ve birbirini geçersiz kılan acil değişikliklerin önüne geçer.
Denetim raporunu farklı ekipler için okunabilir kılma
DNS raporu yalnızca teknik değerlerden oluşursa ürün ve müşteri ekipleri hangi aksiyonu alacağını anlayamaz. Her kritik kayıt için amaç, beklenen değer, gözlenen değer, son kontrol zamanı ve sorumlu ekip bilgisini gösterin. Web ekibi için ziyaretçi etkisini, e-posta ekibi için teslim riskini, güvenlik ekibi için bütünlük ve yetki riskini kısa açıklamayla ekleyin. Bir kayıt bilinmiyorsa bunu kırmızı hata gibi göstermek yerine neden kontrol edilemediğini yazın. Bu format, ajans ile müşteri arasında aynı değişiklik dilini oluşturur.
Denetim sonuçlarını müşteriyle paylaşırken teknik kaydın etkisini de anlatın. A kaydı değişikliği web sitesini, MX değişikliği posta akışını, TXT değişikliği ise doğrulama veya e-posta politikasını etkileyebilir. Her uyarı için ilgili iş sahibini ve güvenli sonraki adımı belirtin. Böylece DNS raporu yalnızca uzmanların okuyabildiği bir çıktı değil, değişikliğin planlanması ve doğrulanması için ortak bir çalışma belgesi olur.
DNS kayıtları sorgulama, teknik ekibin günlük işi gibi görülse de alan adı sürekliliği ve müşteri güveni üzerinde doğrudan etkilidir. Kayıt türlerini göreviyle birlikte okuyun, yetkili kaynak ile önbellekli sonucu ayırın, DNSSEC'in kapsamını abartmayın ve belirsiz durumları dürüstçe işaretleyin. Ardından tek seferlik kontrolü API veya zamanlanmış izleme akışına dönüştürün. Böylece DNS, yalnızca bir kesinti olduğunda bakılan ekran olmaktan çıkar ve web, e-posta ve doğrulama altyapısının düzenli olarak doğrulanan bir parçası haline gelir.