DNS Yönetici Kursu — Laboratuvar Ortamı

Ders 1

Çözümleme, Önbellekleme ve Çözümleyiciler

Alıştırma Hedefi

Bir özyinelemeli çözümleyicinin önbellekteki yanıtı ile yetkili yanıt arasındaki farkı gözlemleyin ve kendi domaininizde TTL azalmasını gerçek zamanlı ölçün.

Neden Önemli

Neredeyse her "DNS çalışmıyor" destek talebi aslında bir önbellekleme yanlış anlamasıdır — değişiklik doğru yapılmıştır ama bir çözümleyici (İSS'niz, herkese açık bir çözümleyici veya kendi işletim sisteminiz) hâlâ eski önbellekteki yanıtı sunmaktadır. Eski yanıtın nerede olduğunu kanıtlayabilmek, bu kursun en çok kullanılan teşhis becerisidir.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Domaininizi İSS'nizin/varsayılan çözümleyicinizin üzerinden sorgulayın, TTL'i not edin
dig yourdomain.com A

# Aynı kaydı doğrudan herkese açık bir çözümleyiciden sorgulayın, TTL'i karşılaştırın
dig @1.1.1.1 yourdomain.com A
dig @8.8.8.8 yourdomain.com A

# Yetkili ad sunucusunu doğrudan sorgulayın (tüm önbelleklemeyi atlar)
dig @ns1.yourdnsprovider.com yourdomain.com A +norecurse

# TTL'in azalışını izleyin: her 10 saniyede aynı sorguyu tekrarlayıp TTL alanını karşılaştırın
watch -n 10 "dig @1.1.1.1 yourdomain.com A | grep -A1 ANSWER"

A kaydının IP'sini panelden değiştirin, ardından TTL süresi dolmadan önce ve sonra özyinelemeli sorguyu tekrar çalıştırın — TTL sıfıra ulaşana kadar ESKİ değeri, ardından YENİ değeri gördüğünüzü doğrulayın.

Ek Notlar (Role Özel)

Sysadmin: yerel işletim sistemi önbelleklemesinin çözümleyici önbelleğinden ayrı bir katman olduğunu kanıtlamak için systemd-resolve --flush-caches (veya macOS'ta dscacheutil -flushcache) de işinize yarayacak — iki önbellek, iki temizleme noktası, sıkça birbirine karıştırılır.
DevOps: konteynerize/k8s ortamlarında asıl sorun genellikle CoreDNS'in kendi önbellek TTL'idir (upstream TTL'den ayrı) — CoreDNS pod'unda kubectl logs ve pod içinden dig eşdeğer bir alıştırmadır.
Security-adjacent: burada DoH/DoT'yi tanıtmak da uygun olur — dig @1.1.1.1 sorgusunu kdig +tls @1.1.1.1 yourdomain.com ile (eğer knot-dnsutils kuruluysa) veya https://cloudflare-dns.com/dns-query adresine curl ile tekrarlayın ve karşılaştırın — aynı yanıt, farklı taşıma, farklı gizlilik düzeyi.

← Derse Dön 1

Ders 2

Delegasyon, Glue Kayıtları ve Yedeklilik

Alıştırma Hedefi

Domaininizin tam delegasyon zincirini kökten itibaren izleyin, glue kayıtlarının doğru olduğunu onaylayın ve sakat delegasyonu tespit edin.

Neden Önemli

Yanlış yapılandırılmış veya sakat bir delegasyon, öyle olmayana kadar görünmezdir — bazı çözümleyiciler çalışan yolu önbelleğe alır ve sorunu haftalarca gizler, ta ki önbellek süresi dolup kullanıcılar aniden domaine erişemeyene kadar. Bu, NODA'nın kendi CAT-INFRA kategorisinin kontrol ettiği bir numaralı temel nedendir.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Delegasyon zincirini manuel izleyin, root -> TLD -> sizin NS
dig +trace yourdomain.com

# ÜST zonun ad sunucularınız hakkında ne söylediğini kontrol edin
dig yourdomain.com NS @a.root-servers.net    # (veya +trace çıktısındaki ilgili TLD sunucusu)

# SİZİN ad sunucularınızın kendileri hakkında ne söylediğini kontrol edin (eşleşmeli)
dig yourdomain.com NS @ns1.yourdnsprovider.com

# Glue'yu kontrol edin: üst zon, NS'leriniz için ikinci bir sorgu olmadan A/AAAA veriyor mu?
dig yourdomain.com NS +additional

# Sakat delegasyonu tespit edin: listelenen her NS'i doğrudan sorgulayın, hepsi yetkili yanıt vermeli
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +norecurse; done

Üst taraftaki NS ile sizin tarafınızdaki NS arasında uyuşmazlık, veya yetkili yanıt vermeyen herhangi bir ad sunucusu, izlenmesi gereken sakat delegasyon işaretidir.

Ek Notlar (Role Özel)

Sysadmin: BIND'i kendiniz çalıştırıyorsanız, named-checkzone bunların çoğunu yayına almadan önce yakalar — bunu bir sorun sonrası incelemesi değil, ön kontrol olarak kullanın.
DevOps: çoklu sağlayıcı DNS (örneğin Route53 + yedek olarak Cloudflare) her iki tarafta byte-byte aynı NS kümesini gerektirir — deploy öncesi sağlayıcılar arasında dig NS çıktısını karşılaştıran bir CI kontrolü, sapmayı müşterilerden önce yakalar.
Security-adjacent: eskimiş/kaldırılmış ama hâlâ delegasyonda görünen bir NS adını kaydettirebilen bir saldırgan, delege edilen trafiği ele geçirebilir — NODA'nın sahipsiz kalmış ama hâlâ delegede olan NS kayıtlarını kozmetik değil Critical olarak işaretlemesinin nedeni tam olarak budur.

← Derse Dön 2

Ders 3

Zon Mekaniği

Alıştırma Hedefi

SOA serial semantiğini anlayın, bir zon aktarımını (AXFR) zorlayıp doğrulayın ve yedek sunucuların senkron kaldığını onaylayın.

Neden Önemli

Eski veya artmayan bir serial, yedek senkronizasyonunu sessizce bozar — yedekler hiçbir şeyin değişmediğini düşünür ve eski veriyi süresiz sunmaya devam eder. Bu, bir denetime (veya kızgın bir müşteriye) kadar fark edilmesi zor, sessiz bir arıza türüdür.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Mevcut SOA serial + zamanlayıcıları okuyun
dig yourdomain.com SOA +short

# Serial'ı primary ve her secondary'de karşılaştırın — her değişiklikten sonra eşleşmeli
for ns in $(dig +short yourdomain.com NS); do echo "== $ns =="; dig @$ns yourdomain.com SOA +short; done

# Zon aktarımı denemesi (yalnızca yetkili bir secondary IP'den BAŞARILI, diğerlerinden BAŞARISIZ olmalı)
dig axfr yourdomain.com @ns1.yourdnsprovider.com

# Laboratuvar sunucunuzdan (AXFR doğru kilitlenmişse reddedilmeli):
dig axfr yourdomain.com @ns1.yourdnsprovider.com

Küçük bir kayıt değişikliği yapın, sağlayıcınızın kuralına göre serial'ı artırın (yaygın olanı YYYYMMDDnn), ve tüm secondary'ler eşleşene kadar karşılaştırmayı tekrarlayın.

Ek Notlar (Role Özel)

Sysadmin: rastgele bir IP'den başarılı olan bir AXFR, gerçek ve yaygın bir yanlış yapılandırmadır — laboratuvar sunucunuzdan başarılı bir aktarımı bir kolaylık değil, düzeltilmesi gereken bir bulgu olarak ele alın.
DevOps: zon verisi kod olarak yönetiliyorsa (Terraform/IaC), serial artırma pipeline'ın otomatikleştirilmiş bir parçası olmalıdır — insan tarafından elle tutulan bir serial ER YA DA GEÇ unutulacaktır.
Security-adjacent: bu, NODA'nın "AXFR / Zone Transfer" Check'inin (CAT-SEC) tam olarak kontrol ettiği şeydir — açık bir zon aktarımı, saldırgana tüm DNS ayak izinizi tek sorguda verir, keşif için kullanışlı iç-görünümlü ana bilgisayar adları dahil.

← Derse Dön 3

Ders 4

Temel Dışındaki Kayıt Türleri

Alıştırma Hedefi

A/AAAA, CNAME birlikte var olma sınır durumları, MX, TXT, SRV ve CAA kayıtlarını doğru şekilde oluşturup doğrulayın.

Neden Önemli

Çoğu yönetici A/MX/TXT'yi bilir; CAA ve CNAME birlikte var olma kuralı "usta seviye"nin tam olarak başladığı yerdir — CAA özellikle en yeni geniş çapta önemli kayıt türüdür ve domaininiz için kimin TLS sertifikası verebileceğini tamamen belirler.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Temel adres kayıtları
dig yourdomain.com A
dig yourdomain.com AAAA

# CNAME birlikte var olma kuralı kontrolü — bu isimde TEK kayıt CNAME olmalı
dig www.yourdomain.com CNAME
dig www.yourdomain.com ANY    # bu isimde başka hiçbir şey görünmemeli

# MX
dig yourdomain.com MX +short

# SRV (örnek: bir servis kendini DNS üzerinden duyuruyor)
dig _sip._tcp.yourdomain.com SRV

# CAA — bu domain için sertifika vermeye kim yetkili
dig yourdomain.com CAA +short

Sertifika vermeyi tek bir CA ile sınırlayan bir CAA kaydı ekleyin (örn. 0 issue "letsencrypt.org"), ardından dig ile görünür olduğunu doğrulayın — ve CAA'nın tarayıcılar tarafından bağlantı anında değil, CA tarafından sertifika verilirken kontrol edildiğini unutmayın.

Ek Notlar (Role Özel)

Sysadmin: bir CNAME'in yanlışlıkla aynı isimdeki başka bir kayıtla birlikte var olması, RFC kuralını istemci tarafında doğrulamayan kontrol paneli editörlerinde klasik bir yanlış yapılandırmadır — CNAME ekledikten sonra her zaman dig ANY ile doğrulayın.
DevOps: SRV kayıtları, servis keşfinin yoğun kullanıldığı ortamlarda (SIP, XMPP, bazı Kubernetes ingress kalıpları) daha önemlidir — yığınınız DNS üzerinden servis keşfi kullanmıyorsa bu kayıt türü basitçe uygulanamayabilir; gerçek bir kullanım alanı olmayan bir alıştırmayı zorlamayın.
Security-adjacent: iodef etiketi olmayan bir CAA, yetkisiz sertifika verme girişiminden haberdar olmayacağınız anlamına gelir — daha eksiksiz bir yapılandırma için ekleyin (0 iodef "mailto:security@yourdomain.com").

← Derse Dön 4

Ders 5

DNSSEC I: Güven Zinciri

Alıştırma Hedefi

Bir zonu imzalayın, üst zonda DS kaydının belirmesini gözlemleyin ve ortaya çıkan güven zincirini uçtan uca doğrulayın.

Neden Önemli

Bu, tüm sektörde en çok alıntılanan "en iyi uygulama boşluğudur" (NODA'nın kendi araştırmalarına bakın) — çoğu operatör ya hiç etkinleştirmez ya da bir kez etkinleştirip zincirin gerçekten doğrulandığını hiç kontrol etmez. Kendi DS kaydınızın belirdiğini görmek, kursun en iyi öğrenme anıdır.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# İmzalamadan önce: henüz DNSKEY olmadığını doğrulayın
dig yourdomain.com DNSKEY +short

# Sağlayıcı panelinden DNSSEC'i etkinleştirin (Cloudflare/Route53/çoğu modern sağlayıcıda tek tıkla), ardından:
dig yourdomain.com DNSKEY +short
dig yourdomain.com DS +short          # ÜST ZONDAN sorgulanır

# Tam zincir doğrulaması (doğrulayan bir çözümleyici gerektirir)
delv yourdomain.com A                 # delv "fully validated" der veya zincirin tam olarak nerede koptuğunu gösterir

# Herkese açık, doğrulayan bir çözümleyicinin de aynı fikirde olduğunu doğrulayın
dig @1.1.1.1 yourdomain.com A +dnssec +cd    # AD bayrağının varlığı = doğrulandı

delv (BIND ile birlikte gelir) bunun için en doğrudan araçtır — sadece "DNSSEC açık mı" diye bakmaz, gerçek güven zincirini izler.

Ek Notlar (Role Özel)

Sysadmin: BIND'i kendiniz barındırıyorsanız, named-checkzone ve dnssec-verify yayın sonrası değil, yayın öncesi bir kontrol olarak çalışmalıdır.
DevOps: üst zonda DS kaydı yayınlama, zon imzalama otomatikleştirilmiş olsa bile çoğu kayıt firmasında genellikle manuel veya yarı manuel bir adım olarak kalır — bu, pipeline'ın çoğu kayıt firmasında tam otomasyona direnen tek parçasıdır; bunu runbook'larda açıkça belgeleyin.
Security-adjacent: herkese açık bir çözümleyiciden gelen AD bayrağı gerekli ama yeterli değildir — zinciri güvenilir saymadan önce her zaman delv veya ikinci bağımsız bir doğrulayıcı (örn. dnsviz.net) ile çapraz kontrol edin, çünkü yanlış yapılandırılmış bir çözümleyici yanlışlıkla doğrulama bildirebilir.

← Derse Dön 5

Ders 6

DNSSEC II: İşletim ve Arıza Modları

Alıştırma Hedefi

Bir anahtar rotasyonu gerçekleştirin ve gerçek dünya arıza imzalarını tanımak için DNSSEC'i kasıtlı olarak bozun.

Neden Önemli

DNSSEC dağıtımları neredeyse yalnızca işletim anlarında bozulur — anahtar rotasyonları, algoritma değişiklikleri — ilk kurulumda değil. Bu, "açtım" ile "işletebiliyorum" arasındaki boşluktur ve gerçek dünyadaki DNSSEC kesintilerinin çoğu tam olarak burada gerçekleşir.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Temel: mevcut doğrulamanın temiz olduğunu onaylayın
delv yourdomain.com A

# Sağlayıcı panelinden anahtar rotasyonunu başlatın, ardından geçişi izleyin:
dig yourdomain.com DNSKEY +short      # rotasyon örtüşmesi sırasında iki anahtarın bulunmasını izleyin
dig yourdomain.com DS +short          # DS'nin üst zonda YENİ DNSKEY canlıya alındıktan SONRA güncellendiğini doğrulayın, önce değil

# Kasıtlı olarak bozun (yalnızca laboratuvar domaininde — asla üretim zonunda):
# örn. DS kaydını rotasyona uğramış bir anahtara göre eski bırakın, veya sağlayıcı ham kayıt düzenlemeye izin veriyorsa bir imzayı elle bozun
dig yourdomain.com A +dnssec          # doğrulayan bir çözümleyicide SERVFAIL ve tam hatayı gözlemleyin
delv yourdomain.com A                 # delv tam olarak hangi zincir halkasının başarısız olduğunu gösterecektir

Amaç, doğrulayan bir çözümleyiciden gelen SERVFAIL kalıbını (genellikle son kullanıcıların "X domaini çalışmıyor" dediği şey) tanımak ve tahmin etmek yerine delv ile tam olarak hangi bağlantının bozuk olduğunu izlemektir.

Ek Notlar (Role Özel)

Sysadmin: sağlayıcınızın rotasyon otomasyonunu (Cloudflare/Route53 zamanlanmış otomatik rotasyon) mu yoksa manuel rotasyon mu kullandığını bilin — DS-önce-DNSKEY sıra hatası gerçek dünyada tam olarak manuel rotasyonda yaşanır.
DevOps: DS kayıtları kod olarak yönetiliyorsa, rotasyon İKİ ADIMLI bir deploy OLMALIDIR (yeni DNSKEY'i yayınla, yayılma + eski TTL süresini bekle, SONRA DS'i güncelle) — ikisini birden yapan tek bir atomik IaC apply, en yaygın kendi kendine verilen DNSSEC arızasıdır.
Security-adjacent: RFC 8624 algoritma seçimini yönetir — bir algoritma değişikliğini test ediyorsanız (sadece anahtar rotasyonu değil), geçiş yapmadan önce kayıt firmanızın/üst zonun yeni algoritmayı DS kayıtlarında gerçekten desteklediğini doğrulayın; hepsi desteklemez.

← Derse Dön 6

Ders 7

Saldırı Yüzeyi Olarak DNS

Alıştırma Hedefi

Kendi altyapınızı açık çözümleyici davranışı ve cache poisoning'e yakın yanlış yapılandırmalar açısından test edin.

Neden Önemli

Kontrolünüzdeki altyapı üzerinde açık bir çözümleyici, üçüncü bir tarafa karşı reflection/amplification DDoS saldırısında fark edilmeden silahlandırılabilir — istemeden bir katılımcı olursunuz ve bu tamamen tek bir yapılandırma kontrolüyle önlenebilir.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# SİZİN ad sunucunuzun rastgele isteklerden gelen özyinelemeli sorgulara yanıt verip vermediğini test edin (yetkili-only bir sunucu için VERMEMELİ)
dig @your-lab-box-ip google.com A         # sunucunun kendisi DIŞINDA bir makineden

# Yetkili-only bir sunucuda özyinelemenin kapalı olduğunu doğrulayın (BIND örneği)
grep -i recursion /etc/bind/named.conf.options    # "recursion no;" göstermeli

# Domaininizin ANY sorguları yoluyla bir yansıma amplifikatörü olarak kullanılmaya açık olmadığını kontrol edin
dig yourdomain.com ANY @ns1.yourdnsprovider.com +norecurse

# Temel yanıt boyutu kontrolü — daha büyük yanıtlar = kötüye kullanılırsa daha büyük amplifikasyon faktörü
dig yourdomain.com ANY +norecurse | wc -c

adım, sunucunuzu sorgulamaya yetkili olmayan bir makineden gerçek bir yanıt döndürüyorsa, özyineleme açıktır ve derhal düzeltilmesi gerekir — bu, NODA'nın CAT-SEC altında çalıştırdığı tam olarak Open Recursor Check'tir.

Ek Notlar (Role Özel)

Sysadmin: recursion no; (BIND) veya Unbound/PowerDNS'teki eşdeğer erişim kontrol listesi düzeltmedir — dış bir bakış noktasından (Seçenek A kullanıyorsanız AWS sunucunuz) doğrulayın, sadece localhost'tan değil, çünkü localhost testleri dış erişilebilirliği ortaya çıkarmaz.
DevOps: ad sunucuları bir yük dengeleyici/güvenlik duvarı arkasındaysa, ACL'nin sadece ağ katmanında değil, DNS sunucusunun kendisinde uygulandığını doğrulayın — sorun giderme sırasında yanlışlıkla açılan bir güvenlik duvarı kuralı, açık bir çözümleyiciyi önleyen tek şey olmamalıdır.
Security-adjacent: RFC 5358 (tavsiye niteliğinde, NODA'nın kendi Metodolojisinin 10. bölümüne göre MUST/SHALL kaynağı değil) buradaki kanonik referanstır — düzeltme notlarında ona atıfta bulunun, ancak katı bir uyumluluk gerekliliği olarak ele almayın.

← Derse Dön 7

Ders 8

SPF Detaylı

Alıştırma Hedefi

Doğru bir SPF kaydı oluşturun, 10 sorgu limitini kasıtlı olarak aşın ve ortaya çıkan arızayı tanıyın.

Neden Önemli

SPF'nin 10 DNS sorgusu sınırı (RFC 7208 §4.6.4), en yaygın gerçek dünya SPF arızasıdır — kayıtlar hizmetler eklendikçe organik olarak büyür, fark edilmeden sınırı aşar ve SPF herkes için permerror vermeye başlar, çoğu zaman aylarca fark edilmez.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Mevcut SPF kaydınızı okuyun
dig yourdomain.com TXT +short | grep spf1

# Sorguları manuel sayın — bu mekanizmaların her biri 1 sorguya mal olur: include, a, mx, ptr, exists, redirect
# (bunun için tek bir dig komutu yok — kaydı terim terim inceleyin)

# Gerçek bir SPF doğrulayıcı ile test edin (MarinaDNS'in kendi /mailauth aracı tam olarak bunu yapar)
# veya her bir 'include:' hedefini manuel olarak çözüp iç içe include'ları sayın

# Limit aşımını simüle edin: 10'u aşacak kadar include: mekanizması ekleyin, ardından permerror kontrol edin
# gerçek bir gönderim testi (mail-tester.com veya benzeri) veya özel bir SPF sorgu sayacı aracıyla

Bir include:'ı çözülmüş IP aralıklarıyla doğrudan değiştirerek (bakım maliyetini kabul ederek) "düzleştirme" yoluyla veya kullanılmayan include'ları kaldırarak düzeltin — hizmet eklendikçe sayının 10'un altında kalacağını ummayın.

Ek Notlar (Role Özel)

Sysadmin: eklenen her üçüncü taraf hizmet (e-posta pazarlaması, yardım masası, CRM) genellikle "sizin adınıza" gönderim yapmak için bir SPF include ister — bunları bir değişiklik günlüğünde takip edin, çünkü 2 yıl sonra limit aşıldığında kimse hepsini hatırlamaz.
DevOps: SPF kod olarak yönetiliyorsa, birleştirmeden önce sorgu sayısını kontrol eden bir CI lint adımı ucuz bir sigortadır — NODA'nın kendi SPF Lookup Limit Check'i (CAT-MAIL) tam olarak bunu otomatikleştirir.
Security-adjacent: hiç posta göndermeyen bir domain yine de v=spf1 -all (sıfır politika) yayınlamalıdır — RFC 7208 §10.1 bunu açıkça önerir ve NODA bu kontrolü tam da bu nedenle koşulsuz olarak değerlendirir (Metodoloji Bölüm 6.3).

← Derse Dön 8

Ders 9

DKIM Detaylı

Alıştırma Hedefi

Bir DKIM anahtar çifti üretin, selektör kaydını yayınlayın ve gerçek imzalı bir mesajın doğrulandığını kontrol edin.

Neden Önemli

DKIM selektör isimleri standartlaştırılmamıştır (RFC 6376) — SPF/DMARC'ın aksine kontrol edilecek sabit bir kayıt adı yoktur, bu da DKIM'i dıştan denetlemesi en zor, fark edilmeden yanlış yapılandırılması en kolay olan yapar.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Bir DKIM anahtar çifti üretin (OpenSSL örneği)
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Genel anahtarı şu adreste bir TXT kaydı olarak yayınlayın: selector._domainkey.yourdomain.com
dig selector._domainkey.yourdomain.com TXT +short

# Bu anahtarla imzalamak üzere yapılandırılmış bir sağlayıcı üzerinden gerçek bir test e-postası gönderin, ardından başlıkları inceleyin:
# DKIM-Signature: başlığını bulun, 's=' (selektör) ve 'd=' (domain) etiketlerini not edin

# İmzanın yayınlanan anahtara göre doğrulandığını kontrol edin
dig $(echo "your-selector")._domainkey.yourdomain.com TXT +short
# manuel olarak veya bir doğrulayıcı ile (opendkim-testkey, mail-tester.com) çapraz kontrol edin

Gerçek DKIM-Signature başlığındaki selektör adının yayınlananla tam olarak eşleştiğini doğrulayın — bu, en yaygın DKIM yanlış yapılandırmasıdır.

Ek Notlar (Role Özel)

Sysadmin: DKIM anahtarlarını periyodik olarak rotasyona sokun (yılda bir makul bir temeldir) — yeni selektörü eskisiyle birlikte yayınlayın, gönderimi geçirin, SONRA eski selektör kaydını kaldırın; Ders 6'daki DNSSEC rotasyon kalıbını yansıtır.
DevOps: bir işlemsel e-posta sağlayıcısı kullanıyorsanız (SendGrid, Postmark vb.), özel anahtarı onlar yönetir ve size sadece yayınlanacak DNS kaydını verirler — işiniz üretim değil doğrulamadır; bu kurulumda openssl'i kendinizin çalıştırması gerektiğini varsaymayın.
Security-adjacent: NODA'nın kendi Metodolojisine göre (Bölüm 6.3), tahmin edilen bir selektörde anahtar bulunamayan bir DKIM kontrolü, kesin bir Fail değil Informational olarak çözülür — yaygın bir selektör adında imza bulunamaması, DKIM'in kesin olarak olmadığı anlamına gelmez, çünkü selektör adları keyfidir.

← Derse Dön 9

Ders 10

DMARC Detaylı

Alıştırma Hedefi

DMARC'ı tam politika ilerlemesiyle (none → quarantine → reject) uygulayın ve gerçek bir toplu (RUA) raporu okuyun.

Neden Önemli

p=none raporlarını önce gözlemlemeden doğrudan p=reject'e geçmek, kendi meşru postanızı (unutulmuş bir üçüncü taraf gönderici, bir CRM, dahili bir araç) engelleme riski taşır — kademeli geçiş, tam olarak bu tür boşlukları bir kesinti haline gelmeden önce ortaya çıkarıp düzeltmek için vardır.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Mevcut DMARC kaydını okuyun
dig _dmarc.yourdomain.com TXT +short

# İzleme-only modunda başlayın:
# v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

# 1-2 hafta gerçek posta trafiğinden sonra toplu RUA raporunu inceleyin (XML eki olarak gelir)
# Şunlara bakın: tanımadığınız kaynak IP'ler, meşru olarak TANIDIĞINIZ postada SPF/DKIM hizalama hataları

# Raporlar temizlendikten sonra politikayı ilerletin:
# v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com
# ... ardından sonunda:
# v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

# Her aşamanın canlıda olduğunu doğrulayın
dig _dmarc.yourdomain.com TXT +short

Tüm domaini tek seferde reject'e çevirmek yerine kademeli artırmak için pct= kullanın (örn. 25/50/100) — bu, en güvenli gerçek dünya devreye alma yöntemidir.

Ek Notlar (Role Özel)

Sysadmin: RUA raporları gzip'li XML olarak gelir — hacim günde birkaç e-postayı aştığında bir ayrıştırıcı (birçok ücretsiz seçenek var, veya hızlı bir script yazın) buna değer; ham XML'i elle okumak ölçeklenmez.
DevOps: posta birden fazla pipeline'dan gönderiliyorsa (uygulama işlemsel postası, pazarlama platformu, destek masası), her biri SPF veya DKIM hizalamasını bağımsız olarak geçmelidir — DMARC arızaları genellikle domain genelinde bir yanlış yapılandırmayı değil, tam olarak unutulmuş tek bir pipeline'ı işaret eder.
Security-adjacent: DMARC'ın gerçek değeri teslim edilebilirlik değil, sahtekarlık karşıtı korumadır — NODA'nın Metodolojisine göre (Bölüm 6.3), DMARC MX varlığından bağımsız olarak koşulsuz kalır, çünkü hiç posta göndermeyen bir domain sahtekarlık için daha da çekici bir hedeftir ve yine de yayınlanmış bir politikaya ihtiyaç duyar.

← Derse Dön 10

Ders 11

Ters DNS ve Posta İtibarı (Bitirme Dersi)

Alıştırma Hedefi

Doğru PTR kayıtları kurun, FCrDNS'i (Forward-Confirmed reverse DNS) doğrulayın ve kursun kapanış alıştırması olarak tam bir domain denetimi yapın.

Neden Önemli

Ters DNS, yaygın DNS sertifikasyonlarında en az ele alınan konudur — oysa çok önemli bir teslim edilebilirlik sinyalidir: birçok posta sunucusu, SPF/DKIM/DMARC doğruluğundan bağımsız olarak, PTR kaydı eksik veya uyuşmayan IP adreslerinden gelen postaları reddeder veya spam olarak işaretler.

Çalıştırılacak Komutlar / Doğrulanacak Ayarlar

# Ters arama: posta gönderen IP'niz hangi ana bilgisayar adına çözümleniyor?
dig -x your.mail.server.ip +short

# İleri doğrulama: bu ana bilgisayar adı aynı IP'ye geri mi çözümleniyor? (FCrDNS)
dig +short the-ptr-hostname.example.com A

# Tam kapanış alıştırması — önceki her dersin kontrolünü domaininizde tek seferde çalıştırın:
dig yourdomain.com A AAAA MX TXT NS SOA CAA +noall +answer
dig yourdomain.com DNSKEY DS +short
dig _dmarc.yourdomain.com TXT +short
dig selector._domainkey.yourdomain.com TXT +short
dig -x your.mail.server.ip +short

# Ya da en basiti: tüm domaini doğrudan NODA üzerinden çalıştırın
# https://noda.marinadns.io — aynı kontroller, tek birleşik rapor

Bitirme alıştırması kasıtlı olarak şudur: "kendi domaininizi öğrendiğiniz her şeyden geçirin, ardından NODA'dan geçirin ve manuel bulgularınızın eşleşip eşleşmediğine bakın."

Ek Notlar (Role Özel)

Sysadmin: PTR kayıtlarını IP bloğunu kontrol eden taraf belirler (genellikle hosting/bulut sağlayıcınız, DNS sağlayıcınız değil) — yaygın bir kafa karışıklığı noktası; genellikle ileri kayıtları yönettiğiniz aynı panelde PTR'yi düzeltemezsiniz.
DevOps: geçici bulut altyapısından (otomatik ölçeklenen sunucular, konteynerler) posta gönderiyorsanız, belirli bir IP'ye bağlı PTR kayıtları gerçek bir operasyonel kısıtlama haline gelir — özel, sabit bir giden IP (veya bir röle hizmeti) genellikle tam olarak PTR'nin geçici altyapıyı takip edememesi nedeniyle gereklidir.
Security-adjacent: FCrDNS uyuşmazlıkları spam filtrelerinin klasik bir sezgisel işaretidir — SPF/DKIM/DMARC mükemmel olsa bile, uyuşmayan veya eksik bir PTR teslim edilebilirliği yine de ciddi şekilde zedeleyebilir; bunu sonradan akla gelen bir ayrıntı değil, e-posta doğrulama üçlüsüyle birlikte dördüncü bir sütun olarak ele alın.

← Derse Dön 11