DNS kayıtları ve alt alan keşfi

Beyaz Vadi Lojistik'in güvenlik ekibi bir envanter çalışması başlattı. Elde yalnız ana alan adı var: beyazvadi.example. Ekip bu addan yola çıkıp kurumun internete açık bütün sistemlerini bulmak istiyor.

İlk durak DNS'tir. DNS, isimleri adreslere çeviren dağıtık bir defterdir ve defterin her satırı altyapı hakkında bir cümle söyler. Bir kayıt posta sunucusunu, başka biri bulut hizmetini, bir diğeri sertifika politikasını anlatır.

Alt alan adları ise en verimli keşif alanıdır; unutulmuş test sistemleri çoğu zaman oradadır. Bu derste kayıt tiplerini tek tek okur, alt alan listesini pasif ve aktif yoldan çıkarır, sonra listeyi doğrularsın. Son bölümlerde iki tehlikeli yapılandırmayı, sahipsiz CNAME'i ve açık bölge aktarımını ele alırsın.

DNS kayıt tipleri sınırlıdır ve her biri ayrı iş görür. A kaydı adı IPv4 adresine, AAAA kaydı IPv6 adresine bağlar. CNAME bir adı başka bir ada yönlendirir.

MX postayı karşılayan sunucuyu, NS yetkili ad sunucusunu, TXT ise serbest metni tutar. SPF satırı, DMARC politikası ve hizmet doğrulama dizeleri TXT içinde durur. Doğrulama dizeleri kurumun hangi bulut hizmetlerine kayıtlı olduğunu tek tek sayar.

SOA kaydı bölgenin kimlik kartıdır; seri numarasını ve yönetici adresini taşır. CAA hangi sertifika makamının sertifika verebileceğini söyler. SRV bir hizmetin hangi sunucuda ve hangi portta çalıştığını yazar. PTR ise ters yönde çalışır ve adresi bir ada çevirir.

$ dig A web01.beyazvadi.example +short
203.0.113.11
$ dig AAAA web01.beyazvadi.example +short
2001:db8:4b0::11
$ dig CNAME destek.beyazvadi.example +short
yardim-masasi.ornek-bulut.example.
$ dig MX beyazvadi.example +short
10 mx1.beyazvadi.example.
$ dig TXT beyazvadi.example +short
"v=spf1 ip4:203.0.113.0/24 include:_spf.ornek-posta.example -all"
"ornek-bulut-dogrulama=8f2a19"
$ dig TXT _dmarc.beyazvadi.example +short
"v=DMARC1; p=quarantine; rua=mailto:[email protected]"
$ dig SOA beyazvadi.example +short
ns1.ornek-dns.example. hostmaster.beyazvadi.example. 2026092801 7200 3600 1209600 300
$ dig CAA beyazvadi.example +short
0 issue "ornek-ca.example"
$ dig SRV _autodiscover._tcp.beyazvadi.example +short
0 0 443 posta.beyazvadi.example.

Çıktıları sırayla oku. web01 hem IPv4 hem IPv6 adresine sahiptir; iki adresi de envantere yazarsın. destek adı bir yardım masası hizmetine CNAME ile bağlıdır ve kurumun o hizmeti kullandığını ele verir. SPF satırı postanın yalnız 203.0.113.0/24 bloğundan ve bir dış posta hizmetinden çıkabileceğini söyler.

Sondaki -all, listede olmayan bir kaynaktan gelen postayı yetkisiz sayar. DMARC satırı politikayı quarantine, yani şüpheli iletiyi karantinaya al olarak koyar. SOA seri numarası çoğu kurumda tarih biçimindedir. 2026092801 değeri, bölgenin 28 Eylül 2026'da o günün ilk değişikliğini aldığını düşündürür.

hostmaster.beyazvadi.example, ilk noktası @ işaretine çevrilince yönetici posta adresidir. CAA yalnız ornek-ca.example makamına izin tanır. SRV kaydı posta istemcilerinin otomatik yapılandırma hizmetini gösterir.

Kayıtların yanında TTL değeri de okunur. TTL, çözücülerin o cevabı kaç saniye saklayacağını söyler. Uzun süre yüksek duran bir TTL birden düşerse yaklaşan bir taşımayı düşündürür, çünkü kurumlar taşıma öncesinde TTL'yi kısaltır.

CDN ve bulut hizmetleri ise TTL'yi zaten kısa tutar. Bir kısayol tuzağına da dikkat et. Eski rehberler bütün kayıtları tek seferde almak için dig ANY sorgusunu önerir.

Ocak 2019'da yayımlanan RFC 8482, yetkili sunuculara ANY sorgusuna kısa bir cevap verme yolunu açtı. Bugün pek çok sunucu ANY sorgusuna tek bir kayıt ya da yalnız bir HINFO satırı döndürür. ANY çıktısı eksik geldiği için tipleri tek tek sorgularsın. Boş bir ANY cevabı kaydın olmadığı anlamına gelmez.

Alt alan keşfi iki yoldan yürür. Pasif yolda başkalarının daha önce topladığı kayıtları okursun. Sertifika şeffaflık günlükleri, pasif DNS veritabanları, arama motoru dizinleri ve internet arşivi bu kaynakların başındadır. Pasif DNS, çözücülerde görülen cevapları zaman damgasıyla saklar ve bir adın geçmişte hangi adreslere çözüldüğünü gösterir.

subfinder ve amass bu kaynakları birleştirir ve hedefe tek paket atmadan liste üretir. Bazı kaynaklar API anahtarı ister; anahtar eklenince liste belirgin biçimde uzar. Pasif yol sessizdir, ama geçmişe bakar. Listede bugün yaşamayan adlar da durur ve her ad sonradan doğrulanır.

Aktif yolda sözlük denersin. Sık kullanılan adları tek tek çözümlersin: test, dev, vpn, eski, yedek, panel. Cevap veren her ad yeni bir kapıdır. Bu adım pasif değildir, çünkü sorular hedefin ad sunucusuna kadar ulaşır.

Binlerce sorgu kısa sürede gider ve yetkili sunucunun günlüğünde belirgin bir iz bırakır. Bulunan adlara httpx gibi bir araçla HTTP isteği atmak da aynı gruba girer. Bu yüzden sözlük denemesi ve yoklama yalnız yazılı yetkiyle ve kapsam içinde yapılır.

Savunma tarafında aynı iz bir tespit fırsatıdır. Kısa sürede çok sayıda NXDOMAIN cevabı alan tek bir kaynak adres, alt alan taramasının tipik işaretidir.

Soruların neden hedefe ulaştığını çözümleme yolu açıklar. Bir tarayıcı web01.beyazvadi.example adını sorduğunda istek önce özyinelemeli çözücüye gider. Çözücü cevabı önbellekte bulamazsa kök sunucuya, oradan uzantı sunucusuna, en son alan adının yetkili ad sunucusuna sorar. Yetkili sunucu cevabı verir ve çözücü onu TTL süresi boyunca saklar.

Genel bir çözücüye sorduğun ad önbellekte varsa hedefin sunucusu senden haberdar olmaz. Önbellekte olmayan, yani yakın zamanda kimsenin sormadığı bir ad ise yetkili sunucuya kadar ulaşır. Sözlük denemesinde uydurduğun adların çoğu bu gruptadır. Yetkili sunucunun günlüğünde çözücünün adresi ve sorulan adlar birikir.

Liste çıkınca üç soru sorarsın. Ad hâlâ çözülüyor mu?

Hangi adrese gidiyor? O adres kuruma mı ait? İlk iki soruyu dnsx gibi bir araç toplu yanıtlar. subfinder çıktısını doğrudan dnsx'e bağlarsın ve araç her adı çözüp adresini yanına yazar.

Yanıt kodunu görmek istersen -rcode bayrağını kullanırsın. NOERROR adın var olduğunu, NXDOMAIN ise bulunamadığını söyler. İki listeyi yan yana koymak envanterdeki ölü kayıtları da ortaya çıkarır. Üçüncü soruyu bu modülün son dersinde, ağ bloğu ve ASN kaydıyla yanıtlarsın.

$ subfinder -d beyazvadi.example -silent | dnsx -silent -a -resp
web01.beyazvadi.example [203.0.113.11]
destek.beyazvadi.example [198.51.100.44]
vpn.beyazvadi.example [203.0.113.20]
eski-panel.beyazvadi.example [203.0.113.50]

$ subfinder -d beyazvadi.example -silent | dnsx -silent -rcode noerror,nxdomain
web01.beyazvadi.example [NOERROR]
destek.beyazvadi.example [NOERROR]
vpn.beyazvadi.example [NOERROR]
eski-panel.beyazvadi.example [NOERROR]
kampanya.beyazvadi.example [NXDOMAIN]
staging.beyazvadi.example [NXDOMAIN]

İlk komut adresleri, ikinci komut yanıt kodlarını verir. Üç ad 203.0.113.0/24 bloğuna düşer. Bu blok SPF kaydında da geçer, yani kurumun kendi bloğu olabilir. destek adı ise başka bir bloğa, yani yardım masası hizmetine gider.

staging adı NXDOMAIN döner ve silinmiş bir sistemden kalmış bir iz gibidir. kampanya adı ise dikkat ister. İlk listede adresi yoktur, ikinci listede NXDOMAIN görünür.

NXDOMAIN iki farklı durumu anlatabilir: ad hiç yoktur ya da ad bir CNAME taşır ama gösterdiği hedef yoktur. RFC 6604'e göre CNAME zincirinde yanıt kodu zincirin son adına aittir. İkinci durum sahipsiz kaydın ilk işaretidir ve bir sonraki bölümde onu açarsın.

Aktif denemede joker (wildcard) kayıt seni yanıltır. Joker kayıt, bir seviyedeki var olmayan her adı aynı adrese çözer. Beyaz Vadi Lojistik'in müşteri portalları musteri.beyazvadi.example altında çalışır ve orada *.musteri.beyazvadi.example kaydı vardır.

Ana bölgede joker yoktur, staging adının NXDOMAIN dönmesi bu yüzdendir. Ama musteri seviyesinde sözlük denemesi yapınca yüzlerce ad cevap verir ve liste şişer.

Tespit yolu basittir: kimsenin kullanmayacağı rastgele bir ad uydur ve sor. O ad da cevap veriyorsa ortada joker kayıt vardır. Sonra o adrese çözülen adları listeden ayıklarsın.

Ayıklamayı körü körüne yapma; joker adrese çözülen bir ad gerçekten var da olabilir. Böyle adları başka kanıtla, örneğin sertifika günlüğüyle ya da farklı bir HTTP cevabıyla ayırırsın. dnsx de -wd bayrağına verdiğin alan adında bu ayıklamayı kendisi yapar.

$ dig A x7k2q-yok.musteri.beyazvadi.example +short
203.0.113.99

$ dnsx -d musteri.beyazvadi.example -w kelimeler.txt -silent -a -resp
admin.musteri.beyazvadi.example [203.0.113.99]
kargo.musteri.beyazvadi.example [203.0.113.30]
test.musteri.beyazvadi.example [203.0.113.99]
yedek.musteri.beyazvadi.example [203.0.113.99]

Sahipsiz kayıt (dangling record) tehlikeli bir durumdur. Kurum bir kampanya sitesini bulut hizmetinde yayınlar. kampanya.beyazvadi.example adı CNAME ile beyazvadi-kampanya.ornek-bulut.example adına bağlanır.

Kampanya biter, ekip bulut kaynağını siler ama DNS kaydını unutur. Kayıt artık var olmayan bir hedefe bakar.

Bulut hizmeti kaynak adlarını ilk gelene veriyorsa başka biri aynı adla yeni bir kaynak açabilir. O andan sonra kurumun alt alan adı yabancı birinin içeriğini sunar. Sonuç ağırdır: kurum adına oltalama sayfası, üst alana yazılmış çerezleri okuma ihtimali ve kurum adına geçerli sertifika alınması. OWASP Web Güvenliği Test Rehberi bu testi WSTG-CONF-10 adıyla tanımlar.

$ dig CNAME kampanya.beyazvadi.example +short
beyazvadi-kampanya.ornek-bulut.example.

$ dig A beyazvadi-kampanya.ornek-bulut.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40211

İlk komut kaydın hâlâ durduğunu gösterir. İkinci komut hedefi sorar ve status alanında NXDOMAIN görürsün; hedef ad artık yoktur. Bazı hizmetlerde hedef ad çözülmeye devam eder, ama hizmet kaynak bulunamadı gibi bir hata sayfası döndürür. can-i-take-over-xyz adlı açık proje, hangi hizmette hangi hata metninin ele geçirmeye açık bir durumu gösterdiğini parmak izi olarak listeler.

Doğrulamanın sınırı nettir. Bu kontrolü yalnız kendi alan adında ya da yazılı yetkiyle yaparsın. Kaynağı kendin açıp adı sahiplenmek test değildir, yetkisiz erişimdir. Bulguyu raporlamak için CNAME kaydı, NXDOMAIN cevabı ve hizmetin hata metni yeterlidir.

Savunma bir sıra kuralıyla başlar: önce DNS kaydını sil, sonra bulut kaynağını. Tersi arada bir ele geçirme penceresi açar. İkinci kural envanterdir. Her CNAME hedefinin sahibi ve amacı bir tabloda durur.

Üçüncü kural düzenli taramadır. Ayda bir bütün CNAME hedeflerini çözer, NXDOMAIN ya da bilinen hata metni dönenleri alarm olarak işaretlersin. Aynı mantık NS kayıtları için de geçerlidir.

Bir alt alanı yöneten ad sunucusu süresi dolmuş bir alan adındaysa, o adı satın alan kişi alt alanın bütün kayıtlarını yönetir. Bu tabloyu düzenli tutan ekip ele geçirme riskini büyük ölçüde kapatır.

$ dig destek.beyazvadi.example +short
yardim-masasi.ornek-bulut.example.
198.51.100.44

Bölge aktarımı (zone transfer), bir alan adının bütün kayıtlarını birincil sunucudan ikincil sunucuya kopyalamak için vardır. RFC 5936 bu işi AXFR sorgu tipiyle tanımlar. Yanlış yapılandırılmış bir ad sunucusu bölge dosyasını isteyen herkese verir. Dosyada alan adına ait her kayıt durur: iç sistem adları, test sunucuları, posta altyapısı.

Bugün çoğu sunucuda aktarım kapalıdır, ama eski ve bakımsız sistemlerde açık kalanı hâlâ çıkar. İstek doğrudan hedefin ad sunucusuna gider ve aktif bir adımdır. Bu yüzden yalnız kendi alan adında ya da yetkili testte denenir. Güvenli bir sunucunun beklenen cevabı aşağıdaki gibidir.

$ dig AXFR beyazvadi.example @ns1.ornek-dns.example

; <<>> DiG 9.18.28 <<>> AXFR beyazvadi.example @ns1.ornek-dns.example
;; global options: +cmd
; Transfer failed.

Transfer failed satırı sunucunun aktarımı reddettiğini söyler ve istenen sonuç budur. Savunma tarafında kontrol listesi kısadır. Bölge aktarımını yalnız ikincil sunucuların adresleriyle sınırla, mümkünse TSIG anahtarıyla imzala. Alt alan kayıtlarını düzenli tara ve kullanılmayanları sil.

CAA kaydı ekle, böylece yalnız seçtiğin makamlar sertifika verir. Yetkili sunucunun günlüğünde AXFR denemelerini ve kısa sürede gelen yoğun NXDOMAIN cevaplarını izle; ikisi de keşif belirtisidir. Bu adımların hiçbiri pahalı değildir. Bir öğleden sonra, kurumun DNS yüzeyinin büyük bölümünü temizlemeye yeter.