DNS, SRV kayıtları ve DC Locator: İstemci doğru DC’yi nasıl bulur? Sites ve subnets.

1. Core Mechanism / Temel mekanizma

İstemcideki Netlogon service, onun içindeki DsGetDcName Locator API'si, DNS resolver, DNS'teki locator (SRV/A) kayıtları ve yanıt veren domain controller'lar arasındaki keşif zinciri. Bu ders yalnız 'istemci hangi DC'yi seçer ve neden' sorusunu ele alır; secure channel kurulumunu 04.02'ye, Kerberos bilet alışverişini 06 bölümüne bırakır. Site topolojisinin replikasyon tarafı bu dersin kapsamı dışındadır.

Arabirimler ve belirtimler

• DsGetDcName (NetApi32.dll): istemcideki uygulamanın DC istemek için çağırdığı Win32 Locator API'si; istek yerel Netlogon service'e RPC ile gider.
• Netlogon service: DsGetDcName'i uygular, DNS sorgusunu yapar, LDAP UDP ping gönderir ve bulunan DC'yi cache'ler.
• DNS SRV kaydı: _<service>._<protocol>.<DnsDomainName> biçiminde DC yeteneklerini (LDAP, Kerberos, PDC, Global Catalog) ilan eder.
• Site'a özgü SRV kaydı: _<service>._<protocol>.<SiteName>._sites... biçimiyle istemcinin kendi site'ındaki DC'leri ayırır.
• LDAP UDP ping: aday DC'lere gönderilen datagram; DC'nin canlı ve uygun olduğunu doğrular, ilk yanıt veren tercih edilir.
• Netlogon DC cache: keşfedilen DC'yi saklayarak sonraki isteklerde tutarlı DC kullanımını sağlar; DS_FORCE_REDISCOVERY bunu atlar.
• netlogon.log (%SystemRoot%\debug\netlogon.log): site eşleşmeyen istemcilerin NO_CLIENT_SITE kayıtlarını tutan tanılama günlüğü.

İstemci DC adaylarını nasıl bulur?

Bir istemci BESIKTAS\birkan olarak oturum açmak istediğinde önce 'bu domain'in bir DC'si nerede?' sorusunu çözmelidir. Bunu yapan bileşen istemcinin kendi Netlogon service'idir; uygulama DsGetDcName API'sini çağırır ve istek yerel Netlogon'a RPC olarak iletilir.

Netlogon, DNS-based discovery modunda domain adını uygun bir şablona ekleyerek SRV kayıtlarını sorgular. Örneğin bir LDAP DC'si için sorgu _ldap._tcp.<DnsDomainName> biçimindedir. DNS, bu adı kayıtlı DC'lerin listesiyle yanıtlar.

SRV kayıtları yalnız 'hangi hostlar DC' bilgisini verir; canlılık bilgisini vermez. Bu yüzden Netlogon dönen adaylara LDAP UDP ping (datagram) gönderir. İlk yanıt veren DC seçilir ve sonuç DsGetDcName üzerinden uygulamaya döner.

Site ve subnet, 'en yakın DC' kararının verisidir

Büyük ortamlarda her domain için birden çok DC vardır. İstemcinin uzaktaki bir DC yerine kendi lokasyonundaki DC'yi seçmesi için sites and subnets topolojisi kullanılır: her subnet bir AD site'ına eşlenir ve DC'ler site'a özgü SRV kayıtları da yayınlar.

İstemci kendi IP adresinden hangi site'ta olduğunu belirler ve önce _<service>._<protocol>.<SiteName>._sites... kayıtlarını hedefler. SiteName parametresi DsGetDcName'e NULL verildiğinde, en yakın site'taki DC bulunmaya çalışılır.

Kritik nokta: bu 'en yakın' kararı tamamen subnet→site eşlemesinin doğruluğuna bağlıdır. İstemcinin IP'si hiçbir tanımlı subnet'e uymuyorsa istemci site'sız kalır ve herhangi bir DC'ye — muhtemelen uzaktaki birine — yönlenebilir. DC bu durumu netlogon.log içinde NO_CLIENT_SITE olarak kaydeder.

Cache ve rediscovery: tutarlılık ile tazelik dengesi

Netlogon, keşfettiği DC'yi cache'ler. Bunun amacı her istekte pahalı keşif sürecini tekrarlamamak ve aynı DC'yi kullanarak AD'nin tutarlı bir görünümünü korumaktır.

DsGetDcName davranışını Flags ile ayarlanır. Örneğin DS_BACKGROUND_ONLY cache 15 dakikadan eski olsa bile ping ile tazelemeyi atlar; DS_FORCE_REDISCOVERY ise cache'i tümüyle yok sayıp taze bir keşif yapar. Microsoft, DS_FORCE_REDISCOVERY'nin yalnız dönen DC'ye erişilemediği anlaşıldığında kullanılmasını, normal koşulda cache'in performans ve tutarlılık için tercih edilmesini önerir.

Bu ders boyunca tek bir istemci isteğini izleyelim: WS-034, outreason.example domain'i için DsGetDcName çağırır → Netlogon DNS'e _ldap._tcp.<site>._sites.dc._msdcs.outreason.example sorar → dönen adaylara LDAP ping atar → ilk yanıt veren DC01 seçilir → sonuç cache'lenir. Her adımda değişen state cache içeriği ve seçilen DC kimliğidir.

Durum ve veri akışı

1. Uygulama DsGetDcName çağırır; istek istemcinin yerel Netlogon service'ine RPC ile gider.
2. Client IP/subnet ile AD site eşlemesini değerlendir. Site biliniyorsa site-specific SRV adayları aranabilir; eşleme yoksa site dışı adaylara yönelme ve NO_CLIENT_SITE kanıtı ayrı incelenir.
3. DNS, SRV (ve A) kayıtlarıyla aday DC'lerin listesini döner.
4. Netlogon adaylara LDAP UDP ping gönderir; her uygun DC canlı olduğunu bildirir.
5. İlk yanıt veren DC seçilir ve bilgisi DsGetDcName üzerinden uygulamaya döner.
6. Netlogon seçilen DC'yi cache'ler; sonraki istekler keşfi tekrarlamadan aynı DC'yi kullanır.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım, keşif katmanının (DNS SRV yanıtı, LDAP ping, site verisi) güvenilir olduğu ve 'bir DC bulundu' sonucunun o bağlantının güvenli/doğrulanmış olduğu anlamına geldiğidir. Discovery güvenle authentication'ı karıştırmak yanlış modeldir.

Technical prerequisites

• İstemcinin çözümlediği isim veya SRV yanıtını etkileyecek bir konum (yerel resolver, hosts dosyası, sahte DNS yanıtı, aynı segmentte mailslot/broadcast'e cevap) üzerinde etki.
• Ya da tam tersi savunma tarafında: subnet→site eşlemesinin eksik olması, bu da site-sız istemcileri istemsizce yanlış DC'ye yönlendirir.
• Etkinin ötesine geçmek için istemcinin sahte hedefe karşı yaptığı bir sonraki adımın (kimlik doğrulama, credential gönderimi) o hedefçe kötüye kullanılabilmesi.

Exploitation mechanism / İstismar mekanizması

DC Locator, güvenmesi gereken veriyi ağdan alır: DNS SRV yanıtları ve LDAP ping cevapları. Bu keşif verisini yönlendirebilen bir aktör, istemciyi seçtiği bir hosta yönlendirebilir. Ancak burada mekanizma ile sonucu ayırmak gerekir: istemciyi bir hosta *yönlendirmek* tek başına o hosta credential vermesini veya güvenmesini sağlamaz. Kerberos'ta istemci gerçek DC'nin bildiği anahtarlara dayalı doğrulama bekler; NTLM/relay senaryolarında ise asıl risk keşif değil, sonraki authentication akışının relay edilebilmesidir. Yani DC Locator'ı zehirlemek bir 'giriş' sağlar; etki, ondan sonraki authentication kontrolünün ne kadar dayanıklı olduğuna bağlıdır.

Yanlış DC'ye gitmek ile yanlış DC'ye güvenmek farklıdır

İstemciyi sahte bir hosta yönlendirmek, o hostun istemcinin kimliğini doğrulayabileceği anlamına gelmez. Kerberos'ta authentication, KDC'nin ve istemcinin paylaştığı sırlara dayanır; rastgele bir host geçerli bir bilet üretemez.

Gerçek risk çoğunlukla keşifin kendisinde değil, keşiften sonra tetiklenen zorunlu authentication'ın (ör. otomatik NTLM) bir saldırgan tarafından başka bir servise relay edilebilmesindedir. Bu yüzden savunma, keşifi 'güvenli' saymak yerine sonraki authentication katmanını (imzalama, channel binding, relay koruması) sertleştirmeye odaklanır.

Yanlış yapılandırma da bir saldırı yüzeyidir

Saldırgan olmadan bile eksik subnet→site eşlemesi istemcileri yanlış/uzak DC'lere yönlendirir. Bu, gizlilik ihlali değildir ama gecikme, oturum açma yavaşlığı ve tanılama karmaşası üretir; olay incelemesinde 'neden bu DC?' sorusunu zorlaştırır.

Kapsam ve engelleyici koşul önemlidir: DC Locator'ı etkilemek geniş, otomatik domain compromise değildir. Etki, saldırganın ağ konumuna, hangi authentication protokolünün tetiklendiğine ve o protokolün relay/imzalama korumalarına bağlıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• DC Locator'ın kendisi bir Security audit olayı üretmez; keşif kanıtı büyük ölçüde istemci ve DC tarafındaki Netlogon tanılamasında (System log ve netlogon.log) bulunur.
• DC tarafında NETLOGON kaynaklı System log olayı 5807, site'a eşlenmeyen istemci IP'lerinden gelen bağlantıların özet sayacıdır; ayrıntı (hangi istemci, hangi IP) %SystemRoot%\debug\netlogon.log içindeki NO_CLIENT_SITE satırlarındadır.
• 5807 bir tehdit alarmı değil, topoloji hijyeni sinyalidir: eksik subnet tanımını gösterir. Tek başına saldırı kanıtı olarak yorumlanmamalıdır.
• Hangi istemcinin hangi DC ile kimlik doğruladığını görmek için keşif olaylarına değil, DC'deki Kerberos/oturum olaylarına (ör. 4768/4769 içindeki client IP) bakılır; bu ders o olayların ayrıntısını 06 bölümüne bırakır.

Events and relevant fields

• NETLOGON / 5807 (System channel): belirli bir süre içinde site'a eşlenmeyen istemcilerden gelen bağlantı sayısının özeti; per-client ayrıntı netlogon.log'dadır.
• netlogon.log / NO_CLIENT_SITE: <domain>: NO_CLIENT_SITE: <bilgisayar> <ip> biçiminde, hangi IP'lerin hiçbir site'a uymadığını listeler.
• 5807 EventData alanları üretici mesaj şablonuna bağlı insertion string'lerdir (süre ve bağlantı sayısı); yapılandırılmış, adlandırılmış Security alanları gibi ele alınmamalıdır.

Keşif kanıtı ile authentication kanıtını ayır

Bir arıza incelemesinde 'istemci DC'yi bulamadı' ile 'DC'yi buldu ama kimlik doğrulama başarısız' farklı aşamalardır. İlki DNS/SRV/site ve Netlogon cache; ikincisi Kerberos/NTLM katmanıdır.

5807 ve netlogon.log site/subnet tarafını aydınlatır. Hangi istemcinin hangi DC ile başarıyla kimlik doğruladığını görmek için DC'deki authentication olaylarına bakılır. İki kanıt kümesini karıştırmak yanlış kök nedene götürür.

5807 bir sayaçtır, bir suçlama değil

5807, eşiği aşan site-sız bağlantıların özetini verir; ne saldırı ne de tek bir istemci hakkında kesin hüküm içerir. Değer, netlogon.log'daki NO_CLIENT_SITE satırlarıyla ve subnet envanteriyle birleşince anlam kazanır.

Bulut, VPN ve geçici ağlar tasarım gereği site-sız olabilir; bu yüzden allowlist ve beklenen IP havuzları olmadan tek bir 5807'yi olaya çevirmek yanlış pozitif üretir.

Detection logic · KQL

// 5807 NETLOGON System-log uyarisidir (Security auditi degil); topoloji hijyen sinyali.
// Log Analytics 'Event' tablosu Windows System/Application loglarini tasir (MMA/AMA collector).
Event
| where TimeGenerated > ago(24h)
| where Source == "NETLOGON" and EventID == 5807
| project TimeGenerated, Computer, EventID, RenderedDescription
| summarize EventCount = count(), Ilk = min(TimeGenerated), Son = max(TimeGenerated) by Computer
| sort by EventCount desc

Query assumptions

• 5807 Security kanalinda degil System kanalindadir; Sentinel/SIEM tarafinda System logunun toplandigi dogrulanmalidir (ornek: Event tablosu, AMA DCR System log kaydi).
• Source alan degeri collector normalizasyonuna gore 'NETLOGON' yerine farkli yazilabilir; mapping dogrulanmalidir.
• Per-client IP ve bilgisayar adi olayda degil netlogon.log'dadir; tam liste icin o dosya ayrica toplanmalidir.
• Sorgu gercek bir workspace veya veri kumesi uzerinde calistirilmadi.
• EventCount, 5807 kayıtlarının sayısıdır; mesajdaki istemci bağlantı toplamı değildir. Insertion string’den bağlantı sayısı çıkarmak collector, dil ve sürüm doğrulaması gerektirir; bu query bunu yapmaz.

False positives

• Yeni eklenen subnet'ler henuz Sites and Services'e tanimlanmadan once gecici 5807 artışı.
• VPN/DirectAccess veya bulut istemcileri gibi tasarim geregi site eşlemesi olmayan IP havuzlari.
• Test/lab segmentleri ve gecici DHCP araliklari.

Hardening

• Sites and Services'te tüm istemci subnet'lerini doğru site'lara eşle; netlogon.log'daki NO_CLIENT_SITE IP'lerini envanterle ve eksik subnet tanımlarını kapat.
• Keşifi güvenli saymak yerine sonraki authentication katmanını sertleştir: LDAP signing/channel binding, SMB signing ve NTLM relay korumalarını uygula (ilgili dersler kapsamında).
• DNS'te locator kayıtlarının doğruluğunu ve DNS altyapısının bütünlüğünü koru; scavenging ve yetkisiz kayıt değişikliklerini izle.
• Windows Server 2025 ve sonrasında NetBIOS-based discovery varsayılan olarak engellidir (BlockNetBIOSDiscovery); eski WINS/mailslot keşfine bağımlılığı envanterle ve aşamalı olarak DNS-based discovery'ye taşı, geri dönüş planı hazırla.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="NETLOGON" />
    <EventID>5807</EventID>
    <Channel>System</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data>24</Data>
    <Data>137</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: İstemci her zaman kendi site'ındaki en yakın DC'ye gider.

Gerçekte: 'En yakın' kararı subnet→site eşlemesine bağlıdır. İstemcinin IP'si hiçbir tanımlı subnet'e uymuyorsa istemci site-sız kalır (DC'de NO_CLIENT_SITE / 5807) ve uzaktaki bir DC'ye yönelebilir; ayrıca Netlogon cache önceden seçilmiş bir DC'yi tutabilir.

Sanılan: DNS'te doğru SRV kaydını bulup DC'ye ulaşmak, kimlik doğrulamanın da başarılı olacağı anlamına gelir.

Gerçekte: SRV sorgusu ve LDAP UDP ping yalnız keşif ve canlılık kontrolüdür. Authentication ayrı bir adımdır: erişilebilen bir DC yine de kimlik doğrulamayı reddedebilir ve rastgele bir host geçerli Kerberos bileti üretemez. Discovery ≠ authentication.

Kaynaklar / Sources

• Microsoft · Locating Active Directory Domain Controllers (DC Locator)
  Domain controller locator process; Discovery process (DNS-based); SRV format _<service>._<protocol>.<DnsDomainName>; LDAP UDP ping; Netlogon cache; BlockNetBIOSDiscovery
• Microsoft · Domain Controller Location
  Locator records; clients use DNS to locate domain controllers
• Microsoft · DsGetDcNameW function (dsgetdc.h)
  Syntax; SiteName parameter (NULL = closest site); Flags DS_BACKGROUND_ONLY (15-minute cache), DS_FORCE_REDISCOVERY, DS_TRY_NEXTCLOSEST_SITE; NetApi32.dll
• Microsoft · Slow/timeout LDAP, Kerberos and DC locator responses; NO_CLIENT_SITE and event 5807
  NETLOGON 5807; netlogon.log NO_CLIENT_SITE; missing subnet-to-site mapping
• IETF · RFC 2782 (DNS SRV RR)
  _Service._Proto.Name SRV record format; priority/weight/port/target