19.08.19/18:42

DNS ve 'Internet'in Tarihi'

Başlatan data_grrr, 24.02.07/08:36

« önceki - sonraki »

0 Üye ve 1 Ziyaretçi konuyu incelemekte.

data_grrr

DNS ve BIND - O'Reilly Kitapları                                                 Çeviri sadece deneme amaçlıdır.

                                      Bölüm 1                   

1- Arkaplan

İçerikler:
 
    İnternetin kısa tarihi
    İnternet ve internets üzerinde
    Domain Name System
    BIND'ın tarihi
    DNS kullanmalı mıyım?

          Beyaz tavşan gözlüğünü taktıktan sonra "Nereden başlayayım Majesteleri?" diye sordu. "Baştan başla" Kral çok ciddi bir şekilde söyledi, "ve sonuna gelene kadar devam et: sonra dur."


DNS'i  (domain name system) anlamak için ARPAnet tarihinden biraz bir şeyler bilmek önemlidir. DNS, ARPAnet'e ve onun soyundan gelen Internete özgü problemleri adresleyebilmek için geliştirilmiştir.

1-1 Internet'in kısa tarihi:

60'ların sonunda, U.S Department of Defense's Advanced Research Projects Agency, ARPA (daha sonra DARPA), ARPAnet adında, Birleşik Devletlerdeki önemli araştırma organizasyonlarını birbirine bağlayan deneysel bir wide area bilgisayar ağının finanse edilmesine başladı. Orijinal amaç hükümet birimlerinin pahalı ve nadir bulunan hesaplama kaynaklarının paylaştırılmasıydı. Bununla beraber, daha başından ARPAnet kullanıcıları bu ağı birlikle çalışmak için kullanmışlardır. Bu işbirliği dosya ve yazılım paylaşımından, elektronik mail gönderilip alınmasına kadar uzanıyordu. Böylece uzaktaki bilgisayarların paylaştırılmasıyla araştırma ve geliştirme birbirine eklemleniyordu.

TCP/IP (Transmission Control Protocol/Internet Protocol) protokol takımı 80'lerin başında geliştirilmiş olup, ARPAnet'te çabuk bir şekilde standart host-networking protokolü oldu. Bu protokol takımının, Berkeley'deki California Üniversitesindeki popüler BSD UNIX işletim sistemine dahil oluşu, internetworking'in demokratikleştirilmesinin aracı oldu. BSD UNIX sanal olarak üniversitelerde özgürdü. Bu internetworking'in -ve ARPAnet bağlantısının- birdenbire ucuz olarak çok daha fazla sayıda örgüt için ulaşılabilir olması anlamına geliyordu. ARPAnet'e bağlı olan bir çok bilgisayar, lokal networklere de bağlıydı ve kısa bir süre sonra lokal networklerdeki bilgisayarlar da ARPAnet yoluyla iletişim kurmaya başladılar.

Ağ bir avuç dolusu hosttan, onbinlerce hosttan oluşan bir network halini alarak büyüdü. Orijinal ARPAnet böylece , bugün Internet denilen, TCP/IP bazlı bölgesel  ve lokal networklerin konfederasyonunun omurgasını  oluşturdu.

1- Arkaplan

Bununla beraber 1988'de DARPA deneyin sona erdiğine karar verdi ve Department of Defense, ARPAnet'i parçalara ayırmaya başladı. National Science Foundation tarafından finanse edilen NSFNET adındaki bir diğer network, böylece ARPAnet'in yerini alarak Internetin omurgasını oluşturmaya başladı.
Hatta günümüze doğru gelirsek, 1995 sonbaharında, Internet, kamusal olarak finanse edilen NSFNET omurgasından birden çok ticari omurga kullanmaya geçiş yaptı.

Bugün internet, dünyadaki milyonlarca hostu birbirine bağlar. Aslında, PC olmayan bilgisayarların önemli bir bölümü Internete bağlıdır. Yeni ticari omurgalardan bazıları saniyede 622 megabits hacimle veri iletebilir. Bu rakam orijinal ARPAnet'inkinin onbinlerce kat üzerindedir. On milyonlarca insan networku günlük olarak işbirliği ve iletişim için kullanır.

1-2 Internet ve internets üzerine

Internet ve internets kelimeleri arasında basım açısından pek bir fark yoktur, birinin baş harfi daima büyük, diğerinin değildir. Bununla beraber, iki kelimenin anlamları arasındaki fark önemlidir. Baş harfi büyük olan Internet, ARPAnet olarak hayatına başlayıp, bugün, direkt veya dolaylı şekilde ticari omurgalara bağlı TCP/IP networklerinin konfederasyonu olarak hayatına devam eden network için kullanılır. Yakından baktığımızda birbirine yüksek hızlı dijital devrelerle bağlı olan az sayıdaki networklerdir (ticari omurgalar, ticari ve Birleşik Devletler TCP/IP networkleri, diğer ülkelerdeki TCP/IP networkleri)

Diğer yandan, küçük harfli internet, aynı internetworking protokollerini kullanan bir çok daha küçük networklerin oluşturduğu her hangi bir network için kullanılır. Bir internet (küçük "i" li) büyük harfli Internete bağlı olmak zorunda değildir, ne de internetworking protokolü olarak TCP/IP'yi kullanma zorunluluğu vardır. İzole edilmiş şirket internetleri olduğu gibi, Xerox XNS bazlı ve DECnet bazlı internetler vardır.

"İntranet" ise TCP/IP bazlı küçük "i" li internet için kullanılan bir pazarlama kavramından başka bir şey değidir, used to emphasize the use of technologies developed and introduced on the Internet within a company's internal corporate network. Bir "extranet" diğer yandan, partner olan şirketleri birbirne bağlayan, ya da bir şirketi distribütörlerine, müşterilerine, destekleyicilerine bağlayan bir internetdir.

1-2-1 Domain Name System Tarihi

70'lerde ARPAnet, küçük, insanların birbirini tanıdığı bir kaç yüz hosttan oluşan bir topluluktu. Bir tek dosya, HOSTS.TXT, hostlar hakkında ihtiyaç duyduğunuz bütün bilgileri içeriyordu: ARPAnet'e bağlanan her host için bir isimden adres haritalamaya (name to adress mapping) sahipti. Tanıdık UNIX host tablosu, /etc/hosts, HOSTS.TXT dosyasından derlenmiştir.(çoğunlukla UNIX'in kullanmadığı alanları silerek).

HOSTS.TXT SRI 'ın Network Information Center'ı  ("NIC" diye kısaltılır) tarafından tek bir host olan SRI-NIC'ten dağıtılmıştır [1]. ARPAnet yöneticileri tipik olarak değişiklikleri email yoluyla NIC'e postalayıp,ve periodik olarak SRI-NIC'i ftpleyip güncel olan HOSTS.TXT dosyasını alıyorlardı. Değiklikleri haftada bir ya da iki kez yeni bir HOSTS.TXT olarak derleniyordu. Fakat, ARPAnet büyüdükçe, bu plan çalışamaz duruma geldi. HOSTS.TXT dosyasının büyüklüğü ARPAnet hostlarının sayısıyla orantılı olarak büyüyordu. Üstelik bu güncelleme işlemi tarafından yaratılan trafik de daha artmıştı: Her yeni host, HOSTS.TXT dosyasında sadece yeni bir satır değil, ayrıca potansiyel olarak SRI-NIC'ten yeni bir host güncelleme anlamına geliyordu.

               [1] SRI, Menlo Park California'daki Stanford Research Institute kısaltmasıdır. SRI           
               bir çok farklı alanda araştırma yürütür, bilgisayar ağları bunlardan biridir.

Ve ARPAnet TCP/IP protokollerini kullanmaya başladığında, network popülasyonu patlayışa geçti. Böylece HOSTS.TXT problemleri doğmaya başladı.
Trafik ve yükleme (traffic and load)
     
          Dosyanın dağıtılması ile işlemciye binen yükün yanısıra, yaşanan network trafiği
          dayanılmaz olmaya başlamıştı.

İsim çakışmaları

          HOSTS.TXT deki iki host aynı ismi alamazdı. Bununla beraber, NIC, adres atamalarının biricikliğini garanti altına alırken, host isimleri üzerinde bir otorite  bulundurmuyordu. Birisinin çakışan bir isimle bir host eklemesini ve böylece tüm planı bozmasını engelleyecek hiçbir şey yoktu.

Kararlılık

          Sürekli genişleyen bir networkde dosyanın kararlılığını sağlamak giderek zorlaştı. Yeni bir HOSTS.TXT dosyası ARPAnet'in en uzak kıyılarına ulaşana kadar, network'ün diğer ucunda HOSTS.TXT değişmiş olabilir ya da kullanıcıların ulaşmak isteyeceği yeni bir host ortaya çıkmış olabilirdi.


Temel problem HOSTS.TXT mekanizmasının uygunsuz olmasıydı. İronik olarak, bir deney olarak ARPAnet'in başarısı HOSTS.TXT'nin başarısızlığıyla sonuçlanmıştı.

ARPAnet'in yönetici body'leri(ekipleri) HOSTS.TXT'nin ardılı için bir araştırma planı yaptı. Amaçları birleşik host tablosu sisteminin doğasında olan problemleri çözebilecek bir sistem yaratmaktı. Yeni sistem, verinin lokal yönetimine izin vermeliydi ve aynı zamanda bu veriyi global olarak erişilebilir kılmalıydı. Yönetimin desentralizasyonu tek-host darboğazının aşılmasına ve trafik probleminden kurtulmaya olanak sağlayacaktı. Ve lokal yönetim veriyi güncel tutma görevinin çok daha rahat gerçekleştirilmesini sağlayacaktı. Hostları isimlendirmek için hiyerarşik bir isim alanı kullanmalıydı. Bu isimlerin biricikliğini garantiliycekti.

USC'nin Information Sciences Institute bölümünden Paul Mockapetris, yeni sistemin mimarisinden sorumluydu. 1984'te, 882  ve 883 RFC lerini dağıttı. Bunlarda Domain Name System tanımlanıyordu. Bu RFClerin yerini daha sonra RFC 1034 ve 1035 aldı, Domain Name System'ın şu andaki tarifi. RFC 1034 ve 1035 şimdi, potansiyel DNS güvenlik problemlerini, kurulum problemlerini, yönetim problemlerini, isim serverlarını dinamik olarak güncelleme mekanizmalarını ve domain verisini korumayı ve daha bir çok başka şeyi anlatan RFC lerle desteklendi.

             [2] RFCler Reques for Comments dökümanlarıdır. Bu dökümanlar göreceli olarak gayri resmi şekilde Internet üzerine yeni teknolojileri tanıtır. RFCler genelde özgür şekilde dağıtılır ve çoğunlukla uygulayıcıları ilgilendiren teknik tanımlamalar içerir.


     
1-3 Domain Name System

Domain Name System sınıflara bölünmüş bir veritabanıdır. Bu tüm veritabanının segmentlerinin lokal kontrolüne izin verir ve buna rağmen her segmentteki data yine de bir client-server ilişkisi aracılığıyla bütün network tarafından erişilebilirdir. Replikasyon ve caching sayesinde sağlamlık ve yeterli performans elde edilir.

Name servers adındaki programlar, bu client-server mekanizmasının yarısı olan server tarafını oluşturur. Name server'ları veritabanının bazı segmentleri hakkında bilgi içerir ve bu bilgiyi, resolvers adı verilen client'lara açar (clientlar için erişilebilir kılar). Resolver'lar sıklıkla sadece kütüphane(library) rutinleri (routines) dir. Bu rutinler sorgulamalar yaratır ve bu sorgulamalar (queries) network üzerinden bir name server'a gider.

DNS veritabanı yapısı, aşağıdaki figürde de görüldüğü gibi, UNIX dosya sistemiyle oldukça büyük benzerlikler taşır. Bütün veritabanı, kök node en başta olacak şekilde (ya da dosyasistemi) tersyüz edilmiş bir ağaç gibi resmedilmiştir. Ağaçtaki her node'un bir text etiketi vardır. Bu text etiket, node'u parent'larıyla ilişkili kılan bir tanımlamadır.  Bu bir dosya sistemindeki "relative pathname" 'e kabaca benzerdir diyebiliriz, bin gibi. Bir etiket -- boş etiket, ya da "" - root node için reserve edilmiştir. Yazılış halinde, root node'u tek bir nokta "." şeklinde yazılır. UNIX dosya sisteminde, root bir slash olarak ("/") yazılır.

Figür 1-1: DNS veritabanı -- UNIX dosya sistemi karşılaştırması



Her node ayrıca, tüm ağaç yapısındaki yeni bir altağacın root'udur. Bu altağaçların her biri tüm ağacın bir bölümünü temsil eder (UNIX dosya sisteminde bir "klasör", ya da Domain Name System'in içinde bir domain.). Her domain ya da klasör,DNS'de subdomain ya da filesystem'da subdirectory adı verilen daha alt ek bölümlere ayırılabilir. Subdomainler de subdirectory ler gibi, ebeveynlerinin çocukları gibi çizilir. (children of their parents)

Her domain'in biricik bir ismi vardır, her directory'nin olduğu gibi. Bir domain'in domain name'i onun veritabanındaki pozisyonunu tanımlar, tıpkı bir directory'nin "absolute pathname" inin o directory'nin filesystem'daki yerini göstermesi gibi. DNS'de domain name, domain'in root'undaki node'dan tüm ağacın root'una uzanan, etiketlerin "." ile ayrıştırıldığı bir etiketler sıralamasıdır. UNIX dosyasisteminde, bir directory'nin mutlak pathname'i relative isimlerin root'tan yaprağa doğru sıralandığı bir listedir (DNS'e göre zıt yönde ve figür 1.2 de görüldüğü gibi isimleri ayırmak için slash kullanılmış.)

Figure 1.2: DNS'de ve UNIX dosya sisteminde isimlerin okunması:



DNS'de her domain farklı bir örgüt tarafından yönetilebilir. Her örgüt daha sonra kendi domain'nini bir grup subdomain'lere bölebilir ve bu subdomain'lerin sorumluluğunu  diğer örgütlere dağıtabilir. Örneğin, InterNIC edu domain'nini yönetir, ama U.C Berkeley'e berkeley.edu subdomain'i için otorite atar (Figür 1.3). Bu uzaktan bir dosya sistemi mount etmek gibi bir şeydir: dosya sistemindeki belirli klasörler aslında başka hostlarda dosya sistemleri olabilir. Bu başka hostlar dosya sistemlerini uzaktaki bir hosttan mount etmiştir. Örneğin, winken hostundaki administrator (figür 1.3), lokal host'ta /usr/nfs/winken olarak görünen dosya sisteminden sorumludur.




Domain isimleri DNS veritabanında indeksler(fihrist) gibi kullanılır. DNS'deki veriyi bir domain ismine "ataçlanmış" gibi düşünebilirsiniz. Bir dosya sisteminde klasörler, dosyalar ve alt klasörler içerir. Buna benzer şekilde domainler hem hostları hem de subdomainleri içerir. Bir domain, hostları ve domain isimleri domain içinde olan alt domainleri içerir (subdomains whose domain names are within domain.)

Bir network'deki her hostun, host hakkındaki bilgiye işaret eden bir domain ismi vardır (figür 1.4 'e bak) Bu bilgi IP adreslerini, mail routing bilgilerini vs içerebilir. Hostlar ayrıca bir ya da birden fazla domain name alias (takma domain isimlerine)lara sahip olabilir. Bunlar basitçe bir domain isminden (takma, alias) diğerine (resmi ya da canonical domain name) işaret eder. Aşağıdaki figürde, mailhub.nv... canonical isim olan rincon.ba.ca.... için bir alias'tır.

Figür 1.4: Bir alias ile bir canonical isime DNS işaret edilişi (pointing)



Neden bütün bu karmaşık yapı? Nedeni HOSTS.TXT dosyasının yaratmış olduğu problemlerdi. Örneğin, hiyerarşik domain isimleri yapmak, isim çakışması tehlikesini eler. Her domain'in biricik bir domain name'e sahiptir, böylece o domain'i yürüten örgüt, domain'indeki hostları ve subdomainleri isimlendirmede özgürdür. Host ya da subdomain için hangi ismi seçerlerse seçsinler, bu isim bir başka örgütün seçtiği domain isimleri ile çakışmayacaktır. Örneğin, hic.com u çalıştıran örgüt bir hostuna puella ismini verebilir (figür 1.5 te gösterildiği gibi), çünkü bu ismin hic.com ile biteceğini biliyordur.

1-4 BIND'ın tarihi

Paul Mockapetris tarafından yazılmış, ilk defa kurulan Domain Name System'a JEEVES adı verildi. Daha sonraki ise Berkeley'nin 4.3 BSD UNIX sistemleri için Kevin Dunlap tarafından yazılmış BIND'dı. BIND şu anda Internet Software Consortium tarafından desteklenir.

Berkeley Internet Name Domain (BIND) bizim bu kitapta üzerinde duracağımız kurulumdur (implementation). BIND bugüne kadar gelmiş geçmiş en popüler DNS olmuştur. Bir çok UNIX çeşidi için port edilmiş (o sisteme göre program düzenlenmiş) ve bu UNIX'ler tarafından OS'nin standart bir parçası olarak dağıtılmıştır. BIND, hatta Microsoft'un Windows NT'si için bile port edilmiştir.

1-5 DNS kullanmalı mıyım?

Domain Name System bütün kullanışlılığına rağmen, bazı durumlarda bize istediğimiz şeyi vermeyebilir. DNS'ten başka isim çözümleme mekanizmaları vardır, bunların bazıları işletim sisteminizle standart olarak gelebilir. Bazen bir domain'i ve onun isim serverlarını yönetmek için harcanan emek, DNS'in verdiği kara değmez. Diğer yandan öyle durumlar vardır ki, bir domain kurup yönetmekten başka bir seçeneğiniz de olmayabilir. Aşağıda bir karar vermeniz için yardımcı olabilecek bazı rehberler bulunuyor.

1-5-1 Eğer Internet'e bağlıysanız...

...DNS bir zorunluluktur. DNS'i Internetin lingua franca'sı (heralde dev bi sözlük) olarak düşünün: hemen hemen Internet'in bütün network servisleri DNSi kullanır. Bunun içine World Wide Web, elektronik posta, remote terminal access ve dosya transferi dahildir.

Diğer yandan, bu sizin zorunlu olarak kendiniz için bir domain kurup yönetmeniz gerektiği anlamına gelmez. Sadece bir kaç tane hostunuz varsa, parçası olmak için var olan bir domain bulabilirsiniz (bölüm 3. nereden başlamalıyım?a bak). Ya da sizin için bir domain çalıştıracak birini bulabilirsiniz. Eğer bir Internet Servis Sağlayıcısıyla, Internet bağlantısı için anlaşma yapmışsanız, onların sizin için bir domain yönetip yönetmediğini sorun. Hatta hali hazırda bir müşteri olmasanız bile, size belli bir ücret karşılığında yardım edecek kuruluşlar bulunmaktadır.

Eğer bir kaç taneden daha fazla hosta sahipseniz, o zaman muhtemelen kendi domain'ninizin olmasını isteyeceksiniz. Ve eğer domaininiz ve isim serverlarınız üzerinde doğrudan bir kontrol istiyorsanız, o zaman domaini kendiniz yönetmek isteyeceksiniz.


1-5-2 Eğer Internet üzerindeki bir hosta UUCP türünde bir bağlantınız varsa...

...bir domain kurmak iyi bir fikir olur. User@domain-tipi adresleme Internet üzerinde bir standart olmuştur. Bir kez domain kurduğunuzda, Internet üzerinden sizinle mektuplaşlan kişiler, bu basit adresleri kullanarak size mail gönderebileceklerdir. Eğer daha sonra Internet'e bir bağlantı kurmaya karar verirseniz böylece ayrıca hazırlıklı olacaksınız.

Bir domain kurup, user@domain-tipi adresler kullanabilmeniz için Internete bağlı olmanız gerektiği oldukça genel bir yanlış anlaşılmadır. Domain'iniz için Internette isim serverları olarak davranacak hostlara ihtiyaç duyacaksınız, ama bunlar sizin hostlarınız olmak zorunda değildir. Sizin domain'iniz için bedavaya hosting hizmeti vermek isteyen ne kadar insan olduğunu duysanız şaşırırdınız: Internet hala oldukça komşuluk ilişkilerinin olduğu bir yerdir. (bunu yapmak isteyen birini bulamasınız bile, size bunu ucuza yapacak bir şirket bulabilirsiniz.)

1-5-3 Eğer kendi TCP/IP tabanlı internetiniz varsa...

...muhtemelen DNS isteyeceksiniz. Burada internet diyerek, sadece TCP/IP kullanan işistasyonlarından oluşan tek bir Ethernet demek istemiyoruz (eğer öyle olduğunu düşündüyseniz bir sonraki bölümü okuyun) oldukça kompleks bir networklerin network'ünden bahsediyoruz. Belki Appletalk lardan oluşan bir forest a ve bir avuç Apollo token ringine sahipsinizdir.

Eğer internetiniz basit olarak homojen ve hostlarınız DNS'e ihtiyaç duymuyorsa (diyelim büyük bir DECnet'iniz ya da OSI internetiniz var), o zaman buna ihtiyaç duymayabilirsiniz. Ama eğer çeşitli hostlarınız varsa, özellikle bunların bazılar çeşitli UNIXler çalıştırıyorsa, DNS isteyeceksiniz. DNS host bilgisinin dağıtılmasını basitleştirecek ve sizi herhangi bir host table dağıtım şemalarından planlarından zahmetinden kurtaracaktır.

1-5-4 Eğer kendi local area network'ünüz ya da site network'ünüz varsa...

...ve bu network daha geniş olan başka bir networke bağlı değilse , muthemelen DNS kullanmadan devam edebilirsiniz. Microsoft'un Windows Internet Name Service'ini (WINS), host tablolarını, ya da Sun'ın Network Information Service (NIS) ürününü kullanmayı düşünebilirsiniz.

Ama eğer dağıtılmış bir administration a ihtiyaç duyarsanız ya da networkünüzdeki verinin kararlılığını korumakta sorunlar yaşarsanız, DNS sizin derdinize çare olabilir. Ve eğer networkünüz ileride başka bir networke bağlanabilir gibi duruyorsa (sizin internetiniz ya da Internet gibi), şimdi bir domain kurmak akıllıca olurdu.

data_grrr

2- DNS Nasıl Çalışır?

             "...resimler ve konuşmaların olmadığı bir kitap neye yarar?" diye düşündü Alice.

Domain Name System temel olarak bir host bigisi veritabanıdır. Kuşkusuz, bundan çok daha fazlasını alıyorsunuz: tuhaf noktalı isimler, networklenmiş isim serverları, gölgeli bir "isim alanı"Ama şunu aklınızda tutun, nihayetinde DNS'in sunduğu servis internet hostları hakkındaki bilgidir.

Zaten DNS'in bazı önemli yanlarını açıklamıştık, bunlar client-server mimarisi ve DNS veritabanı yapısıydı. Ama çok fazla detaya inmedik.

Bu bölümde, DNS'in çalışma mekanizmasını illüstre edip açıklayacağı. Ayrıca kitabın gerisini okuyabilmeniz (ayrıca domain administratorları ile zekice muhabbet edebilmek için) için gerekli olan terimleri açıklayacağız.
İlk olarak geçen bölümde giriş yaptığımız konseptlere daha detaylı olarak bir bakalım.

2-1 Domain Name Space

DNS'in dağıtılmış veritabanı domain isimleri ile indekslenir. Her domain ismi esasen, domain name space adı verilen büyük ters bir ağaçta sadece bir yoldur. Figür 2.1 de gösterilen, ağacın hiyerarşik yapısı, UNIX dosya sistemine benzer. Ağacın en başında tek bir root bulunur. UNIX dosya sisteminde buna root directory adı verilir ve slash "/" ile temsil edilir. DNS buna sadece "root" der. Bir dosya sistemi gibi, DNS de bir çok yola dallanabilir, bu yollarda her kesişme noktası bir node olarak adlandırılır. Ağacın derinliği 127 level ile sınırlıdır (büyük ihtimalle hiç ulaşmıycağınız bir limit)

Figür 2.1: DNS isim alanının yapısı



2-1-1 Domain Names

Ağaçtaki her node'un 63 karaktere kadar uzun olabilen bir metin etiketi vardır (noktalar olmadan). Boş (null) bir etiket (zero-length) root için ayrılmıştır. Herhangi bir node'un ağaçtaki full domain ismi o node'dan başlayarak root'a kadar giden yoldaki etiketlerin sıralanmasıdır. Domain isimleri her zaman node'dan root'a doğru okunur (ağacın "yukarısına" doğru) ve noktalar yoldaki isimleri birbirinden ayırır.

Eğer root node'un etiketi gerçekte node'un domain isminde görünüyorsa, isim noktayla bitiyormuş gibi gözükür, "www.oreilly.com."da olduğu gibi. (aslında bir nokta ayırıcıyla bitip root'un boş etiketini gösterir.) Root node'un etiketi kendiğiliğinden göründüğü zaman, tek bir nokta "." olarak yazılır, uygunluk açısından. Sonuç olarak, bazı yazılımlar domain name 'deki bu noktayı domain name'in mutlak olduğuna işaret ettiği anlamına yorar. Mutlak bir domain ismi root ile ilişkili olarak yazılır, ve muğlak olmayan bir şekilde node'un hiyerarşideki yerini belirtir. Mutlak bir domain ismine ayrıca fully qualified domain name adı da verilir, kısaca FQDN. Son noktası olmayan isimler bazen root tan başka bir domain ile ilişkili olarak yorumlanır. Klasör isimlerinde, tıpkı takip eden bir slash (/) ın olmamasının sıklıkla mevcut klasörle ilişkili olarak yorumlanması gibi.

DNS, kardeş nodeların -aynı parent ın children ı olan node lar- farklı etiketlere sahip olmasını ister. Bu sınırlama bir domain isminin eşsiz olarak ağaçtaki tek bir node'u tanımlamasını garantiler. Bu sınırlama tam da gerçek bir sınırlama değildir, çünkü etiketler sadece children (çocuklar) arasında eşsiz olmalıdır, ağaçtaki bütün nodelar arasında değil. Aynı sınırlama UNIX dosya sisteminde de geçerlidir: İki kardeş klasöre aynı ismi veremezsiniz. Tıpkı iki hobbes.pa.ca.us node'una aynı isim alanında sahip olamayacağınız gbi, iki tane /usr/bin klasörüne de sahip olamazsınız (figür 2.2) Bununla beraber, hem hobbes.pa.ca.us hem de bir hobbes.lg.ca.us node una sahip olabilirsiniz.

Figür 2.2: Domain isimlerinde ve UNIX dosyayollarında eşsizliği sağlama



2-1-2 Domainler

Bir domain temel olarak domain isim alanındaki bir altağaçtır. Bir domain nin domain ismi o domain nin en başındaki node un domain ismiyle aynıdır. Örneğin, purdue.edu domain ninin başındaki node un ismi purdue.edu dur, Figür 2.3 te gösterildiği gibi.

Figür 2.3: purdue.edu domain i




Tıpkı bir dosya sisteminde, /usr klasörünün başında /usr adında bir node bulmayı umduğunuz gibi. Figür 2.4





Altağaçtaki herhangi bir domain isminin domain'in bir parçası olduğu düşünülür. Bir domain ismi birden çok altağaçta olabileceği için, bir domain ismi  ayrıca birden çok domain'de de olabilir.  Örneğin, pa.ca.us domain ismi ca.us domain'ninin bir parçasıdır ve ayrıca us domain'ninin bir parçasıdır, figür 2.5te gösterildiği gibi.

Figür2.5: Birden çok domain'de bir node



Sonuç olarak soyut anlamda bir domain, domain name space'te sadece bir altağaçtır. Peki eğer bir domain basitçe domain isimleri ve diğer domainlerden oluşuyorsa, o zaman bütün o hostlar nerede? Domainler host gruplarıdır öyle değil mi?

Hostlar oradadır, domain isimleri ile temsil edilirler. Hatırlayın, domain isimleri DNS veritabanı içinde sadece indekslerdir. "Hostlar" münferit hostlar hakkındaki bilgiye işaret eden domain isimleridir. Ve bir domain, domain isimleri bu domain içinde olan bütün hostları içerir. Hostlar mantıksal olarak sıklıkla coğrafik olarak ya da organizasyonel bağlamda ilişkilendirilir. Network, adres, ya da donanımsal anlamda ilişkilendirilmek zorunda değillerdir. On farklı hosta sahip olabilirsiniz, ve her biri farklı bir networkte olabilir ve her biri belki farklı bir ülkede olabilir, yine de hepsi aynı domain'de olabilir. [2]

[2] Bir uyarı: Domain Name System'daki domainleri Sun's Network Information Service (NIS) teki domainlerle karıştırmayın. Bir NIS domain'i ayrıca bir grup hostu belirtmesine rağmen, ve iki tip domain de benzer şekilde isimleri oluşturmasına rağmen, konseptleri tamamen farklıdır. NIS hiyerarşik isimler kullanır fakat hiyerarşi orada biter: Aynı NIS domain'nindeki hostlar, kullanıcılar ve hostlar hakkındaki belirli veriyi paylaşır, fakat bu hostlar NIS isim alanında, başka NIS domainlerindeki veriyi bulmak için yönlenemez. Muhasebe ve güvenlik hizmetleri sağlayan NT domainlerinin de ayrıca DNS domainleri ile hiç bir ilişkisi yoktur.

Ağacın yapraklarındaki domain isimleri genel olarak münferit hostları temsil eder, ve bunlar network adreslerine, donanım bilgisine, mail routing bilgisine  işaret edebilir. Ağacın içindeki domain isimleri bir host isimlendirebilir ve domain hakkındaki bilgiye işaret edebilir. İç domain isimleri hem kendisinin uygun düştüğü domain'i  hem de networkdeki özel bir hostu temsil edebilir. Örneğin, hp.com hem Hewlett-Packard Şirketi'nin domain ismi hem de HP'nin web server'ını çalıştıran hostun domain ismidir.

Bir domain ismi kullanırken yanıt olarak alacağınız bilginin tipi, o domain ismini kullandığınız bağlama bağlıdır. hp.com 'daki birine bir mail göndermek geriye mail routing information olarak döner, bununla beraber domain ismini telnetlemek host bilgisine bakılmasına yol açar. Figür 2.6, örneğin hp.com'un IP adresi). [3]

   [3] Bu kitapta domain ve subdomain kavramları sıklıkla birbirinin yerine kullanılır.     Burada, subdomain'i sadece relatif bir kavram olarak kullanıyoruz: eğer subdomain'in   root'u domain içerisindeyse, domain bir başka domain'in subdomainidir.

Figür 2.6: Hem yapısal hem de host verisi olan bir iç node




Bir domain'in bir başka domain'in subdomain'i olup olmadığını anlamanın kolay bir yolu domain isimlerini karşılaştırmaktır. Bir subdomain'in domain ismi o subdomain'in parent domain ismiyle biter. Örneğin, la.tyrell.com domaini tyrell.com un subdomaini olmalı çünkü tyrell.com ile bitiyor. Benzer olarak, ayrıca com'un subdomainidir.

Domain'lerin subdomain'leri olarak anlatılmaktan başka, domainler sıklıkla levelleri ile anlatılır. Mailing listler ya da Usenet newsgrouplarda, top-level domain ya da second-level domain gibi kavramlar görebilirsiniz. Bu kavramlar temel olarak bir domainin domain name space teki pozisyonunu belirtir.

·   Top-level bir domain, root'un bir çocuğudur (child).
·   First-level domain root'un (top-level domain) bir çocuğudur.
·   Second-level domain first-level domain'in bir çocuğudur. Ve böyle devam eder.




2-1-3 Kaynak Kayıtları

Domain isimleriyle ilgili olan veri resource records'ta (kaynak kayıtları) tutulur ya da RRs şeklinde kısaltılır. Kayıtlar sınıflara bölünür, her biri bir çeşit networke ya da software'e aittir. Şu anda internetler için (herhangi TCP/IP tabanlıi internet), Chaosnet protocols tabanlı networkler için, ve Hesiod yazılımını kullanan networkler için sınıflar vardır. (Chaosnet çok eski bir network yapısıdır.)

Classlar (sınıflar) içinde internet classı en yaygın olanıdır. (şu anda Chaosnet classını kullanan birisi olup olmadığından gerçekten emin değiliz ve Hesiod kullanımı ise çoğunlukla MIT'de gerçekleşir.) Burada internet class üzerinde yoğunlaşacağız.

Eğer buradaki bilgi yüzeysel görünürse endişelenmeyin -- internet classındaki kayıtlara daha sonra daha detaylı bakacağız. Genel kayıtlar Bölüm 4 BIND'ı Kurma bölümünde anlatılıyor.

2-2 Internet Domain Name Space (Internet Domain İsim Alanı)

Şimdiye kadar , domain name alanının teorik yapısından ve içinde ne tip verilerin saklandığından bahsettik, hatta verdiğimiz örneklerle (kimisi kurgusal)içinde ne tip isimlerin bulunabileceği konusunda bile bazı ipuçları verdik. Ama bu kadarı size Internetteki domain isimlerini çözmenize yetmeyecek.

Domain Name Sistemi domain isimleriinde  kullanılan etikler için çok fazla kural empoze etmez, ve belirli bir düzeyde etiketlere herhangi özel bir anlam iliştirmez. Domain name alanının bir parçasını yönetmeye başladığınızda, domain isimleri için istediğiniz şeyleri seçebilirsiniz. Kendi subdomaininizi A'dan Z'ye istediğiniz şekilde isimlendirebilirsiniz, kimse sizi durduramaz (yine de değiştirmeniz konusunda ciddi tavsiyelerde bulunabilirler)

Varolan Internet domain isim alanının, bununla beraber bazı kendiliğinden kendine empoze olmuş bir yapısı da bulunmaktadır. Özellike yukarı level domainlerinde, domain isimleri bazı kesin gelenekleri takip eder (kurallar değil,gerçekten çünkü kırılabilir ve kırılmışlardırda). Bu gelenekler domain isimlerinin tamamen kaotik bir şekle bürünmesini engeller. Bu gelenekleri anlamak eğer bir domain ismini deşifre ediyorsanız çok değerli bir şeydir.

2-2-1 Top-Level Domainler

Orijinal top-level domainleri Internet domain space i örgütsel olarak 7 domaine bölmüştür.

·   com
ticari organizasyonlar, Hewlett-Packard (hp.com), Sun Microsystems (sun.com), ve IBM (ibm.com) gibi
·   edu
eğitimsel organizasyonlar, U.C Berkeley (berkeley.edu) ve Purdue University (purdue.edu) gibi
·   gov
hükümet organizasyonları, NASA (nasa.gov) gibi.
·   mil
askeri organizasyonlar, U.S Army (army.mil) gibi.
·   net
networking organizasyonları, NSFNET (nsf.net) gibi.


·   org
ticari olmayan organizasyonlar, Electronic Frontier Foundation (eff.org) gibi.
·   int
uluslararası organizasyonlar, NATO (nato.int) gibi


arpa adında bir diğer top-level domain, ARPAnet'in host tablolarından DNS'e geçişi sırasında kullanıldı. Bütün ARPAnet hostları arpa altında host isimlerine sahipti, böylelikle kolayca bulunabiliniyorlardı. Daha sonra organizasyonel top-level domainlerin çeşitli subdomainlerine taşındılar. Bununla beraber, arpa domaini hala bir şekilde kullanımda kalmıştır, daha sonra bu konuya geleceğiz.

Örneklerde oldukça belirgin olan bir milliyetçi önyargı farketmiş olabilirsiniz: hepsi de Birleşik Devletler örgütleri. Bunu anlamak -- ve bağışlamak- daha kolay olacaktır, eğer Internetin ARPAnet, yani bir Birleşik Devletler projesi olarak başladığını düşünürseniz. Kimse ARPAnetin bu kadar başarılı olacağını öngörememişti, ya da bugünki Internet gibi uluslararası bir düzeye geleceğini kimse tahmin etmemişti.

Günümüzde, bu orijinal domainler generic top-level domains olarak adlandırılır, ya da gTLDs. Internetin hızlı gelişimini karşılamak için ve daha çok domain name "space" için bunu okuduğunuz sırada bu domainlere yenileri eklenmiş olabilir. Daha çok bilgi için http://www.gtld-mou.org/ a bakın.

Internetin uluslararası ihtiyaçlarını karşılamak için, Internet domain alanı kurucuları uzlaşmaya vardı. Bütün top-level domainlerin örgütsel tanımlamalarında ısrar etmek yerine, coğrafik dizaynların da olması gerektiğine karar verdiler. Yeni top-level domainler münferit ülkelere uygun olacak şekilde ayrılmıştır (ama zorunlu olarak yaratılmamışlardır). Domain isimleri zaten var olan bir uluslararası standart olan ISO 3166'yı kullanmıştır. Bu standart resmi olarak, dünyadaki her ülkenin isimlerini iki harf şeklinde kısaltır. [4]

                [4] Büyük Britanya hariç. ISO 3166'ya göre Büyük Britanyanın top-level domain'i gb olmalı. Bunun yerine bu ülkedeki çoğu organizasyon uk'yi kullanıyor. Ayrıca yolun yanlış tarafında da gidiyorlar tabi.

2-2-3 Domain İsimlerini Okuma

lithium.cchem.berkeley.edu

             berkeley.edu UC Berkeley'nin domain ismidir (bu domain, edu domaininde bulunduğu için bir üniversite olduğunu anlamanız gerek.) cchem, berkeley.edu'nun subdomainidir ve açılımı College of Chemistry dir. En sonunda, lithium domaindeki özel bir hosttur -- ve muhtemelen yüzlercesi içinde.

winnie.corp.hp.com
   
           Bu örnek biraz daha zor ama o kadar değil. hp.com Hewlett-Packard'a aittir. corp subdomaini şüphesizki onların corporate headquartersı. Ve winnie muhtemelen birisinin düşündüğü sadece aptalca bir host ismi.

fernwood.mpk.ca.us

           Burada us domaini yapısını anlamanız gerekiyor. ca.us açıkça California'nın domain'i, ama mpk herşey olabilir. Bu durumda, bunun Menlo Park's domaini olduğunu bilmek San Fransico'yu tanımıyorsanız oldukça zor olacaktır.

daphne.ch.apollo.hp.com

Bu örneği bütün domain isimlerinin sadece dört etiketi olduğunu düşünmeyesiniz diye ekledik. apollo.hp.com, hp.com'un Apollo Computer subdomain'i (HP Apolloyu aldığında, ayrıca Apollonun internet domainini de almış oldu, böylece apollo.com, apollo.hp.com oldu). ch.apollo.hp.com Apollo'nun Chelmsford Massachusetts site ı. Ve daphne Chelmsforddaki bir host.

2-3 Delegasyon (Delegation)

Domain Name System'ın dizaynının ana amaçlarından birinin yönetimin desentralizasyonu olduğunu hatırlıyor musunuz? Bu delegasyon aracılığıyla sağlanır. Domainleri delege etmek, bir işte görev bölüşümü yapılmasına çok benzer. Bir yönetici büyük bir projeyi daha küçük görevlere bölerek, bu görevlerin herbirini farklı çalışanların sorumluluğuna dağıtır (delege eder).

Bunun gibi, bir domaini yöneten bir organizasyon bu domaini subdomainlere bölebilir. Bu subdomainlerden herbiri başka organizasyonlara delege edilebilir. Bunun anlamı o örgütün  kendisine verilen subdomaindeki bütün verilerden sorumlu olduğudur. Verileri serbestçe değiştirebilir ve hatta bu kendi subdomainini başka subdomainlere bölüm bunları başkalarına delege edebilir. Parent domain sadece subdomainin verisinin kaynaklarına işaret eden eden işaretçiler içerir, so it can refer queries there. stanfor.edu domaini örneğin, Stanford'da üniversitenin ağlarını çalıştıranlara delege edilmiştir. (figür 2.7)

Figür 2.7: stanford.edu Stanford Üniversitesine delege edilmiş



Bütün örgütler bütün domainlerini delege etmez, bütün yöneticilerin bütün işleri başkasına dağıtmaması gibi. Bir domain bir çok subdomaine sahip olabilir ve aynı zamanda subdomainlere ait olmayan hostları da içerebilir. Örneğin, Acme Corporation'ın Rockaway'de bir bölümü ve Kalamazoo'da bir merkezi vardır. Rockaway'deki host rockaway.acme.com subdomainini, Kalamazoo'daki kalamazoo.acme.com subdomainini alabilir, ama Birleşik Devletlerin orasına burasına dağılmış bir kaç host acme.com altında, herhangi bir subdomain altında duracağından daha iyi durur.

Subdomainlerin nasıl yaratılacağından ve delege edileceğinden daha sonra bahsedeceğiz. Şimdilik sadece delegasyonun anlamı olan, başka bir örgüte bir subdomain vermek yoluyla sorumluluğun dağıtılmasını anlamanız yeterli.

2-4 Name Servers and Zones (isim serverları ve alanlar)

Domain name alanı hakkındaki bilgileri tutan programlara name servers denir. Name server genelde zone adı verilen, bir dosyadan ya da başka bir name server'dan çağrılan, domain name alanının bir parçası hakkında tam bütün bir bilgi tutar. Name server'ın o zaman o zone için otoriteye sahip olduğu söylenir. Name serverları birden çok zone için de autoritative olabilir.
Zone ve domain arasındaki fark önemlidir ve çok ince bir fark vardır. berkeley.edu, hp.com gibi bütün second-level ve daha aşağı olan domainler delegasyon yoluyla daha küçük yönetilebilir birimlere bölünür. Bu birimlere zone adı verilir. Figür 2.8 de gösterilen, edu domaini, berkeley.edu yu purdue.edu yu ve nwu.edu yu içeren bir çok zone a ayrılmıştır. Domain'in başında ayrıca edu zone'u bulunur. edu yu işletenlerin edu yu bölmeleri çok doğaldır, yoksa edu nun bütün subdomainleri ile kendileri ilgilenmek zorunda kalırlardı. berkeley.edu yu Berkeley'e vermek mantıklı olandır. Peki edu'yu yönetenlere ne kalır? Çoğunlukla edu'nun subdomainleri hakkındaki delegasyon bilgileri.

Figür 2.8: edu domaini zone lara ayrılıyor



Figür 2.9 da gösterildiği gibi berkeley.edu subdomaini de delegasyon yoluyla bir çok zone a ayrılıyor cc, cs, cs, me, ve daha fazlası. Bu subdomainlerin herbiri bir takım isim serverlarına delege edilir, bazıları ayrıca berkeley.edu için authoritative'dir. Bununla beraber, bu zone lar hala ayrıdır, ve tamamen farklı bir grup authoritative name servera sahip olabilir.

Figür 2.9: berkeley.edu domain'i zone'lara ayrılıyor



Bir zone, delege edilmiş subdomainlerin dışındaki kendi isminde olan domain isimlerini içerir. Örneğin, ca (Kanada) top-level domaininin, ab.ca, on.ca ve qc.ca gibi vilayet subdomainleri olabilir. ab.ca, on.ca, ve qc.ca domainlerinin otoriteleri her vilayetteki name serverlara delege edilebilir. ca domaini, ca içindeki bütün verilere sahiptir, buna ek olarak, ab.ca, on.ca, ve qc.ca nın da tüm verilerine sahiptir. Ama zone olan ca sadece ca'daki veriyi içerir (Figür 2.10'a bak). Bu veri de muhtemelen delege edilmiş subdomainler için pointerlardan oluşur.

Eğer bir domain'in subdomaini delege edilmemişse, yine de zone, domain nameleri ve subdomaindeki veriyi içerir. Böylece ca domaininde  bc.ca(British Columbia) ve sk.ca (Saskarchewan) subdomainleri varolabilir, ama aynı zamanda delege edilmemiş de olabilir. (Belki B.C ve Saskatchewandaki otoriteler henüz kendi subdomainlerini yönetmeye hazır değillerdir, ve ca domainini yönetenler Canada'nın bütün köyleri için hemen subdomain açmak isteyebilirler.)

Figür2.10: ca domaini...



Figür 2.11: ...ca zone'una karşı



Şimdi name serverların neden domainler yerine zone ları yükledikler, daha açık oldu böylece: bir domain, name serverın ihtiyaç duyacağından daha fazla veriye sahip olabilir. [6] Bir domain başka name serverlara delege edilmiş verileri içerebilir. Zone sa delegasyonla sınırlandırıldığı için asla delege edilmiş verileri içermeyecektir.

                  [6] Bir root name serverın, root zone u yerine root domainini yüklemeye çalıştığını bir düşünün: bütün isim alanını yüklüyor olurdu!

Eğer henüz yeni başlıyorsanız, domaininizin muhtemelen hiç subdomaini olmayacak. Bu durumda, yapılan bir delegasyon da olmadığı için domaininiz ve zone'unuz aynı veriyi içerecektir.

2-4-1 Domainleri delege etme

Henüz domaininizi parçalara ayırıp delege etmek zorunda olmasanızda, bir domainin nasıl delege edildiği hakkında biraz daha fazla bilmenin yardımı olacaktır. Delegasyon, soyut anlamda domaininizin bir parçasının sorumluluğunu başka bir örgüte devretmenizdir. Gerçekte olansa, subdomain otoritelerin farklı name serverlara atanmasıdır. (server değil de serverlar dediğimize dikkat edin.)

Veriniz, delege ettiğiniz subdomain hakkında bilgi içermek yerine, subdomain için yetkisi(otorite) olan name serverlara işaret eden işaretçiler içerir. Şimdi bu durumda  eğer serverlarınızdan birisi subdomaindeki bir veri için sorgulansa, ulaşılması gereken doğru name serverların olduğu bir liste çıkarabiliir.

data_grrr

2-4-2 Name Serverların çeşitleri

DNS iki farklı tipte name server tanımlar: primary masters ve secondary masters. Bir zone için primary master olan name server, zone için olan bilgiyi hostundaki bir dosyadan okur. Bir zone için secondary master olan name server, zone bilgisini, o zone için otoritatif olan, onun master server'ı adı verilen başka bir name server'dan alır. Çoğunlukla master server zone'un primary master'ıdır, ama bu bir zorunluluk değildir: bir secondary master zone bilgisini bir başka secondary masterdan yükleyebilir. Bir secondary çalışmaya başladığında, kendi master name server ı ile kontak kurar ve eğer gerekliyse, zone verisini  kendine çeker. Buna zone transfer adı verilir. Bugünlerde, secondary master name server için tercih edilen isim  slave'dir. Yine de hala çoğu insan ve Microsoft'un DNS Manager'ı secondary diye tanımlayabilir.

Bir zone'un primary master name server'ı da slave name server'ı da o zone için otoritatiftir.  Küçümsenen isimlerine rağmen, slaveler ikincı sınıf name serverlar değildir. DNS bu iki tip isim serverını yönetim daha da kolaylaşsın diye sağlar.  Bir kez zone'unuz için bir veri yaratıp, primary master name server kurduğunuzda, zone için yeni name serverları açarken veriyi hosttan hosta kopyalayıp aptallaşmak zorunda değilsiniz. Sadece basitçe verilerini zone'un primary master'ından yükleyen slave name serverları kurarsınız. Bir kez kurulduklarında, gerekli olduğunda slaveler yeni zone verilerini transfer edeceklerdir.

Slave name serverlar önemlidir çünkü herhangi bir zone için birden fazla name server kurmak iyi bir fikirdir. Birden fazlasını, yüklemenin yayılması, hostların yakınında birer name server ı olması için isteyeceksiniz. Slave name serverları kullanmak bu işlemi yapılabilir hale getirir.

Bir primary master name server ı ya da slave name server ı kendine has name serverlar olarak tanımlamak biraz eksik olurdu doğrusu. Daha evvel, bir name serverın birden fazla zone için otoritativ olabileceğini söylemiştik. Buna benzer, bir name serverı bir zone için primary master ken aynı zamanda başka bir zone'un slave name server'ı olabilir. Ama çoğu name serverı yükledikleri çoğu zone için ya primary dir ya da slave dir. Böylece eğer özel bir name serverından primary ya da slave olarak bahsediyorsak, biz bunun yüklediği çoğu zone için primary ya da slave olduğundan bahsediyoruz.

2-4-3 Veri Dosyaları

Primary master name serverların zone datalarını yükledikleri dosyalara zone data dosyaları ya da sadece data dosyaları denir. Biz çoğu zaman, database'in kısaltması olan db files'ı kullanıyoruz. Slave name serverları da ayrıca zone datasını data dosyalarından yükleyebilir. Slaveler genelde bir master name serverdan data files'a transfer ettikleri  zone datasını yedeklemek için konfigüre edilir.  Eğer slave daha sonra öldürülür ve yeniden başlatılırsa, önce backup(yedek) data dosyalarını okuyacak sonra da verinin güncel olup olmadığına bakacaktır. Bu hem master ölürse, bir data kaynağı sağlar hem de eğer değişmediyse zone datasını transfer etme ihtiyacının üstesinden gelir.

Data dosyaları zone'u tanımlayan kaynak kayıtları (RRs) içerir. Kaynak kayıtları zonedaki bütün hostları tanımlar ve bütün subdomain delegasyonlarına işaret eder. BIND ayrıca bir data dosyasının başka data dosyalarının içeriklerini içermesine izin verir, bunun için özel direktifler kullanır. C programlamadaki #include ifadesine benzer bu.

2-5 Resolvers

Resolverlar, name serverlara erişen clientlardır. Domain name space'ten bilgi edinmek isteyen host üzerindeki programlar resolver'ı kullanır. Resolver aşağıdakileri halleder:

·   Biri name server'ı sorgulama
·   Yanıtları yorumlama (yanıt resource record ya da bir hata olabilir)
·   Bilgiyi, daha önceden talep eden programlara geri götürme.

BIND'da resolver, telnet ve ftp gibi programlara linklenmiş sadece bir takım kütüphane rutinleridir (library routines). Hatta bu ayrı bir işlem bile değildir. It has the smarts to put together a query, yeniden göndermek için ve bir yanıt beklemek için, ve bir yanıt gelmediyse yeniden sorgulamak için, ama hepsi budur. Sorgulamaya yanıt bulmanın verdiği yükün çoğu  name server'a biner. DNS specs bu tip resolverlara, stub resolver der.

Daha zeki resolverları olan başka DNS uygulamaları da bulunmaktadır, örneğin name serverlarından zaten daha önceden gelmiş bilgilerden bir cache yapabilmek gibi sofistike şeyler. [7] Ama bunlar BIND içindeki stub resolver uygulaması kadar yaygın değildir.

     [7] Rob Austein'in CHIVES resolver'ı TOPS-20 için cache yapabilir mesela.



2-6 Resolution (çözümleme)

Name serverlar, domain name space'ten veri getirmekte beceriklidirler. Sadece autoritative oldukları zone'un bilgisini size vermekle kalmaz, ayrıca domain name space'te autoritative olmadıkları veriyi de arayabilirler. Bu işleme name resolution ya da basitçe resolution denir.

Name space ters bir ağaç olarak yapılandırıldığı için, name server'ın ağaçtaki herhangi bir noktaya giden yolunu bulması için, sadece tek bir parça bilgiye ihtiyacı vardır: domain isimleri ve root name serverlarının adresleri (bu bir parçadan fazla mı?) Bir name server, domain name space'teki herhangi bir isim için, bir root name server'ına sorgulama yapabilir ve root name serverı yolunun üzerindeki name serverı çalıştıracaktır.

2-6-1 Root Name Servers

Root name serverları, her bir top-level domaini için nerede yetkili(otoritatif) bir name server bulacağını bilir. (aslında, root name serverlarının çoğu jenerik top-level domainleri için yetkilidir.) Herhangi bir domain ismi için bir sorgu verildiğinde, root name serverları en azından aranan domainin içinde olduğu top-level domainleri için yetkili olan name serverlarının adreslerini ve isimlerini sağlayabilir. Ve top-level name serverları aranan domainin içinde olduğu second-level domainler için yetkili olan name serverlarının bir listesini sağlayabilir. Sorgulanan her name server, ya cevabı kendisi verir ya da sorgulayıcıya yanıta nasıl daha yakınlaşacağı hakkında bilgi verir.

Root name serverları açıkça görülüyorki adres çözümlemesinde önemlidir. Bu kadar önemli olmaları sebebiyle, DNS bu root name serverlarının yükünü hafifletmek için çeşitli mekanizmalar kullanır (caching gibi, daha sonra anlatıcaz bunu). Sonuçta diğer bilgilerin yokluğunda, çözümleme root name serverlarında başlamalıdır. Bu DNS'in işletiminde root name serverleri son derece kritik bir noktaya koyar. eğer bütün Internet root name serverları bir süre için erişilemez olsaydı, Internetteki bütün çözümleme işlemleri başarısız olurdu. Bunu önlemek için, Internet'in on üç tane root name server'ı vardır. İkisi MILNET üzerindedir, Birleşik Devletlerin Internetteki payı bir tanesi SPAN, NASA'nın internetidir iki tanesi Avrupa'da bir tanesi de Japonaya'dadır.

Bir çok sorgulama için odak noktası olmaları rootları meşgul tutar on üç taneyle bile her root servera giden trafik çok yoğundur. Server yöneticileri arasında yapılan son gayriresmi bir araştırma göstermiştir ki bazı rootlar saniyede binlerce sorgulama alıyor durumda.

Root name serverlara binen yüke rağmen, Internetteki çözümleme gayet iyi çalışır. Figür 2-12 gerçek bir domaindeki gerçek bir hostun adresinin çözümleme sürecini  domain name space içinde ilerleme şekliyle gösteriyor.


Figür 2-12: girigiri.gbrmpa.gov.au 'nun Internet üzerinde çözülümü




Lokal name server'ı  girigiri.gbrmpa.gov.au adresi için bir root name server'ını sorgular ve au name serverlarına refere (au ismini verir) edilir. Lokal name serverı aynı soruyu au name serverına sorar ve gov.au name serverlarına refere edilir. gov.au name serverı lokal name serverı gbrmpa.go.au name serverlarına refere eder. Nihayetinde, lokal name serverı gbrmpa.go.au ya adresi sorar ve yanıtı alır.

2-6-2 Recursion

Geçen örnekte serverlar arasında yapılan iş bakımından büyük bir farklılık gözünüze çarpmış olabilir. Name serverlarından dördü sorgulamalara zaten bildikleri en iyi cevapları -çoğunlukla başka name serverlara refere ederek- verdiler. Bu serverlar istenen veriyi bulmak için kendi sorgulamalarını yollamak zorunda değildiler. Ama bir name server- resolver tarafından sorgulanan- kendisine gelen referansları bir cevap alana kadar takip etmek zorundaydı.

Neden lokal name serverı basitçe resolverı başka bir name servera refere edemedi? Çünkü bir stub resolverın herhangi bir referansı takip etme yeteneği zekası yoktu. Ve lokal name serverı nasıl anladı bir referansla cevap vermeyeceğini? Çünkü resolver recursive bir sorgulama yaptı.

Sorgulamalar iki çeşittedir, recursive ve iterative (nonrecursive de denir). Recursive sorgulamalar sorgulama gerçekleştiğinde yükün çoğunu sorgulama yaptığı name serverına bindirir. Recursion, ya da recursive sorgulama (query) sadece, recursive sorgulamalar aldığında bir name serverın yaptığı çözümleme işlemine verilen addır.

Iterarion ya da iterative resolution, diğer yandan, bir name serverı iterative query aldığında o name serverı tarafından yapılan çözümleme işlemine verilen addır.

Recurison'da bir resolver belirli bir domain name hakkındaki bilgi için bir name serverına recursive bir sorgu gönderir. Sorgulanan name serverı böylelikle istenen veriyle ya da istenen verinin varolmadığını ya da belirtilen domain name'in olmadığın belirten bir hatayla cevap vermeye zorlanır. Name serverı bu durumda farklı bir name serverına referans veremez, çünkü sorgu recursive di.
      [8] BIND 8 name serverı recursive sorgulamaları reddetmek üzere konfigüre edilebilir Bölüm 10 Gelişmiş Özellikler ve Güvenlik 'e nasıl ve niye gibi soruları soruyorsan bak.

Eğer sorgulanan name serverı istenen veri için authoritative değilse, cevap için başka name serverlarını sorgulamak zorundadır. Diğer name serverlarına recursive sorgulamalar gönderebilir, böylece onları bir cevap bulmaları ve geri getirmeleri için zorlayacaktır. Ya da iterative sorgular göndererek aradığı domain name'ine muhtemelen daha yakın olan bir name servera refere edilebilir. Mevcut kurulumlar kibardır ve ikincisini yapar, bir cevap bulana kadar referansları takip eder.

     [9] Buna bir istisna çözümlenmemiş sorgulamaları, bu iş dizayn edilmiş bir name serverına yönlendiren, ve adına forwarder denilen bir name serverıdır. Forwarderlar nasıl kullanıldığı hakkında daha çok bilgi için Bölüm 10'a bak.

Yanıtını kendisinin veremediği recursive bir sorgulama alan bir name serverı, "en yakın" bildiği name serverlarını sorgulayacaktır. En yakın bilinen name serverları aranan domain name'ine en yakın olan zone'da authoritative olan serverlardır. Örneğin, name serverı girigiri.gbrmpa.gov.au domain name'i için bir recursive sorgulama alırsa, ilk önce girigiri.gbrmpa.gov.au için olan name serverlarını bilip bilmediğini kontrol edecektir. Eğer biliyorsa sorguyu onlardan birine gönderecektir. Eğer bilmiyorsa, gbrmpa.gov.au için olan name serverlarını bilip bilmediğini kontrol edecektir. Onu da bilmiyorsa gov.au yu deneyecek sonra ise au yu. Kontrolün sonlanmasının garantilendiği yer root zone'udur. Çünkü her name serverı root name serverlarının domain name ve adreslerini bilir.

En yakın bilinen name serverını kullanmak, çözümleme işleminin olabildiğince çabuk tamamlanmasını sağlar.  waxwing.ce.berkeley.edu adresi için bir recursive sorgu alan bir berkeley.edu name serverı, root name serverlara danışmamalıdır ce.berkeley.edu name serverlarına basitçe bu sorguyu iletebilir. Buna benzer şekilde, ce.berkeley.edu name serverlarından henüz yeni bir domain name'i bakmış olan bir name serverı, başka bir ce.berkeley.edu ya da berkeley.edu domain name'i için çözümlemeye rootlardan başlamamalıdır bu konuya bir sonraki bölüm olan cachingde bakacağız.

2-6-3 Iteration

Diğer yandan, iterative çözümleme, sorgulanan name serverından  o kadar çok bir iş istemez. Iterative çözümlemede, bir name serverı sadece zaten bildiği en iyi yanıtı sorgulayana geri verir. Ekstra bir sorgulama yapması gerekmez. Sorgulanan name serverı 


istenen veriyi aramak için local datasına danışır (sözünü ettiğimiz cache ini de içeren). Eğer datayı orada bulamazsa yapabileceği en iyi şeyi yapıp sorgulayıcıya sorgulayacağı adresleri verir. Bunlar genelde en yakın bilinen name serverların domain name ve adresleridir.

bir çözümleme işlemi bütün olarak ele alındığında neye tekabül ettiği şekil 2-13e benzer


Şekil 2-13: resolution işlemi




Bir resolver, lokal name serverı sorgular, sonra resolver için bir yanıt bulmak üzere başka name serverları sorgulanır.  Sorguladığı her name serverı onu domain name space içinde daha aşağıdaki zonelardan yetkili olan name serverlara, aradığı domain name'in daha yakınına referans verir. Nihayetinde, lokal name serverı, yanıtı veren bir authoritative name serverı sorgular.

2-6-4 Mapping Adresses to Names  (adresleri isimlere haritalama)

Şimdiye kadar anlattığımız çözümleme işleminde anlatmadığımız ama bu işlemde son derece önemli bir yeri olan bir işlevsellik de adreslerin geriye isim olarak nasıl çevrildiğidir. Adress-to-name mapping biz insanların çıktıları okuyup yorumlayabilmesi için kullanılır. (log dosyalarında mesela). Ayrıca bazı authorization kontrollerinde de kullanılır. UNIX hostları adresleri, domain namelere çevirip (map) .rhosts ve hosts.equiv dosyalarıyla karşılaştırmak için kullanır mesela. Host tablosu kullanırken, adress-to-name mapping önemsizdir (trivial). Bir adres için host tablosunda doğrudan bir zincirleme tarama gerektirir. Tarama listelenen resmi host name i bulur. DNS'de bununla beraber, adress-to-name mapping bu kadar basit değildir. Adresleri içeren, domain name space'teki data, isim yoluyla indekslenir.  Bir domain name verildiğinde, bir adres bulmak nispeten kolaydır.  Ama adresi verilmiş bir domain name'i bulmaya çalışmak  her domain name'e iliştirilmiş veri için yorucu bir arayış gerektirirdi.

Aslında, çok daha iyi, hem verimli hem de zekice olan bir çözüm var. Domain name'inden gittiğimizde madem veriyi bulmak kolay, öyleyse neden domain name space'te adresleri etiket olarak kullanan bir bölüm yaratmıyalım? Internet'in domain name space'inde name space'in bu bölümü  in-addr.arpa domainidir.

in-addr.arpa domainindeki nodelar noktalı-octet olan IP adreslerinden sonra etiketlenir. in-addr.arpa domaini, örneğin, 256 subdomaine sahip olabilir ve her biri IP adresinin ilk octetindeki değere uygun düşen şekilde olabilir. Bu subdomainlerinse herbiri yine 256ya kadar subdomaine sahip olabilir ve bu da ikinci octete uygun düşer. Nihayetinde, 4 kat aşağıda, son octete iliştirilmiş resource recordları vardır, bu o IP adresindeki host ya da networkün full domain nameini verir. Bu durum bu domanini gerçekten korkunç derecede büyük yapar. in-addr.apra, şekil 2.14de de gösterildiği gibi Internetteki her IP adresini karşılayabilir.

Şekil 2-14: addr.arpa domaini





IP adresi ters görünür çünkü isim yapraktan, köke doğru okunur. Örneğin, eğer winnie.corp.hp.com'un IP adresi 15.16.192.152 ise, bunun karşılığı olan  in-addr.arpa subdomaini 152.192.16.15.in-adrr.arpa'dır. ki bu da winnie.corp.hp.com. adresini geriye verir.

IP adresleri name space te tam tersi yönde temsil edilebilirdi, IP adresinin ilk okteti, in-addr.arpa domainin en altında olacak şekilde. Bu şekilde, IP adresi domain namede düz yoldan okunurdu.

Bununla beraber IP adresleri  tıpkı domain nameler gibi hiyerarşik bir yapıya sahiptir. Network numaraları aynı domain nameler gibi gereksinenlere dağıtılmıştır, ve bu şekilde administratorlar adress alanlarını subnetlere ayırıp, bu rakamlara delegasyon verebilir. Fark, IP adresleri soldan sağa doğru gidildikçe daha da özelleşirken, domain nameler sağdan sola gidildikçe özelleşir. Şekil 2-15 ne demek istediğimiz gösteriyor.

Şekil 2-15: Hiyerarşik isim ve adresler




IP adresinin ilk oktetlerini ağaçta en yükseğe koymak administratorlara in-addr.arpa domainleri için network hatları boyunca otorite delege etme olanağı sağlar. Mesela, IP adresleri 15 ile başlayan bütün hostların, reverse mapping bilgisini içeren 15.in-addr.arpa domaini, 15.0.0.0 networkündeki administratorlara delege edebilir. Bu eğer oktetler zıt yönde görünmüş olsaydı imkansiz bir görev olurdu 15.in-addr.arpa IP adresi 15 ile biten bütün hostlardan oluşurdu -- delegasyon için hiç te pratik bir domain değil.

2-6-5 Inverse Queries (ters sorgular):

in-addr.arpa name alanı açıkça görünüyorki sadece IP-adresinden domain name e çevirmede kullanışlı. Domain name spacete  adresten başka bir şey aramak -- adrese ilaveten örneğin-  in-addr.arpa gibi ya başka bir özelleştirilmiş name space ya da bir exhaustive search gerektirirdi.

Bir dereceye kadar exhaustive search mümkündür, ve buna inverse query denir. Bir inverse query verilen bilgiyi indeksleyen domain name i için arama yapan sorgulamadır.(An inverse query is a search for the domain name that indexes a given datum.) Ve yalnızca sorguyu alan name serverı tarafından işlemi yapılır. Söz konusu name serverı bütün lokal datasını aranan nesne için tarar ve indekslenmiş domain name'ini yanıt olarak geri verir, eğer mümkünse. Eğer datayı bulamazsa vazgeçer. Başka bir name servera sorguyu forwardlamak gibi bir girişim olmaz.

Herhangi bir name serverı sadece domain name space'in bir kısmının bilgisini içerdiğinden, bir inverse query'nin bir cevap getirmesi garanti değildir. Örneğin, bir name serverı eğer hakkında birşey bilmediği bir IP adresi için inverse query alırsa, bir cevap getiremez, fakat ayrıca IP adresinin var olmadığını da bilemez, çünkü sadece DNS database'inin bir kısmını tutar. Bundan başka, inverse query implementasyonu DNS'in türüne göre opsiyoneldir BIND 4.9.7 hala inverse querileri yanıtlayabilen koda sahiptir, ama defaul olarak kapalıdır. BIND 8 o koda bile sahip değildir, yine de inverse querileri tanımlayıp onlara sahte yanıtlar verebilir.[10] Bu bize de uyar, çünkü çok az yazılım (nslookup ın arkaik versiyonları gibi) hala günümüzde inverse queryileri kullanır.
                         
                            [10] Bu işlev hakkında detay için 11.7.4 "Query Refused" a bak.



2-7 Caching

Host tablosundaki basit aramalara alışık birisine, bütün yukarıda anlatılan bu çözümleme işlemi korkunç derecede dolambaçlı ve hantal gözükebilir. Aslında, oldukça hızlıdır. Bu işlemi önemli derecede hızlandıran özelliklerden birisi ise cachingdir.

Recursive bir query işleyen bir name server, bir yanıt bulmak için biraz sorgu göndermek zorunda kalabilir. Bununla beraber, böyle yaptıkça domain name space hakkında oldukça fazla bilgi edinir. Başka name serverlarına her refere edilişinde, o name serverlarının bazı zonelar için yetkili olduğunu ve o serverların adreslerini öğrenir. Ve, çözümleme işleminin sonunda, sorgulayıcının aradığı bilgiyi bulduğunda, bu veriyi gelecekteki aramalarda kullanmak için saklayabilir. Version 4.9 ve 8 BINDleriyle beraber name serverları negative caching bile uygulamaya başlamıştır: Eğer yetkili bir name serverı sorgulanan verinin ya da domain name'in varolmadığını local name server'a iletirse, local name server'ı bu bilgiyi de geçici olarak cache de tutabilir. Name serverları bu tip dataların hepsini sorgulama işlemini hızlandırmak için kullanır. Bir dahaki sefere bir resolver, local name server'ı local name serverın bilgisi olduğu bir şey hakkında sorgularsa, çözümleme işlemi bir parça kısaltılmış olur. Name serverı yanıtı positive ya da negative olarak cachelemiş olabilir, her iki durumda hemen yanıtı resolvera gönderir. Hatta yanıtı cache'inde tutmuyor olsa bile, aranan domain name'in zone'larında yetkili olan name serverların kimliklerini öğrenmiş olabilir ve onları vakit kaybetmeden doğrudan sorgulayabilir.

Örneğin, diyelim ki name serverımız zaten eecs.berkeley.edu adresine önceden bakmış olsun. İşlem sırasında, eecs.berkeley.edu ve berkeley.edu name serverlarının  isimlerini ve adreslerini (artı eecs.berkeley.edu'nun IP adresini) cache'ine aldı. Şimdi eğer bir resolver, name serverımızı baobab.cs.berkeley.edu adresi için sorgulamış olsaydı, name serverımız root name serverlarını sorgulamayı atlayabilirdi. berkeley.edu'nun baobab.cs.berkeley.edu adresi için bildiği en yakın ata(ancestor) olması, name serverımız doğrudan berkeley.edu name serverını sorgulayabilir, şekil 2.16'da da görüldüğü gibi. Diğer yandan, eğer name serverımız daha önceden eecs.berkeley.edu için hiçbir adres olmadığını keşfetmiş olsaydı, bir dahaki sefere aynı isim için sorgu aldığında, bu sorguya cache'ine uygun olarak yanıt verebilirdi.


Şekil 2.16: baobab.cs.berkeley.edu 'yu çözümleme



Çözümleme işlemini hızlandırmasının yanında, caching bizim root name serverlarını yeniden sorgulamamızı engeller. Bunun anlamı bizim rootlara bağımlı olmadığımız, onlarında bu sorguların ağırlığı altında kalmayacaklarıdır.

2-7-1 Time to Live

Name serverları sonsuza dek verileri cachelemezler tabi ki. Eğer öyle yapsalardı, authoritative name serverlarındaki dataya yapılan değişiklikler asla networkün geri kalanına ulaşamazdı. Uzaktaki name serverları sadece cachelenmiş datayı kullanmaya devam ederlerdi. Sonuç olarak, datayı içeren zone'un yöneticisi, data için bir time to live e karar verir ya da TTL. Time to live bir name serverın datayı cachelemesine izin verilen sürenin miktarıdır. Time to live 'in süresi geçtikten sonra, name serverı cachelenmiş veriyi atmalı ve yetkili name serverlarından yeni data almalıdır. Bu negative cachelenmiş datalar için de geçerlidir bir name server, yeni bir data yetkili name serverlarına eklenmiş olabileceği için, negatif yanıtları da belli bir süre sonunda atmalıdır. Bununla beraber, negatif cachelenen datanın TTL'i domain administratorı tarafından ayarlanabilir değildir on dakikaya hardcodelanmıştır.

Datanız için time to live değerine karar vermek aslında performans ve kararlılık arasında bir yer belirlemek demektir. Küçük TTL değeri domaininiz hakkındaki datanın network boyunca kararlı olmasına yardımcı olur, çünkü uzak name serverları bu veriyi daha çabuk sürede atıp, authoritative name serverlarınızı çok daha sık yeni veri için sorgulamaya zorlanmış olacaklardır. Diğer yandan bu name serverları üzerine binen yükü artıracak ve domaininiz içindeki bilginin çözümleme süresini artıracaktır.

Büyük bir TTL domaininizdeki bilginin ortalama çözümleme süresini kısaltacaktır çünkü data daha uzun süreler için cachelenebilir durumdadır. Bunun karşılığında eğer name serverlarınızdaki verilerde değişiklikler yaparsanız, domaindeki bu bilgiler daha uzun süreler için tutarsız olacaktır.

data_grrr

DNS ve Elektronik Posta:

Domain Name System'ın host tablolarına karşı olan en büyük avantajlarından biri de gelişmiş mail routing desteği sunmasıdır. Mail atanlarn bir zamanlar sadece HOSTS.TXT dosyasına sahipken yapabilecekleri en iyi şey postalamayı host'un ip adresine göndermekti. Eğer bu başarısız olursa tekrar denemek zorundaydılar.

DNS mail dağıtımı için backup hostlar sunan bir mekanizmaya sahiptir. Mekanizma ayrıca hostlara diğer hostlar için mail yönetimine izin verir. Bu mailer çalıştırmayan disksiz hostların, mesela, kendilerine gelen mailların ilgili serverları tarafından işlenmesini sağlar.

Host tablolarından farklı olarak DNS, keyfi isimlerin elektronik posta hedefleri olarak gösterilebilmesini sağlar. Siz - ve Internetteki bir çok organizasyon - ana forward-mapping zone'unuzun domain ismini bir email hedefi (adresi) olarak gösterebilirsiniz.  Ya da zone'unuza esas olarak email hedefleri olacak, herhangi bir hostu temsil etmeyen domain isimleri ekleyebilirsiniz.  Tek bir mantıksal email hedefi ayrıca bir çok mail serverını temsil edebilir.

MX KAYITLARI:

DNS gelişmiş mail routing için tek tip bir resource record kullanır, MX recordu. Esasında, MX record'unun işlevi iki record arasında bölünmüştü, MD (mail destination) ve MF (mail forwarder) recordları olarak. MD, bir mesajın verilen bir domain ismine dağıtılması için en son ki hedefini belirtmişti. MF ise hedef erişilemez olduğunda maili forward edileceği destinationı belirtmişti.

Internette yaşanan ilk deneyimlerde görüldü ki bu işlevlerin ayrılması çok da iyi çalışmamıştı. Bir mailer hem MD hem de MF recordlarının domain ismine ataçlanmış olmasına ihtiyaç duyuyordu maili nereye göndereceğine karar vermesi için. Tek başına bu kayıtları bir tanesi bir işe yaramıyordu. Ama tek tip bir kayıt için (MF ya da MD) yapılan explicit bir lookup name serverın sadece ilgili record tipini cache etmesine neden olacaktı. Bu nedenle mailer lar ya iki sorgulama yapmak durumundaydılar, biri MD biri MF için ya da cache edilmiş cevapları kabul edemezlerdi. Bu da mail işletmenin giderlerinin diğer servislere oranla daha fazla olacağına işaret ediyordu ki bu da kabul edilemezdi.

İki record tipi MX adı verilen tek bir record tipine entegre edilerek bu problem çözüldü. Şimdi bir mailer, bir mail routing kararı vermek için, özel bir domain name destination ı için olan tüm MX recordlarına ihtiyaç duyucaktı. TTLleri eşleştiği sürece cachelenmiş MX recordlarını kullanmak güzeldi.

MX recordları bir domain ismi için bir "mail exchanger" belirtir: bu maili işleyen ya da domain ismi için forwardlayan (bir firewall üzerinden mesela) bir hosttur. Mailı "işlemek" maili ya adreslendiği kişiye göndermek ya da mailı gateway yoluyla başka bir mail transporta göndermektir (X.400 gibi). "Forwardlama" ise maili son hedefine göndermek ya da SMTP yoluyla daha yakın olan mail exchanger'a göndermektir. SMTP, Internet's Simple Mail Transfer Protocol kısaltmasıdır. Bazen mail forwardlamaya maili bir süreliğine sıraya sokmak da dahil olur.

Mail routing döngülerini önlemek için, MX recordunun mail exchanger'ın domain isminden başka ekstra bir parametresi daha vardır: tercih değeri (preference value)
Preference value bir imzalanmamış (unsigned) 16-bit lik bir sayıdır (0 ve65535 arasında). Bu sayı mail exchanger'ın önceliğine işaret eder. Örneğin aşağıdaki MX recordu:

peets.mpk.ca.us.    IN    MX    10 relay.hp.com.

relay.hp.com 'un peets.mpk.ca.us için 10 tercih değerinde bir mail exchanger olduğunu belirtir.

Toparladığımızda, mail exchangerların tercih değerleri, mailerın onları kullanma sırasını belirler. Tercih değeri kendi başına bir önem taşımaz, sadece diğer mail exchangerlar ile olan ilişkisi önemlidir. Önemli olan belirli hedefin belirli bir mail exchanger'ının tercih değeri diğer exchangerlardan düşük mü yüksek mi, önemli olan budur.

aşağıdakinin yaptığı şey,

plange.puntacana.dr.  IN  MX  1 listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  2 hep.puntacana.dr.

bununla aynıdır,

plange.puntacana.dr.  IN  MX  50  listo.puntacana.dr.
plange.puntacana.dr.  IN  MX  100 hep.puntacana.dr.

Mailerlar ilk dağıtımı mail exchangerlar arasından en düşük tercih değerli olana gerçekleştirmelidir.
Eğer en çok tercih edilen mail exchangerlara dağıtım başarısız olursa, mailerlar daha az tercih edileni deneyerek bu işleme devam etmelidir.
Birden fazla mail exchanger tek bir tercih değerini paylaşabilir, bu durumda mailer ilk hangisine göndereceğini kendisi seçer, ve başarısızlık durumunda bu exchangerların hepsini denemek durumundadır.

Örneğin , oreilly.com için MX recordları aşağıdaki gibi olabilir:

oreilly.com.    IN    MX    0 ora.oreilly.com.
oreilly.com.    IN    MX    10 ruby.oreilly.com.
oreilly.com.    IN    MX    10 opal.oreilly.com.

Hepsi beraber yorumlandığında, bu MX recordları mailerlara şu talimatları verir:

1. ora.oreilly.com ilk
2. Ya ruby.oreilly.com ya da opal.oreilly.com sonra
3. İkinci sırada kullanılmayan mail exchanger

Tabi ki başarılı bir şekilde ilk sıradaki ora.oreilly.com a dağıtımı gerçekleştirirse mailer diğerlerini kullanması gerekmez.

Şuna dikkat edin, oreilly.com spesifik bir host değildir; bu O'Reilly & Associates' in main forward-mapping zone'unun domain ismidir. O'Reilly & Associates domain ismini burada çalışan herkes için email hedefi olarak kullanır. Kullanıcıların hangi hostta hesapları varsa onlara göndermek yerine (mesela ruby.oreilly.com ya da amber.oreilly.com) tek bir email hedefi kullanmak (oreilly.com) çok daha kolaydır öyle değil mi?

Bu tabi ki ora.oreilly.com daki mailerın administratorının O'Reilly deki bütün kullanıcılar için takma isimler (aliases) dosyası tutmasını gerektirir. Bu durumda mailer mailları userların okumuş oldukları hostlara forward eder, ya da POP ya da IMAP server çalıştırarak kullanıcıların remote access yoluyla mail alanlarına erişmelerini sağlar.  Peki ya bir hedefin bir MX kaydı yoksa, ama bir ya da iki A recorduna sahipse? O zaman mailer mail hedefine göndermeyecek mi? Bu aslında mail servera bağlı bir şeydir. Hem Microsoft Exchange hem de Windows Server 2003 ile gelen SMTP serverları mail göndermek istediğiniz domain name'i için geçerli bir MX recordunun varlığına ihtiyaç duyar. Bununla beraber, Sendmail, Unix dünyasından gelen popüler bir mail transport agentı daha farklıdır. Sendmail'ın son versiyonları MX recordu olmayan ama en azından bir A recordu olan bir hedefe mail göndermek üzere derlenebilir. Bir çok dağıtıcı kendi sendmaillarını bu şekilde derlemiştir. Sendmail version 8, kutudan çıktığı haliyle, MX recordları olmadan bir mail destination'ın adresini deneyecektir. Emin değilseniz dağıtıcınızın dökümanlarını okuyarak sadece A recordları olan mail hedeflerine mail serverınızın mail gönderip göndermeyeceğini öğrenebilirsiniz.

Neredeyse bütün mailerlar MX recordu olmayan ama en az bir adress recordu olan hedefe mail dağıtabilmesine rağmen, her mail destination ı için en azından bir MX recorduna sahip olmak iyi  bir fikirdir. Çoğu mailerlar, sendmail dahil, dağıtılması gereken bir mail olduğunda ilk önce hedef için olan MX recordlarına bakacaklardır. Eğer hedefin hiç MX recordu yoksa, bir name serverı - genellikle sizin authoritative name serverlarından biri - hala bu sorguyu yanıtlamak zorundadır, ve sonra Sendmail A recordlarına bakmak üzere devam edecektir işleme. Bu ekstra zaman alır, mail dağıtımını yavaşlatır, ve zone'unuzun yetkili name serverlarına biraz daha yük binmesine neden olur.  Eğer basitçe her mail destinationı için bir domain name'e işaret eden bir MX recordu eklerseniz, mailer sadece tek bir sorgu atmak zorunda olacaktır, ve mailerın local name server'ı MX recordunu sonraki kullanımlar için cache'inde saklayacaktır.

DNS konsolundan MX recordları eklemek:

MX recordu eklemek istediğiniz zone'un domain ismine sağ tıklayın.
New Mail Exchanger'ı seçin pop-up menüden.
Buradan gerekli ayarları yapın,
örnek;
host or child domain: ruby
FQDN: ruby.oreilly.com.
FQDN of mail server: ruby.oreilly.com
Mail server priority: 10

bu örnekte ruby.oreilly.com için 10 tercih değerinde, ruby.oreilly.com un kendisine işaret eden bir MX kaydı ekledik. Zone data dosyasına eklenen kayıt şuna benzer:

ruby       IN MX 10   ruby.oreilly.com.


MX ALGORİTMASI:

Mailerların routing loopları kontrol etmediğini farz edelim. Diyelim ki iş yerinizden nuts@oreilly.com a bir mail gönderdiniz. Maalesef, ora.oreilly.com şu anda down. Problem yok! oreilly.com un MX recordlarını hatırlayın:

oreilly.com.   IN   MX  0 ora.oreilly.com.
oreilly.com.   IN   MX  10 ruby.oreilly.com.
oreilly.com.   IN   MX 10 opal.oreilly.com.

Mailer bu durumda mesajınızı ruby.oreilly.com a gönderir. ruby.oreilly.com un mailer ı sonra maili ora.oreilly.com a forward etmeyi dener ama yapamaz, çünkü ora.oreilly.com down durumdadır. Şimdi ne olucak? ruby.oreilly.com ne yaptığını kontrol etmediği müddetçe, mesajı opal.oreilly.com a ya da kendisine forward etmeye çalışacak. Bu tabi ki mailin dağıtılmasına bir yarar sağlamayacak. Eğer ruby.oreilly.com mesajı kendine gönderirse, bir mail routing loopumuz var demektir. Eğer ruby mesajı opal e gönderirse, opal ya bunu rubye geri gönderecek ya da kendine gönderecektir yani yine bir loop oluşur.

Bunun olmasını engellemek için, mailerlar bir mesajı nereye göndereceklerine karar vermeden önce belirli MX recordlarını kaldırırlar.