<Database’in sorgulanması

DNS Sorguları bir clienttan yada bir DNS Serverdan gönderilebilir. DNS server’a uygun iki tip sorgulama yöntemi vardır.
· Recursive
· Iterative
* Recursive sorgulama DNS server’i sorgu ile ilgili herhangi bir cevap (olumlu yada olumsuz) göndermesi için zorlar. Bu durumda DNS server recursive bir sorgu ile karşılaştığında diğer DNS server’larla da irtibata geçerek bu sorguyu cevaplamaya çalışır. Eğer Recursive sorgu DNS Server’in kendi cache’inde çözümlenemez ise bir üst DNS Server’a (Root Server) yönlendirilir.
* Iterative tip sorgulamada ise sorgu bir Name Server’a gönderilir veya Name Server kendi Cache’inden sorguya olumlu yada olumsuz bir cevap mutlaka gönderir. Eğer sorgu cevabı kendisinde yok ise bunu başka bir DNS Server’a göndermez ve client’a negatif cevap gönderir.
Aşağıdaki şekilde her iki sorgu için de bir örnek verebiliriz.



Şimdi bunu biraz açıklayalım. Client www.kabak.net in IP adresini sorgulamaktadır.
.Iterative sorgu (A RR) => www.kabak.net 2
·Net’i gösteren name serveri (NS RR, net) 3
·Iterative sorgu (A RR) => www.kabak.net 4
·Kabak.net’i gösteren name server (NS RR, kabak.net) 5
·Iterative sorgu (A RR) => www.kabak.net 6
·Kabak.net serverdan cevap (www.kabak.net’in IP addresi) 7
Local DNS serverdan Resolver’a cevap (www.kabak.net’in IP address) 8

Incremental Zone Transfer

IXFR işlemi için Master Server bir Bilgilendirme (NOTIFY) paketi gönderir. Bu pakette Zone değişikleri yoktur, sadece değişiklik olduğuna dair bilgilendirme paketidir. Bu paketten sonra transfer işlemi başlar. Yukarıda bahsettiğimiz Full Zone transfer metodu çokta kullanışlı ve tavsiye edilen bir yöntem değildir, çünkü bu yöntemde Zone dosyalarının tamamı transfer edilmektedir. Incremantal transfer işlemi ise sadece değişiklikleri transfer edecektir ve tavsiye edilende budur.

Incremental Zone Transfer Nasıl Çalışır ?

Slave server IXFR bir Zone transfer gerçekleştirebilir ve mevcut Zone dosyalarını çeker. Bu işlemi gerçekleştirdikten sonra kopyaladığı Zone için kontrol etmek istediği kaydın seri numarasını bir IXFR mesajı ile Master Server’a gönderir. Master server kendisine gelen mesajdaki seri numarasının eski versiyon olup/olmadığını yani, Zone’da bir değişiklik olup olmadığını kontrol eder , eğer bir değişiklik varsa sadece bu değişikliği transfer eder , full zone transfer gerçekleşmez. Bazı durumlarda ise full zone transfer , incremental zone transferden daha avantajlı olabilir. Bu durumlar aşağıdaki gibi özetlenebilir.
· Değişikliklerin miktarı Zone’dan daha büyükse
· Eğer server aldığı IXFR tipinde bir sorguyu cevaplarken , sorguyu çözemez ise IXFR zone transfer kullanmak yerine otomatik olarak AXFR zone transfer başlatır.
Aşağıdaki şekil incremental transfer mekanizmasını göstermektedir.



Dinamik Update

Geleneksel DNS yapısında eğer Zone içinde önemli değişiklikler olması gerekiyorsa bunu Network Administrator manuel olarak yapmaktaydı. Zaten DNS orjinalinde bütün kayıtlar statik konfigüre edilmiştir. Bununla beraber network büyüdükçe ve sık sık değişiklik yapılması gereken durumlar ortaya çıkınca manuel kayıt girmek zorlaştı. Dinamik olmasının avantajı DHCP gibi otomatik IP adresi sağlayan servislerin gereksiz DNS kayıtlarını manuel girme problemini gidermesidir.

Dinamik Update Nasıl Çalışır ?

Windows 2000 Server dinamic dns (DDNS)’i destekler. Bir update mesaj sayesinde Zone’a bir RR eklemek yada silmek bu sayede tanımlanabilir. Eski yapıda bir DNS’in update işlemini gerçekleştirmesi için o zone için bir primary name server gereksinimi vardı. Böylece secondary server bir update işlemi istediğinde primary server replikasyon topolojine uygun olarak işlemi gerçekleştirmektedir.

Dinamik Update Algoritması

Update işlemi aşağıdaki sırada olmaktadır.
·Client, bir SOA sorgu kullanarak primary DNS serverin yerini öğrenir ve register edilmiş kayıtlar için yetkili Zone dosyalarına ulaşır.
.Client, bu DNS’e bir assertion(bildiri) gönderir.
Bu bildirinin amacı update
edilecek kaydın olup olmadıgını kontrol etmektir. Eğer kayıt yoksa client uygun register kaydının update’i için gereken paketi gönderir.
. Eğer update başarısız olursa client sistemde varsa başka DNS serverlara update işlemi için girişimde bulunur. Eğer bütün primary server’larda update işlemi başarısız olursa 5 dakika sonra tekrar dener, yine başarısız olursa 10 dakika sonra tekrar dener , tekrar başarısız olması durumunda 50 dakika sonra ve sürekli dener.

DNS Kayıtlarının Dinamik Update İşlemi

Windows 2000 çalıştıran bütün bilgisayarlar A ve PTR kayıtlarını register etmek girişiminde bulunurlar. Bu işlem için client eğer DHCP client olarak ayarlanmışsa çalışan DHCP client servisi her makinada çalışacak ve bu kayıtların DNS’ e girmesini sağlayacaktır.
Dinamik Update işlemi clientin yapılandırmasına göre değişik şekillerde çalışır. Bu durumda 3 senaryodan bahsedebiliriz.

. DHCP Client
.Statik konfigüre edilmiş Client
. RAS Client

DHCP Client

Default olarak DHCP Server PTR RR kayıtlarını update ettiği zaman DHCP Client A RR kaydını update etmek ister.Tabiki DHCP Serverin “Update DNS server according to client request” yada “Always update forward and reverse look-ups.” olarak konfigüre edilmiş olmalıdır.(Default olarak böyledir) . Eğer DHCP Server bu şekilde konfigüre edilmemişse Client A ve PTR kayıtlarını kendi kendine yapmaya çalışacaktır.
IP kira süresi bittiği zaman , o client’te uygun kayıt Zone’dan silinecektir. Bu işlem Dynamic Cleanup olarak Adlandırılır...

Mixed Ortam

Windows 2000 DHCP client makinalar , Windows NT 4.0 DHCP server ile veya Dinamik update işlemini destekleyen herhangi bir DHCP Server ile dinamik update procedürlerini sorunsuz çalıştırabilir. Windows NT 4.0 DHCP serverdan öncesinde client A ve PTR kayıtlarını DHCP server dinamik update’i desteklemediği için kendi kendine yapmaktaydı.
Bu durumun aksine down-level clientlar (Windows 95/98, Windows NT) eğer Windows 2000 DHCP serverin ”Do updates for down-level DHCP clients” opsiyonu işaretlenmiş ise A ve PTR dns kayıtlarını register edebilirler.

Statik konfigüre edilmiş Client

Statik konfigürasyon yapılmışsa client DHCP server ile bağlantıya geçmeyecektir, böylece A ve PTR kayıtlarını boot ettikten sonraki bir zamanda yapacaktır. Aynı şekilde IP numarası değişecek olursa bu işlemi tekrarlayacaktır.

Ras Client

Ras Client Statik konfigüre edilmiş client gibi davranmakla beraber DHCP server ile herhangi bir etkileşimi yoktur. Client A ve PTR kayıtlarını dynamic update etmekle sorumludur. Bununla beraber client bağlantısını keseceği zaman serverdan kayıtları silme girişiminde bulunur. Eğer bu girişim başarıyla sonuçlanırsa sorun yoktur, ancak bu girişim baraşırız olursa (Örneğin bağlantı beklenmedik bir şekilde kopar yada DNS server o an kapalı olacak olursa) kayıtlar silinemeyecek ve DNS serverda kalacaktır. Bu durumda server deregistration işlemi yaparak doğru PTR kaydını tekrar register edecektir.

Client Reregistration

Client otomatik register işlemi ile RR kayıtlarını DNS servera iletecektir. Bu noktada DHCP server ile DNS ortaklaşa çalışacaktır. Windows 2000 makinalar kendilerini her 24 saatte bir DNS servera kaydettirmeye çalışacaklardır. Bu süre registry’da aşağıda belirtilen yoldan değiştirilebilir.

HKLM\\System\\CurrentControlSet\\Services\\Tcpip\\Parameters registry key altında DefaultRegistrationRefreshInterval değeri. TTL değeride aynı yerde DefaultRegistrationTtl değeri ile değiştirilebilir. Default 20 dakikadır.

Kayıt esnasında isim çakışması durumu

Client DNS’e RR kayıtlarını dinamik update ile kaydetmek istediği zaman, eğer aynı isim IP adresi ile başka bir makina tarafından daha önceden register edilmiş ise client bu kaydı silerek kendi kaydını register etmeye çalışacaktır. Eğer bu işlem başarısızlıkla sonuçlanacak olursa Event Viewer’e gerekli hata mesajı kaydedilecektir. Mevcut kaydın silinebilecek olması durumunu engellemek için Secure dinamik update yöntemi kullanılmalıdır. Çünkü secure dinamik update’te sadece kayıtların gerçek sahibi bu kayıtları update etme hakkına sahiptir.

Secure Dynamic Update

DS Integrated Zone Secure dinamik update’i kullanmak üzere konfigüre edilmiştir default olarak. Windows 2000 DNS uygulamasında Secure Dynamic Update algoritması “GSS Algorithm for TSIG (GSS-TSIG).” olarak adlandırılmaktadır. Bu algoritma Generic Security Service Application Program Interface tabanlıdır. Bu güvenlik mekanizmasının altında, güvenlik servisinin bağımsızlığını sağlayacaktır. Bu güvenlik servisi aşağıdaki process’lere ayrılacaktır.
·Security token yöntemi kullanılarak bir security context kurulması.
·Bir kere bu Security Context kurulur, ancak bunun süresi sınırlıdır.
Secure Dynamic Update işleminin uygulama sırası aşağıdaki şekilde ifade edilmektedir.



1. Durumda ; Client Local Name Server’a bir query göndererek Name update girişimini yapacağı Server’ı sorar.
2. Durumda ; Client bulduğu yetkili server’a ismini update etme girişiminde bulunur ve bu girişimi Server kontrol eder
3. Durumda ; Client Non-Secure Update girişiminde bulunur ve Serverdan olumsuz yanıt alır. Tabiki burada Server Secure update yapacak şekilde konfigüre edilmiş ise.
4. Durumda ; Client ve Server Security Context görüşmelerina başlar, bir veya birden fazla Security Token değişimi olur ve Token taşıma işlemi TKEY RR kaydı kullanılarak yapılır. Client ve Server Kerberos kullanıyorlarsa, bu algoritmayı kullanarak birbirlerinin kimliklerini kontrol ederler. Daha sonra Security Context bağlantısı kurulur ve Client ile Server arasında mesajlaşma başlar.
5. Durumda ; Client , Server’a imzalı Secure dynamic update isteğini gönderir. Bu dijital imzalı isteklerin taşınması görevini ise TSIG RR kaydı üstlenir.
6. Durumda ; Server Active Directory ‘de update girişiminde bulunur. Burada client’in yetkisi olup olmadığı kontrol edilerek update işleminin yapılıp yapılamayacağına karar verilir.
7. Durumda ; Server, Client’a imzalı bir mesaj ile update işleminin yapılıp yapılamayacağını bildiren mesajı gönderir.

Secure Dynamic Update Policy

Client DNS Server’a bir dynamic update girişiminde bulunduğu zaman, aşağıdaki yollardan birtanesini kullanabilir.
.Önce Non-Dynamic update girişiminde bulunur ve olumsuz olur buna mukabil Secure Dynamic Update görüşmeleri başlar (Yukarıda ifade ettiğimiz şekliyle)
.Her zaman secure dynamic update işlemi yapabilir.
. Sadece Non-Secure update girişiminde bulunabilir.

DnsUpdateProxy Group

Eğer sisteminizde birden fazla DHCP server kullanıyorsanız (Backup amacıyla) bazı sorunlarla karşılaşabilirsiniz. Ne gibimi ? . Öncelikle bildiğimiz üzere Windows 2000 DHCP server dinamik olarak A ve PTR kayıtlarını register edebiliyordu. Bu durumda Windows 2000 DNS Server secure dynamic update kullanıyorsa bazı sorunlarla karşılaşılabilinir. Örneğin ;

1- Bir DHCP serverimizi olsun. Adı DIEYCSIPI olsun. Ve bu server belirli bir DNS domain name için clientlarin secure dynamic update yapabilsin.
2- Bununla beraber client secure dynamic update ile kendini DNS’e kaydettirdiginde bu bilgiyi sadece kendisinin tekrar update ettiğini biliyoruz. Dolayısıyla client DHCP server’a bir kere IP ve ismini verdiği zaman bu ismi DNS’e sadece o DHCP server kaydettirebilecektir.
Bu durumda bazı sorunlar çıkabilir. İkinci bir DHCP serveriniz var ve ismide SEKONDDIEYCSIPI server olsun. Bu durumda eğer DIEYCSIPI çökecek olursa bu client’in register update işlemini SEKONDIEYCSIPI server yapamayacaktır , çünkü o clientin ismi aslında bu serverda kayıt edilmemiştir. Bu problemi çözmek için DnsUpdateProxy security grubu kullanılır. Bu gurubun üyeleri tarafından create edilmiş her obje daha sonra modify veya update etme hakkına sahip olacaktır. Dolayısıyla DHCP server RR kayıtlarını register edecektir , eğer client bu grubun üyesi ise.

DNS Admins Group

Default olarak Windows 2000 domain’ninde DNS Admin grubu bütün Zone’lar üzerinde full control yetkisine sahiptir. Ancak bazı durumlarda DNS Admin grubunun üyelerinin tüm yetkilerini kullanabilmeleri sakıncalı olabilir. Bu durumda Domain administrator , bu kullanıcıları sadece yetkili oldukları Zone üzerinde full control yetkisini vererek diğer Zone’lar için Read hakkı verebilir. DNS Admin grubu Active Directory Users and Computer’dan konfigüre edilebilir.

Unicode Karakter Desteği

DNS isimleri a-z , 0-9 ve başka karakterler içerebilirler. Ayrıca DNS isimlerinin ilk karakterleri sayıda olabilir. (Örnegin. www.3com.com)
Netbios name , DNS name gibi geniş bir desteğe sahip değildir.
Bununla beraber Windows 2000 DNS Server , her server ve her zone için UTF karakter setinin kullanılabilmesine izin vermek yada izin vermemek durumlarıyla konfigüre edilebilir. Non-UTF-8 standardı kullanan bir DNS server UTF-8 standardı kullanan bir DNS serverdan zone transferini kabul edebilir ancak bunun tersi gerçekleşmez.


Disabling the Caching Resolver


DNS Serverinizin cache vazifesini görmesini engellemenin 2 yolu vardır. Birincisi ; dos prompttan “ net stop Dnscache ” komutunu vererek. İkinci yöntem ise REG_DWORD MaxCacheEntryTtlLimit değerini 0 (Zero) yapmaktır.

Active Directory için DNS İsimlendirmesi

DNS konfigürasyonu yapmasanızda Windows 2000 Server’iniz doğru bir şekilde çalışabilir. Ancak Active Directory kurulumunda DNS kaçınılmaz olarak kullanılmalıdır.
Bir Windows 2000 Active Directory Namespace dizaynı yapmadan önce bazı şeyleri önceden düşünmeniz ve hazırlamanız gerekmektedir. Örneğin domaininizdeki Forest , Tree yapılarınız Organiztional Unit ve Global Catalog yapılandırmalarınız, Güven ilişkileriniz ve tabiki replikasyon işlemleri gözardı etmemeniz gereken uygulumalardır.
DNS dizaynı yapmadan önce şu soruların cevaplarını vermeniz iyi olacaktır.
1- Kaç tane Active Directory domainine ihtiyacınız olacak
2- Bunların isimleri ne olacak
3- Bilgisayar isimleriniz ne olacak


İnternet Erişiminde Dikkat Edilecek Hususlar

İnternet erişimi şirketlerin DNS yapılandırmalarını yapmalarında önemli bir faktörü teşkil eder. Şöyleki, sizin şirket içi yapılandırmanız (internal/private) internet ortamındaki yapılandırmadan (external/public) tamamen ayrı ve bağımsızdır. Ancak şirketin internete erişebilmesi ve yapısını değiştirmeden güvenli bir çıkış sağlayabilmesi gerekmektedir. Bunun için iki örneği ele alabiliriz. Bu örneklerimizde 2 şirket olsun. AAA ve BBB şirketleri. Bu şirketlerin internette aaa.com ve bbb.com olarak DNS isimleri register edilmiş olsun. Bu durumda internal client’lerin internette çıkabilmeleri , yani external DNS isimlerini çözebilmelei için bazı yollar vardır. Bunlar ;
· Proxy üzerinden
· LAT (Local Adres Table) desteği ile
· Supporting Name Exclusion List
· Supporting Proxy AutoConfiguration dosyası
Eğer internal clientlar proxy üzerinden yada LAT ile çıkıyorlarsa , bu durumda internal DNS serverlar sadece çözümlenmemiş sorguları (unresolved query) dışarıya gönderecektir.

DNS Sorgu Algoritmalarından Bazı Örnekler

Örnek 1:



Burada A makinamız http://www.third.yyy.com/ adresini istemiş olsun. Bu adrese ulaşabilmek için ;
İlk Dns Server’a , yani , firs.yyy.com a bu ismi soracaktır (1). Eğer bu isim bu serverin bilgisinde yok ise , bu sorgu bir üste , yani , yyy.com a sorulacaktır (2). Bu sorgunun cevabı (3) ana serverdan gönderildikten sonra , bu bilgi doğrultusunda third.yyy.com serverina sorgu gönderilecektir. (4) Bu sorgunun cevabı verilecektir. (5) Cevap , sorguyu gönderen makinaya ulaştırılacak ve işlem bitecektir. (6)

B makinamızında www.third.zzz.com Bunun için ;
İlk olarak ilk DNS servera gerekli bilgi sorulur, eğer bu DNS serverin bilgisi dahilinde ise clienta bilgi gönderilir değilse bir üste yani zzz.com a sorulur. (1 ve 2) zzz.com bu bilgiyi third.zzz.com ile haberleşerek kontrol ettikten sonra (3 ve 4) gerekli bilgi first.zzz.com a iletilir, (5) son olarakta clienta istediği sorgunun cevabı gönderilir. (6)

Örnek 2 : Aşağıdaki örnek hayatınızın dönüm noktası olacaktır. DNS den öncesi ve DNS den sonrası. O halde inceleyelim.



* YYY şirketindeki bir computer www.kabak.com sayfasını istemiş olsun. Bu amaçla bi sorgu göndermiş olsun. Bu durumda client sorgusu öncelikle proxy server tarafından değerlendirilir(1). Daha sonra bu sorgulama Proxy tarafından bi üst dns servera(yyy.com) gönderilir(2). Bu sorgunun cevabı bulunamassa bu DNS server sorguyu Root DNS’e gönderir(3) . Root DNS server kendisinden bu bilgiye dair sorgunun cevabını gönderir(4). Yyy.com Root DNS serverdan aldığı bilgi doğrultusunda bi üst DNS servera sorguyu gönderir(5). Sonraki işlemler ise üstte izah ettiğimiz gibi normal gerçekleşir ve son olarak client a bilgi Proxy Server tarafından ulaştırılır.
* ZZZ şirketinde bir computer www.kabak.com sayfasına bir sorgu göndermiş olsun. (Unutmayın burada Proxy server yok !) Bu durumda sorgu ilk olarak first.zzz.com’a gidecektir (1), first.zzz.com eğer bu bilgi kendisinde yoksa bunu bir üst DNS’e soracaktır, yani zzz.com’a. Eğer ondada bilgi yok ise firewall üzerinden dışarıdaki (External DNS Server) ‘a sorgu gönderilir(3). Zzz.com sorguyu en üst Root DNS Servera gönderir(4). Root DNS serverin istenilen bilginin hangi DNS Serverda tanımlı olduğunu geri döndürür.(5) Alınan bilgi doğrultusunda bir alt DNS e sorgunun cevabı için başvurulur. (6). Cevabın hangi makina olduğu bilgisi alınır. (7) Bu bilgiye erişildikten sonra bu bilgiyi barındıran makinaya www.kabak.com bilgisi sorulur ve gereken cevap alınır. (8 ve 9). Bu aşamadan sonraki 10-11-12 bu bilginin client computera ulaştırılmasından başka birşey değildir.

Örnek – 3 :



Client makina www.second.zzz.com bilgisini sorguluyor olsun. Bu bilgi öncelikle kendi bağlı bulunduğu DNS servera sorulacaktır. Bu DNS servarda bilgi varsa clienta verilecek yok ise bi üst DNS’e yönlendirme yapılacaktır. (1 ve 2) Eğer üst DNS bunu bilmiyorsa (3) bilgi bu kaydın olduğu DNS servera (External Server) gönderilecektir (VPN üzerinden) (4). ZZZ.com bilginin kendinde olduğunu gönderecek ve bu sorgunun cevabı client’a ulaşacaktır. (5 ve 6) .
* Ayrıca ZZZ şirketindeki clientin www.second.yyy.com bilgisini sorguladığını düşünelim. Bu durumda client bunu kendi DNS’ine soracak , sonra bir üst DNS’ e soracak ve bu DNS Serverda bu bilgi bulunduğu için yyy.com DNS’ine gitmek zorunda kalmayacaktır.