TR / EN

DNS Security Bir Kurumsal Alan Adını Yanlışlıkla Engellerse Ne Yapılmalı?

Yeni yayına alınmış bir kurumsal alan adı bazı kullanıcılarda açılırken güvenlik filtresi arkasında engellenebilir. İş birimi bunu kesinti, web ekibi DNS sorunu, güvenlik ekibi ise itibar kararı olarak görür. Üçü de kısmen haklı olabilir. False positive demeden önce alan adının gerçekten kuruma ait, doğru yapılandırılmış ve zararlı içerikten arınmış olduğunu kanıtlamak gerekir.

16 Temmuz 2026 tarihli olayda düşük yaş ve sınırlı itibar verisi nedeniyle bir alan adı istenmeyen kategoride değerlendiriliyordu. Global filtreyi kapatmak veya tüm kategoriyi allow yapmak yerine önce bağımsız DNS ve TLS kontrolleri yaptık, ürün günlüğündeki kategori kararını doğruladık. Yalnızca gerekli FQDN için süreli istisna açarken üreticiye kanıtlı yeniden sınıflandırma talebi gönderdik ve istisnaya kapanış tarihi verdik.

Sorunun ortaya çıkışı

Kurumsal duyuru sitesi yayına alındıktan sonra bazı lokasyonlarda güvenlik uyarısı ile engellendi. Mobil ağdan erişim mümkündü; kurum DNS güvenliği kullanan istemciler farklı bir yanıt veya block page alıyordu. Alan adı yeni olduğu için iş etkisi hızla büyüyor, iletişim ekibi hemen whitelist talep ediyordu. Ancak sahiplik ve teknik bütünlük kontrol edilmeden istisna vermek doğru değildi.

Olay kapsamı istemci, lokasyon, resolver ve zaman bilgisiyle çıkarıldı. Yalnızca ana alan adı mı, belirli alt alan mı ve yönlendirme zincirindeki üçüncü taraf hedef mi engelleniyor soruları ayrıldı. Gerçek alan adını genel destek ekranlarına taşımadan kanıtlar güvenli olay kaydında toplandı. Böylece “site açılmıyor” ifadesi belirli bir kategori kararıyla ilişkilendirildi.

İlk belirtiler ve yanlış varsayımlar

İlk varsayım, mobil ağda açılan sitenin otomatik olarak güvenli olduğuydu. Farklı resolver ve filtre politikası yalnızca engelin nerede olduğunu gösterir; içeriğin güvenliğini kanıtlamaz. İkinci varsayım kategori hatasının DNS kaydı hatasıyla aynı olduğuydu. Yanlış A/CNAME, süresi yaklaşan TLS sertifikası veya ele geçirilmiş içerik de güvenlik ürününün şüpheli kararını destekleyebilir.

Tüm “newly observed” veya “uncategorized” kategorisini izinli yapmak hızlı görünüyordu, ancak başka yeni ve riskli alanları da geçirirdi. Wildcard istisna da gereksiz alt alanları kapsayabilirdi. Sadece block page ekran görüntüsüne dayanmak yerine cihaz günlüğündeki kategori, profil, policy ve çözümleme sonucunu gördük. Tarayıcı önbelleği ve yerel DNS cache etkisini kontrollü tekrarlarla ayırdık.

Teknik analiz

Yetkili DNS zinciri, A/AAAA ve CNAME kayıtları, nameserver tutarlılığı ve DNSSEC kullanılıyorsa doğrulama durumu incelendi. TLS sertifikasının ad kapsamı, zinciri ve geçerlilik zamanı kontrol edildi. HTTP yönlendirmelerinin alan dışı beklenmeyen hedefe gitmediği doğrulandı. Web ekibi yayın dosyalarını ve yönetim hesaplarını gözden geçirdi; güvenlik taraması temiz sonuç vermeden false positive kararı verilmedi.

Güvenlik ürününde alanın mevcut kategorisi, ilk görülme/itibar bağlamı ve hangi DNS profili tarafından engellendiği belirlendi. Farklı resolver sonuçları TTL dikkate alınarak karşılaştırıldı. Ürün önbelleği ile istemci önbelleğinin ayrı süreleri olduğu unutulmadı. Aynı registrable domain altındaki servislerin iş amacı ve sahipliği kontrol edilerek istisna kapsamı yalnızca gereken tam alan adına indirildi.

# example.invalid gerçek bir hedef değildir; salt okunur doğrulama
nslookup portal.example.invalid
Resolve-DnsName portal.example.invalid -Type A
Resolve-DnsName portal.example.invalid -Type CNAME

Uygulanan çözüm veya önerilen mimari

Sahiplik, DNS, TLS ve içerik doğrulandıktan sonra yalnızca ihtiyaç duyulan FQDN için dar ve süreli bir allow override oluşturuldu. İstisna belirli güvenlik profiline uygulandı; tüm kullanıcı ve kategorileri kapsamadı. Değişiklik sahibi, iş gerekçesi, son kullanma tarihi ve geri alma adımı kaydedildi. Kullanıcılardan cache temizleme yerine TTL sonrası kontrollü yeniden test istendi.

Aynı anda üreticinin sınıflandırma portalına işlev, sahiplik ve teknik doğrulama kanıtlarıyla başvuru yapıldı. Kategori düzeltmesi farklı ağlardan doğrulandıktan sonra yerel istisna kaldırıldı ve block/allow sonucu tekrar test edildi. Yeni alan adı yayına alma kontrol listesine DNS güvenlik kategorisi, TLS izleme, alan sahipliği ve ön bildirim adımları eklendi; sorun lansman sonrası sürpriz olmaktan çıkarıldı.

Alternatifler ve karar gerekçesi

DNS Security profilini geçici kapatmak sorunu ayırabilirdi ama tüm alanlar için korumayı kaldırırdı. Test amacıyla yalnızca izole bir istemci ve kısa pencere kullanılabilse de üretim çözümü olamazdı. Hosts dosyasına kayıt eklemek kategori kontrolünü atlatabilir, DNS değişikliklerini gizler ve yönetilemez istemci sapması yaratır; bu nedenle kullanılmadı.

Yalnızca üretici yeniden sınıflandırmasını beklemek yerel riski en aza indirir fakat iş etkisi kabul edilemez süreye uzayabilirdi. Teknik güvenlik kanıtları tamamlandığı için süreli dar istisna ile üretici başvurusunu paralel yürüttük. Wildcard yerine exact FQDN seçimi biraz daha fazla bakım gerektirdi, ancak yetki alanını ölçülebilir tuttu ve yeni alt alanları otomatik güvenilir saymadı.

Güvenlik ve operasyonel riskler

Whitelist kalıcı güven damgası değildir. Alan adı daha sonra ele geçirilebilir, içerik veya DNS sağlayıcısı değişebilir. İstisnalar süreli olmalı, düzenli yeniden doğrulanmalı ve SIEM’de görünür kalmalıdır. Alan sahipliği yenileme hesabı, MFA ve registrar lock ile korunmalıdır. TLS sertifikası yalnızca şifreli bağlantıyı doğrular; içeriğin güvenli olduğunu tek başına kanıtlamaz.

Üreticiye gönderilen ekran görüntüsü ve günlüklerde gerçek kullanıcı, iç IP ve politika adı bulunabilir; paylaşım öncesi maskelenmelidir. Yeniden sınıflandırma küresel olduğundan yanlış kategori talebi başka müşterileri de etkileyebilir, açıklama dürüst ve kanıtlı olmalıdır. Override envanteri sahibi olmayan istisnalara dönüşürse güvenlik kontrolü zamanla aşınır; son kullanma uyarısı ve periyodik rapor zorunludur.

Çıkarılan Dersler

Kontrol Listesi