DNS ve isim çözümleme

DNS (Domain Name System, alan adı sistemi) altaykargo.example gibi bir adı makinenin kullandığı IP adresine çevirir. Sunucular 53 numaralı portta dinler. Sorgular çoğunlukla UDP ile gider, çünkü tek soru tek cevap hızlıdır. Cevap UDP'ye sığmazsa sunucu onu kesik diye işaretler, istemci de aynı soruyu TCP ile yeniden sorar.

RFC 7766 her DNS yazılımının TCP'yi de desteklemesini ister. Ad, noktayla ayrılmış etiketlerden oluşur ve sağdan sola okunur. www.altaykargo.example adında en sağda görünmez kök, sonra example, sonra altaykargo, en solda ise www gelir.

Çözümleme tek bir sunucuda bitmez, birkaçına yayılır. Bilgisayarındaki küçük istemci (stub resolver) soruyu özyinelemeli çözücüye iletir. Bu çözücü kurumun sunucusu, internet sağlayıcısının sunucusu ya da herkese açık bir DNS servisi olabilir.

Özyinelemeli çözücü işi senin adına baştan sona yürütür: gerekirse birden çok sunucuya sorar ve sonunda sana tek bir cevap döner. Sen yalnız soruyu sorar, arkadaki koşuşturmayı hiç görmezsin. Bu iş bölümü DNS'i hem hızlı hem ölçeklenebilir kılar.

Şemadaki zinciri soldan sağa izle. Özyinelemeli çözücü önce kök sunucuya sorar. Kök cevabı bilmez ama TLD sunucularının adresini verir, bu cevabın adı yönlendirmedir (referral). TLD sunucusu da alan adının yetkili ad sunucularını gösterir.

Yetkili sunucu kaydın gerçek sahibidir ve kesin cevabı yalnız o verir. Bu iş bölümünün iki adı vardır. İstemciyle çözücü arasındaki sorgu özyinelemelidir: bana kesin cevabı bul, ayrıntıyla sen uğraş der.

Çözücüyle kök, TLD ve yetkili sunucular arasındaki sorgular ise iteratiftir: her sunucu ya cevabı verir ya da bir sonraki durağı gösterir. Kök ve TLD sunucuları milyonlarca sorguyu ancak böyle kaldırır. Kök sistemi A'dan M'ye 13 harfle anılır, ama arkasında anycast ile dünyaya dağılmış iki binden fazla sunucu çalışır.

Zincir aslında senin makinende başlar. Linux, bir adı çözmeden önce /etc/nsswitch.conf dosyasındaki sıraya bakar. Varsayılan sıra önce files, sonra dns olduğu için ilk durak /etc/hosts dosyasıdır.

Orada yazan bir eşleşme DNS'e hiç sorulmadan kullanılır. Hangi çözücüye sorulacağını ise /etc/resolv.conf dosyasındaki nameserver satırı söyler. Windows'ta aynı dosya System32 altındaki drivers\etc\hosts yolundadır.

Hosts dosyası bu yüzden saldırganın da ilgisini çeker. Bir banka adını sahte adrese bağlayan tek satır, kullanıcıyı DNS'e hiç uğratmadan yanlış sunucuya götürür. Uç nokta izleme araçları bu dosyadaki değişikliği ayrıca kaydeder.

$ cat /etc/resolv.conf
nameserver 10.0.0.53
search altaykargo.example

$ grep altaykargo /etc/hosts
10.0.0.5   intranet.altaykargo.example

dig +trace komutu bu iteratif yolu senin için açık açık gösterir. Araç sorguyu kökten başlatır ve her durağın verdiği yönlendirmeyi izleyerek aşağı iner. Aşağıdaki çıktıda ilk satır kök sunucuların listesidir, dig işe onları öğrenerek başlar. İkinci satırda kök, example TLD'sinin sunucusunu gösterir.

Üçüncü satırda TLD, altaykargo.example alanının yetkili sunucusunu verir. Son satır ise yetkili sunucudan gelen A kaydıdır. Bir alan çözülmüyorsa +trace, zincirin hangi durakta koptuğunu ortaya koyar. Yanlış yapılandırma ararken ilk denediğin komutlardan biri bu yüzden budur.

$ dig +trace altaykargo.example

.                    518400 IN NS kok-sunucu.example.
example.             172800 IN NS ns.tld.example.
altaykargo.example.    3600 IN NS ns1.altaykargo.example.
altaykargo.example.    3600 IN A  203.0.113.40

Yetkili sunucular genelde çift çalışır. Birincil sunucu bölgenin asıl kopyasını tutar, ikincil sunucu ise onu bölge aktarımıyla (zone transfer) çeker. RFC 5936 bu aktarımı AXFR adıyla tanımlar.

Sık yapılan hata, aktarımı yalnız ikincil sunucuya değil herkese açık bırakmaktır. O zaman dig axfr komutunu koşan herkes bölgedeki bütün kayıtları tek seferde alır. İç sunucu adları, test ortamları ve yönetim panelleri bir anda görünür olur.

MITRE ATT&CK bu keşfi T1590.002 altında anar. Aşağıdaki örnekte aynı alanın iki sunucusu farklı davranıyor. Gerçek ağlarda da sık görülen bir durumdur: birincil sıkılaştırılmış, ikincil unutulmuştur.

$ dig axfr altaykargo.example @ns1.altaykargo.example
; Transfer failed.

$ dig axfr altaykargo.example @ns2.altaykargo.example
altaykargo.example.            3600 IN SOA ns1.altaykargo.example. hostmaster.altaykargo.example. 2026092801 7200 3600 1209600 3600
altaykargo.example.            3600 IN NS  ns1.altaykargo.example.
vpn.altaykargo.example.        3600 IN A   203.0.113.60
test-panel.altaykargo.example. 3600 IN A   10.20.0.44

ns2'nin verdiği listede vpn adresi ve iç ağdaki test paneli de görünüyor; saldırgan için hazır bir hedef listesidir. Önlem iki katmanlıdır. Birincisi, aktarımı yalnız ikincil sunucunun adresine açmaktır; BIND'da bunu allow-transfer seçeneği yapar. İkincisi, aktarımı TSIG anahtarıyla imzalamaktır, böylece adresi taklit eden biri de bölgeyi çekemez.

Tespit için yetkili sunucunun kayıtlarında beklenmeyen kaynaklardan gelen AXFR isteklerini ararsın. Kendi alanını dışarıdan dig axfr ile denemek en ucuz denetimdir. Bunu yalnız kendi alanında ya da yazılı iznin olan hedefte dene.

Her kayıt tipi farklı bir soruya cevap verir. A kaydı IPv4, AAAA kaydı IPv6 adresini verir. CNAME bir adı başka bir ada bağlar, yani takma ad kurar. RFC 1034'e göre CNAME olan bir düğümde başka kayıt bulunmaz.

Alan adının kökünde NS ve SOA kayıtları zorunlu olduğu için orada CNAME kullanamazsın. CNAME bir güvenlik tuzağı da taşır. Kapatılan bir bulut servisine işaret eden kayıt silinmezse, o servis adını başka biri alıp senin alt alan adında kendi içeriğini yayınlayabilir. Buna alt alan adı devralma (subdomain takeover) denir.

Önlem, servisi kapatırken ona işaret eden DNS kaydını da aynı gün silmektir. NS kaydı alanı yöneten yetkili ad sunucularını listeler. PTR ise ters yönde çalışır, IP adresinden ada gider ve çoğunlukla posta sunucularının doğrulamasında işe yarar.

Birkaç kayıt tipi daha altyapının iskeletini kurar. SOA (Start of Authority) kaydı alanın kökünde durur. İçindeki sayılar sırasıyla seri numarası, yenileme, yeniden deneme, sona erme ve olumsuz cevapların önbellek süresidir. İkincil sunucu seri numarası arttığında bölgeyi yeniden çeker.

CAA kaydı hangi sertifika sağlayıcısının bu alan için sertifika kesebileceğini sınırlar, örneğin issue etiketiyle. SRV kaydı bir servisin hangi sunucuda ve hangi portta olduğunu bildirir; dizin ve sohbet servisleri bunu sık kullanır. Bu kayıtları okuyarak bir kurumun altyapısını, hedefe hiç dokunmadan haritalayabilirsin.

MX kaydı, alana gelen postayı hangi sunucunun karşıladığını ve öncelik sırasını yazar. Satırdaki sayı önceliktir; düşük sayılı sunucu önce denenir, o cevap vermezse sıradaki devreye girer. Ama postayı kimin gönderebileceğini MX söylemez, o bambaşka bir sorudur. Gönderme yetkisi TXT kaydındaki SPF satırında durur.

TXT kaydı serbest metin tutar ve tek bir amaca bağlı değildir. SPF, DKIM ve DMARC ayarlarının hepsi birer TXT kaydı olarak yayımlanır. Bir alanın posta güvenliğini incelerken bu yüzden önce onun TXT kayıtlarını okur, hem gönderme yetkisini hem doğrulama politikasını oradan çıkarırsın.

$ dig A altaykargo.example +short
203.0.113.40
$ dig MX altaykargo.example +short
10 posta.altaykargo.example.
$ dig -x 203.0.113.40 +short
sunucu.altaykargo.example.
$ dig SOA altaykargo.example +short
ns1.altaykargo.example. hostmaster.altaykargo.example. 2026092801 7200 3600 1209600 3600
$ dig TXT altaykargo.example +short
"v=spf1 ip4:203.0.113.25 -all"
$ dig TXT _dmarc.altaykargo.example +short
"v=DMARC1; p=reject; rua=mailto:[email protected]"

Son iki satır posta güvenliğinin çekirdeğidir. v=spf1 ip4:203.0.113.25 -all satırı, yalnız 203.0.113.25 adresinin bu alan adına posta gönderebileceğini söyler. Sondaki -all, listede olmayan her göndereni kesin olarak yetkisiz sayar ve alıcı sunucu böyle bir postayı çoğu zaman reddeder. Daha yumuşak olan ~all ise muhtemelen yetkisiz ama sertçe reddetme anlamına gelir.

RFC 7208 SPF'in sorgu sırasında en çok 10 DNS araması yapabileceğini sınırlar; bu sayıyı aşan kayıt hata verir. _dmarc altındaki kayıt ise politikayı söyler. p=reject, doğrulamadan geçemeyen postanın reddedilmesini ister.

dig komutunda önce kayıt tipini, sonra adı yazarsın. Tip yazmazsan dig varsayılan olarak A kaydını sorar. +short yalnız cevabı basar, başlık ve açıklama satırlarını atar; bu yüzden bir betiğin içinde işlemesi kolaydır. Belirli bir sunucuya sormak için @ kullanırsın, örneğin dig @192.0.2.53 altaykargo.example, ve böylece bir çözücünün kendi cevabını başkasınınkiyle karşılaştırırsın.

Ters çözümleme için -x bayrağını IP adresiyle verirsin. Sorun ararken ise +short'u bırakır, tam çıktıyı okursun.

$ dig altaykargo.example A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41325
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;altaykargo.example.          IN      A

;; ANSWER SECTION:
altaykargo.example.   3517    IN      A       203.0.113.40

;; Query time: 1 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)

Çıktıyı bölüm bölüm oku. status alanı sorgunun sonucunu verir. NOERROR cevabın bulunduğunu, NXDOMAIN adın hiç olmadığını, SERVFAIL ise çözücünün geçerli bir cevap üretemediğini söyler.

flags satırında qr bunun bir cevap olduğunu, rd özyineleme istendiğini, ra ise çözücünün özyinelemeyi desteklediğini gösterir. aa bayrağı yoksa cevap yetkili sunucudan değil, çözücüden gelmiştir. Cevap satırındaki 3517 kalan TTL süresidir.

Kayıt 3600 ile gelmiş, 83 saniyedir önbellekte bekliyordur. Query time değerinin 1 milisaniye olması da cevabın önbellekten geldiğini doğrular. SERVER satırı ise hangi çözücünün, hangi protokolle cevap verdiğini yazar.

Çözücü aldığı cevabı bir süre saklar, yani önbelleğe alır. Saklama süresini kaydın TTL (Time To Live) değeri belirler ve süre saniye cinsindendir. TTL 3600 ise cevap bir saat önbellekte kalır ve o süre boyunca aynı soru yeniden yetkili sunucuya gitmez.

RFC 2308 olmayan adın cevabını, yani NXDOMAIN'i de önbelleğe alır ve süresini alanın SOA kaydından çıkarır. Önbellek DNS'i hızlandırır ama bir kaydı değiştirdiğinde eski cevabın bir süre daha dolaşmasına da yol açar.

DNS varsayılan olarak şifresizdir, aradaki ağ bütün sorguları okuyabilir. Kafede aynı Wi-Fi ağındaki biri, senin hangi sitelere girdiğini sorgulardan çıkarabilir. İki standart bunu düzeltir. DoT (DNS over TLS) sorguyu TLS içinde 853 portundan taşır.

DoH (DNS over HTTPS) ise sorguyu HTTPS içinde 443 portundan, sıradan web trafiğine benzeterek taşır. dig ile ikisini de denersin: +tls DoT'u, +https ise DoH'u açar. Şifreli kanal sorgunun içeriğini gizler ama hangi çözücüye bağlandığını yine de saklamaz.

$ dig +tls @192.0.2.53 altaykargo.example +short
203.0.113.40
$ dig +https @192.0.2.53 altaykargo.example +short
203.0.113.40

Açık kalan DNS kanalı kötüye de kullanılır. Saldırgan komutu ve veriyi DNS sorgularının içine gizleyebilir; MITRE ATT&CK bunu T1071.004 tekniğiyle izler. Bu davranışın adı DNS tünelidir.

Tespitte dört işarete bakarsın: olağan dışı uzun ve anlamsız etiketler, aynı üst alan altında çok sayıda benzersiz ad, yoğun TXT sorgusu ve tek istemciden gelen yüksek hacim. Normal kullanıcı aynı birkaç adı tekrar tekrar sorar. Aşağıdaki çözücü kaydında 10.0.0.23 adresi, saniyede birkaç kez aynı üst alana her seferinde yeni bir ad soruyor.

10:21:04 10.0.0.23 TXT  a7f3b9c1d2e48f06b5.veri-yedek.example
10:21:04 10.0.0.23 TXT  9c02e7aa41f5d8b3c6.veri-yedek.example
10:21:05 10.0.0.41 A    www.altaykargo.example
10:21:05 10.0.0.23 TXT  4be1f0c97d2a6e8315.veri-yedek.example
10:21:06 10.0.0.23 TXT  e81d5a0b3f97c42d60.veri-yedek.example

Önlem olarak bütün istemcileri kurumun iç çözücüsüne yönlendirir, dışarıya doğrudan 53 çıkışını kapatır ve çözücü kayıtlarını izlersin. Şifreli DNS burada yeni bir kör nokta açar. Tarayıcı sorguyu 443 üzerinden doğrudan dış bir DoH çözücüsüne yollarsa, iç çözücü o sorguyu hiç görmez.

Kurumlar bu yüzden tarayıcıda DoH ayarını politikayla yönetir, 853 çıkışını kapatır ve bilinen genel DoH sunucularını çıkışta engeller. İç çözücünün kendisi ise dışarıya şifreli DNS ile sorabilir. Böylece hem gizlilik korunur hem de görünürlük kaybolmaz.