DNS

DNS (İngilizce: Domain Name System, Türkçe: Alan Adı Sistemi), internet uzayını bölümlemeye, bölümleri adlandırmaya ve bölümler arası iletişimi organize etmeye yarayan, bilgisayar, servis, internet veya özel bir ağa bağlı herhangi bir kaynak için hiyerarşik dağıtılmış bir adlandırma sistemidir. ⓘ

İnternet ağını oluşturan her birim sadece kendine ait bir IP adresine sahiptir. Bu IP adresleri kullanıcıların kullanımı için www.site_ismi.com gibi kolay hatırlanır adreslere karşılık düşürülür. DNS sunucuları, internet adreslerinin IP adresi karşılığını kayıtlı tutmaktadır. ⓘ

Katılımcı kuruluşların her birine atanmış alan adları çeşitli bilgileri ilişkilendirir. En belirgin olarak, insanlar tarafından kolayca ezberlenebilen alan adlarını, dünya çapında bilgisayar servisleri ve cihazlar için gerekli sayısal IP adreslerine çevirir (dönüştürür). DNS, çoğu internet servisinin işlevselliği için temel bir bileşendir, çünkü Internetin temel yönetici servisidir. ⓘ

Alan Adı Sistemi DNS her alan için yetkili ad sunucuları atayarak alan adlarını atama ve bu adların IP adreslerine haritalanması sorumluluğunu verir. Yetkili ad sunucuları desteklenen alanları için sorumlu olmakla görevlidirler ve diğer ad sunucuları yerine alt alanlara yetki (otorite) verebilirler. Bu mekanizma dağıtılmış ve arızaya toleranslı servis sağlar  ve tek bir merkezi veri tabanına ihtiyacı önlemek için tasarlanmıştır. ⓘ

DNS aynı zamanda özünde (çekirdekte) bulunan veritabanı servisinin teknik işlevselliğini de belirtir. DNS protokolünü – DNS’de kullanılan veri yapılarının ve veri iletişim alışverişinin (değiş tokuş) detaylı tanımlaması- İnternet Protocol Suite’in bir parçası  olarak tanımlar. Tarihsel olarak DNS’ den önceki yönetici servisleri orijinal olarak metin dosyalarına ve belirgin bir şekilde HOSTS.TXT çözücüsüne dayandığı için büyük veya küresel yöneticilere göre ölçeklenebilir değildi. DNS 1980’ den bu yana yaygın olarak kullanılır olmuştur. ⓘ

İnternet hiyerarşi alan adı ve İnternet Protokol (IP) adres boşluğu olmak üzere iki ana ad boşluğunu sağlar. DNS sistemi alan adı hiyerarşisi sağlar ve onunla adres boşluğu arasında çeviri servisi sağlar. İnternet adı sunucuları ve iletişim protokolü Domain Name Sistemini etkin kılar. Bir DNS ad sunucusu, alan DNS kayıtlarını alan adı için depolayan bir sunucudur; DNS ad sunucusu veri tabanına karşı sorulara cevaplarla karşılık verir. ⓘ

DNS veri tabanında depolanan en yaygın kayıt türleri; DNS bölgesinin yetkisi otoritesi  (SOA), IP adresleri (A ve AAAA), SMTP posta değiştiriciler (MX), ad sunucuları (NS), ters DNS aramaları için işaretçiler (PTR) ve alan adı takma isimleridir (CNAME). ⓘ

Genel amaçlı bir veri tabanı olmak için tasarlanmamasına rağmen, DNS diğer veri türleri için DNSSEC kayıtları gibi şeyler için otomatik makine aramalarını  ya da Sorumlu kişi (RP) kayıtları gibi insan sorularını da depolayabilir. DNS kayıt türlerinin tam listesi için, DNS kayıt türlerinin listesine bakın. Genel amaçlı veritabanı olarak, DNS veri tabanında saklanan gerçek zamanlı kara delik listesi kullanılarak istenmeyen e-posta (Spam) ile mücadelede kullanımında da DNS görülebilir. İnternet adlandırma için veya genel amaçlı kullanımlar için olsun, DNS veritabanı, yapılandırılmış bölge dosyasında geleneksel olarak depolanır. ⓘ

İşlev

Alan Adı Sistemini açıklamak için sıklıkla kullanılan bir benzetme, insan dostu bilgisayar ana bilgisayar adlarını IP adreslerine çevirerek İnternet için telefon rehberi görevi görmesidir. Örneğin, www.example.com alan adı 93.184.216.34 (IPv4) ve 2606:2800:220:1:248:1893:25c8:1946 (IPv6) adreslerine çevrilir. DNS hızlı ve şeffaf bir şekilde güncellenebilir, böylece bir hizmetin ağ üzerindeki konumu aynı ana bilgisayar adını kullanmaya devam eden son kullanıcıları etkilemeden değiştirilebilir. Kullanıcılar, bilgisayarın hizmetleri gerçekte nasıl bulduğunu bilmek zorunda kalmadan anlamlı Tekdüzen Kaynak Konum Belirleyicileri (URL'ler) ve e-posta adresleri kullandıklarında bundan yararlanırlar. ⓘ

DNS'nin önemli ve her yerde bulunan bir işlevi de bulut hizmetleri ve içerik dağıtım ağları gibi dağıtılmış İnternet hizmetlerindeki merkezi rolüdür. Bir kullanıcı bir URL kullanarak dağıtılmış bir İnternet hizmetine eriştiğinde, URL'nin alan adı kullanıcıya yakın olan bir sunucunun IP adresine çevrilir. DNS'nin burada kullanılan temel işlevi, farklı kullanıcıların aynı alan adı için aynı anda farklı çeviriler alabilmesidir; bu, DNS'nin geleneksel telefon defteri görünümünden önemli bir sapma noktasıdır. Kullanıcılara yakın sunucuları atamak için DNS'yi kullanma süreci, İnternet üzerinde daha hızlı ve daha güvenilir yanıtlar sağlamanın anahtarıdır ve çoğu büyük İnternet hizmeti tarafından yaygın olarak kullanılmaktadır. ⓘ

DNS, İnternet'teki idari sorumluluk yapısını yansıtır. Her bir alt alan adı, bir yöneticiye devredilmiş idari özerkliğe sahip bir bölgedir. Bir kayıt kuruluşu tarafından işletilen bölgeler için, idari bilgiler genellikle kayıt kuruluşunun RDAP ve WHOIS hizmetleri ile tamamlanır. Bu veriler, İnternet üzerindeki belirli bir ana bilgisayar hakkında bilgi edinmek ve sorumluluğunu izlemek için kullanılabilir. ⓘ

Tarihçe

Bir ana bilgisayarın sayısal adresi yerine daha basit, daha akılda kalıcı bir adın kullanılması ARPANET dönemine kadar uzanır. Stanford Araştırma Enstitüsü (şimdi SRI International), ana bilgisayar adlarını ARPANET'teki bilgisayarların sayısal adresleriyle eşleyen HOSTS.TXT adlı bir metin dosyası tuttu. Elizabeth Feinler ilk ARPANET dizinini geliştirdi ve sürdürdü. Atanmış Numaralar Listesi olarak adlandırılan sayısal adreslerin bakımı, ekibi SRI ile yakın çalışan Güney Kaliforniya Üniversitesi Bilgi Bilimleri Enstitüsü'nden (ISI) Jon Postel tarafından gerçekleştirildi. ⓘ

Adresler manuel olarak atanıyordu. Bilgisayarlar, ana bilgisayar adları ve adresleriyle birlikte, Feinler tarafından yönetilen SRI Ağ Bilgi Merkezi'ne (NIC) mesai saatleri içinde telefonla ulaşılarak birincil dosyaya eklendi. Daha sonra Feinler, kaynaklar, kişiler ve varlıklar hakkında bilgi almak için NIC'deki bir sunucuda bir WHOIS dizini kurdu. O ve ekibi alan adı kavramını geliştirdi. Feinler, alan adlarının bilgisayarın fiziksel adresinin bulunduğu yere dayalı olmasını önerdi. Örneğin, eğitim kurumlarındaki bilgisayarlar edu etki alanına sahip olacaktı. O ve ekibi 1972'den 1989'a kadar Host Naming Registry'yi yönetti. ⓘ

1980'lerin başında, tek ve merkezi bir ana bilgisayar tablosunun tutulması yavaş ve hantal hale gelmişti ve gelişmekte olan ağ, teknik ve personel sorunlarını ele almak için otomatik bir adlandırma sistemi gerektiriyordu. Postel, birbiriyle yarışan beş çözüm önerisi arasında bir uzlaşma sağlama görevini Paul Mockapetris'e verdi. Mockapetris bunun yerine 1983 yılında Güney Kaliforniya Üniversitesi'ndeyken Alan Adı Sistemini yarattı. ⓘ

İnternet Mühendisliği Görev Gücü, Kasım 1983'te RFC 882 ve RFC 883'te orijinal özellikleri yayınladı. Bunlar Ocak 1986'da RFC 973'te güncellendi. ⓘ

1984 yılında, dört UC Berkeley öğrencisi, Douglas Terry, Mark Painter, David Riggle ve Songnian Zhou, Berkeley Internet Name Domain için genellikle BIND olarak adlandırılan ilk Unix isim sunucusu uygulamasını yazdılar. 1985 yılında DEC'ten Kevin Dunlap DNS uygulamasını büyük ölçüde revize etti. Mike Karels, Phil Almquist ve Paul Vixie daha sonra BIND'ın bakımını üstlendi. Internet Systems Consortium 1994 yılında Rick Adams, Paul Vixie ve Carl Malamud tarafından BIND geliştirme ve bakımı için bir yuva sağlamak amacıyla kurulmuştur. ISC'nin sponsorları tarafından sağlanan destekle 4.9.3'ten itibaren BIND sürümleri ISC tarafından geliştirildi ve sürdürüldü. Ortak mimarlar/programcılar olarak Bob Halley ve Paul Vixie, Mayıs 1997'de BIND sürüm 8'in ilk üretime hazır sürümünü yayınladılar. 2000 yılından bu yana 43'ün üzerinde farklı çekirdek geliştirici BIND üzerinde çalışmıştır. ⓘ

Kasım 1987'de RFC 1034 ve RFC 1035, 1983 DNS spesifikasyonlarının yerini aldı. Birkaç ek Yorum İsteği, çekirdek DNS protokollerine uzantılar önermiştir. ⓘ

Yapı

Alan adı alanı

Alan adı uzayı bir ağaç veri yapısından oluşur. Ağaçtaki her düğüm veya yaprak bir etikete ve alan adıyla ilişkili bilgileri tutan sıfır veya daha fazla kaynak kaydına (RR) sahiptir. Alan adının kendisi, sağdaki üst düğümün adıyla birleştirilen ve bir nokta ile ayrılan etiketten oluşur. ⓘ

Ağaç, kök bölgeden başlayarak bölgelere ayrılır. Bir DNS bölgesi, bölge yöneticisinin seçtiği sayıda etki alanından ve alt etki alanından oluşabilir. DNS, ayrı sınıfların paralel ad alanı ağaçları dizisi olarak düşünülebileceği sınıfa göre de bölümlendirilebilir. ⓘ

İnternet sınıfı için hiyerarşik Alan Adı Sistemi, her biri bir ad sunucusu tarafından sunulan bölgeler halinde düzenlenmiştir ⓘ

Herhangi bir bölge için idari sorumluluk, ek bölgeler oluşturularak bölünebilir. Yeni bölge üzerindeki yetkinin belirlenmiş bir ad sunucusuna devredildiği söylenir. Ana bölge yeni bölge için yetkili olmaktan çıkar. ⓘ

Alan adı sözdizimi, uluslararasılaştırma

Alan adlarının oluşturulmasına ilişkin kuralların kesin açıklamaları RFC 1035, RFC 1123, RFC 2181 ve RFC 5892'de yer almaktadır. Bir alan adı, teknik olarak etiket olarak adlandırılan, geleneksel olarak birleştirilen ve example.com gibi noktalarla sınırlandırılan bir veya daha fazla parçadan oluşur. ⓘ

En sağdaki etiket üst düzey etki alanını ifade eder; örneğin, www.example.com alan adı üst düzey com etki alanına aittir. ⓘ

Etki alanları hiyerarşisi sağdan sola doğru iner; soldaki her etiket sağdaki etki alanının bir alt bölümünü veya alt etki alanını belirtir. Örneğin, example etiketi com etki alanının bir alt etki alanını belirtir ve www, example.com'un bir alt etki alanıdır. Bu alt bölümler ağacı 127 seviyeye kadar olabilir. ⓘ

Bir etiket sıfır ila 63 karakter içerebilir. Uzunluğu sıfır olan null etiket kök bölge için ayrılmıştır. Tam alan adı, metinsel gösteriminde 253 karakter uzunluğunu aşamaz. DNS'nin dahili ikili gösteriminde maksimum uzunluk, adın uzunluğunu da sakladığı için 255 sekizli depolama alanı gerektirir. ⓘ

Alan adı etiketlerinin bir sekizli ile temsil edilebilen herhangi bir karakteri kullanmasını engelleyen teknik bir sınırlama olmamasına rağmen, ana bilgisayar adları tercih edilen bir biçim ve karakter kümesi kullanır. Etiketlerde izin verilen karakterler ASCII karakter kümesinin bir alt kümesidir ve a'dan z'ye kadar olan karakterler, A'dan Z'ye kadar olan karakterler, 0'dan 9'a kadar olan rakamlar ve kısa çizgiden oluşur. Bu kural LDH kuralı (harfler, rakamlar, tire) olarak bilinir. Alan adları büyük/küçük harf bağımsız olarak yorumlanır. Etiketler tire ile başlayamaz veya tire ile bitemez. Ek bir kural, üst düzey alan adlarının tamamen sayısal olmamasını gerektirir. ⓘ

DNS'de izin verilen sınırlı ASCII karakter seti, birçok dilin isimlerinin ve kelimelerinin kendi alfabelerinde veya alfabelerinde temsil edilmesini engellemiştir. Bunu mümkün kılmak için ICANN, web tarayıcıları gibi kullanıcı uygulamalarının Punycode kullanarak Unicode dizelerini geçerli DNS karakter setiyle eşleştirdiği Internationalizing Domain Names in Applications (IDNA) sistemini onayladı. 2009 yılında ICANN uluslararasılaştırılmış alan adı ülke kodu üst düzey alan adlarının (ccTLD'ler) kurulumunu onaylamıştır. Buna ek olarak, mevcut üst düzey alan adlarının (TLD'ler) birçok kaydı RFC 5890, RFC 5891, RFC 5892, RFC 5893 tarafından yönlendirilen IDNA sistemini benimsemiştir. ⓘ

İsim sunucuları

Alan Adı Sistemi, istemci-sunucu modelini kullanan dağıtılmış bir veritabanı sistemi tarafından sürdürülür. Bu veritabanının düğümleri ad sunucularıdır. Her etki alanı, o etki alanı ve ona bağlı tüm etki alanlarının ad sunucuları hakkında bilgi yayınlayan en az bir yetkili DNS sunucusuna sahiptir. Hiyerarşinin en üstünde, bir TLD'yi ararken (çözümlerken) sorgulanacak sunucular olan kök ad sunucuları bulunur. ⓘ

Yetkili ad sunucusu

Yetkili ad sunucusu, yalnızca bir veri önbelleği tutan başka bir ad sunucusuna sorgu yoluyla elde edilen yanıtların aksine, DNS sorgularına yalnızca orijinal bir kaynak tarafından, örneğin etki alanı yöneticisi veya dinamik DNS yöntemleriyle yapılandırılmış verilerden yanıt veren bir ad sunucusudur. ⓘ

Yetkili bir ad sunucusu birincil sunucu ya da ikincil sunucu olabilir. Tarihsel olarak master/slave ve primary/secondary terimleri bazen birbirinin yerine kullanılmıştır, ancak mevcut uygulama ikinci biçimi kullanmaktır. Birincil sunucu, tüm bölge kayıtlarının orijinal kopyalarını saklayan bir sunucudur. İkincil sunucu, birincil kayıtların özdeş bir kopyasını tutmak için birincil ile iletişim halinde DNS protokolünde özel bir otomatik güncelleme mekanizması kullanır. ⓘ

Her DNS bölgesine bir yetkili ad sunucuları kümesi atanmalıdır. Bu sunucu kümesi, ad sunucusu (NS) kayıtlarıyla birlikte ana etki alanı bölgesinde saklanır. ⓘ

Yetkili bir sunucu, yanıtlarında "Yetkili Yanıt" (AA) biti olarak adlandırılan bir protokol bayrağı ayarlayarak yetkili kabul edilen kesin yanıtlar sağlama durumunu belirtir. Bu bayrak, yanıt veren ad sunucusunun söz konusu alan adı için yetkili olduğunu belirtmek için genellikle dig gibi DNS yönetim sorgu araçlarının çıktısında belirgin bir şekilde yeniden üretilir. ⓘ

Bir ad sunucusu, yetkili verilere sahip olmadığı bir alan adı için yetkili sunucu olarak belirlendiğinde, "topal temsilci" veya "topal yanıt" olarak adlandırılan bir hata türü ortaya çıkar. ⓘ

Operasyon

Adres çözümleme mekanizması

Alan adı çözümleyicileri, en sağdaki (üst düzey) alan adı etiketinden başlayan bir dizi sorgu ile söz konusu alan adından sorumlu alan adı sunucularını belirler. ⓘ

RFC 1034 tarafından zorunlu kılınan yinelemeli yaklaşımı uygulayan bir DNS çözümleyici; bu durumda, çözümleyici "www.wikipedia.org" tam nitelikli alan adını çözümlemek için üç ad sunucusuna danışır. ⓘ

Alan adı çözümleyicisinin düzgün çalışması için bir ağ ana bilgisayarı, kök ad sunucularının bilinen adreslerinden oluşan bir başlangıç önbelleği (ipuçları) ile yapılandırılır. İpuçları, bir yönetici tarafından güvenilir bir kaynaktan bir veri kümesi alınarak periyodik olarak güncellenir. ⓘ

Çözümleyicinin süreci hızlandırmak için önbelleğe alınmış kayıtları olmadığı varsayıldığında, çözümleme süreci kök sunuculardan birine yapılan bir sorgu ile başlar. Tipik bir işlemde, kök sunucular doğrudan yanıt vermez, ancak daha yetkili sunuculara yönlendirme ile yanıt verir, örneğin, "www.wikipedia.org" için bir sorgu org sunucularına yönlendirilir. Çözümleyici şimdi yönlendirilen sunucuları sorgular ve yetkili bir yanıt alana kadar bu işlemi yinelemeli olarak tekrarlar. Diyagramda, "www.wikipedia.org" tam nitelikli alan adıyla adlandırılan ana bilgisayar için bu süreç gösterilmektedir. ⓘ

İnternet üzerindeki her çözümlemenin kök sunucudan başlaması gerekseydi, bu mekanizma kök sunuculara büyük bir trafik yükü getirecekti. Pratikte, DNS sunucularında kök sunucuların yükünü hafifletmek için önbellekleme kullanılır ve sonuç olarak, kök ad sunucuları aslında tüm isteklerin yalnızca nispeten küçük bir kısmına dahil olur. ⓘ

Özyinelemeli ve önbellekli ad sunucusu

Teorik olarak, yetkili isim sunucuları İnternet'in çalışması için yeterlidir. Ancak, yalnızca yetkili ad sunucuları çalışırken, her DNS sorgusu Alan Adı Sisteminin kök bölgesinde özyinelemeli sorgularla başlamalı ve her kullanıcı sistemi özyinelemeli çalışma yeteneğine sahip çözümleyici yazılımı uygulamalıdır. ⓘ

Verimliliği artırmak, İnternet üzerindeki DNS trafiğini azaltmak ve son kullanıcı uygulamalarında performansı artırmak için Alan Adı Sistemi, DNS sorgu sonuçlarını söz konusu alan adı kaydının yapılandırmasında (yaşama süresi) belirlenen bir süre boyunca saklayan DNS önbellek sunucularını destekler. Tipik olarak, bu tür önbelleğe alma DNS sunucuları, DNS kökünden başlayarak sorgulanan alan adının yetkili ad sunucularına kadar belirli bir adı çözümlemek için gerekli özyinelemeli algoritmayı da uygular. İsim sunucusunda uygulanan bu işlev sayesinde kullanıcı uygulamaları tasarım ve işletim açısından verimlilik kazanır. ⓘ

Bir ad sunucusunda DNS önbelleğe alma ve özyinelemeli işlevlerin bir arada bulunması zorunlu değildir; işlevler özel amaçlar için sunucularda bağımsız olarak uygulanabilir. ⓘ

İnternet servis sağlayıcıları genellikle müşterileri için özyinelemeli ve önbellekli ad sunucuları sağlar. Buna ek olarak, birçok ev ağı yönlendiricisi, yerel ağdaki verimliliği artırmak için DNS önbellekleri ve özyineleme uygular. ⓘ

DNS çözümleyicileri

DNS'nin istemci tarafına DNS çözümleyici denir. Çözümleyici, aranan kaynağın tam olarak çözümlenmesine (çevrilmesine) yol açan sorguların başlatılmasından ve sıralanmasından sorumludur; örneğin, bir alan adının IP adresine çevrilmesi. DNS çözümleyicileri özyinelemeli, özyinelemesiz ve yinelemeli gibi çeşitli sorgu yöntemlerine göre sınıflandırılır. Bir çözümleme işlemi bu yöntemlerin bir kombinasyonunu kullanabilir. ⓘ

Özyinelemeli olmayan bir sorguda, bir DNS çözümleyici, sunucunun yetkili olduğu bir kaydı sağlayan bir DNS sunucusunu sorgular veya diğer sunucuları sorgulamadan kısmi bir sonuç sağlar. Önbelleğe alma DNS çözümleyicisi durumunda, yerel DNS önbelleğinin özyinelemesiz sorgusu bir sonuç sağlar ve yukarı akış DNS sunucularından gelen ilk yanıttan sonra bir süre için DNS kaynak kayıtlarını önbelleğe alarak yukarı akış DNS sunucuları üzerindeki yükü azaltır. ⓘ

Özyinelemeli sorguda, bir DNS çözümleyicisi tek bir DNS sunucusunu sorgular ve bu sunucu da istekte bulunan adına diğer DNS sunucularını sorgulayabilir. Örneğin, bir ev yönlendiricisinde çalışan basit bir saplama çözümleyici genellikle kullanıcının İSS'si tarafından çalıştırılan DNS sunucusuna özyinelemeli bir sorgu yapar. Özyinelemeli sorgu, DNS sunucusunun gerektiğinde diğer ad sunucularını sorgulayarak sorguyu tamamen yanıtladığı sorgudur. Tipik bir işlemde, bir istemci önbelleğe alınmış özyinelemeli bir DNS sunucusuna özyinelemeli bir sorgu gönderir, bu sunucu daha sonra yanıtı belirlemek ve istemciye tek bir yanıtı geri göndermek için özyinelemeli olmayan sorgular gönderir. Çözümleyici veya çözümleyici adına özyinelemeli olarak hareket eden başka bir DNS sunucusu, sorgu başlıklarındaki bitleri kullanarak özyinelemeli hizmetin kullanımı konusunda anlaşmaya varır. DNS sunucularının özyinelemeli sorguları desteklemesi gerekmez. ⓘ

Yinelemeli sorgu yordamı, bir DNS çözümleyicisinin bir veya daha fazla DNS sunucusundan oluşan bir zinciri sorguladığı bir işlemdir. Her sunucu, geçerli sunucu isteği tam olarak çözümleyene kadar istemciyi zincirdeki bir sonraki sunucuya yönlendirir. Örneğin, www.example.com adresinin olası bir çözümlemesi bir global kök sunucusunu, ardından bir "com" sunucusunu ve son olarak da bir "example.com" sunucusunu sorgular. ⓘ

Dairesel bağımlılıklar ve tutkal kayıtları

Temsilciliklerdeki ad sunucuları IP adresi yerine adla tanımlanır. Bu, çözümleme yapan bir ad sunucusunun, yönlendirildiği sunucunun IP adresini öğrenmek için başka bir DNS isteği göndermesi gerektiği anlamına gelir. Temsilcilikte verilen ad, temsilciliğin sağlandığı etki alanının bir alt etki alanıysa, döngüsel bir bağımlılık söz konusudur. ⓘ

Bu durumda, yetkilendirmeyi sağlayan ad sunucusu, yetkilendirmede belirtilen yetkili ad sunucusu için de bir veya daha fazla IP adresi sağlamalıdır. Bu bilgi tutkal olarak adlandırılır. Yetki veren ad sunucusu bu yapıştırıcıyı DNS yanıtının ek bölümündeki kayıtlar biçiminde sağlar ve yetkilendirmeyi yanıtın yetki bölümünde sağlar. Tutkal kaydı, ad sunucusu ve IP adresinin bir birleşimidir. ⓘ

Örneğin, example.org için yetkili ad sunucusu ns1.example.org ise, www.example.org adresini çözümlemeye çalışan bir bilgisayar önce ns1.example.org adresini çözümler. ns1 example.org içinde yer aldığından, bu önce example.org'un çözümlenmesini gerektirir, bu da döngüsel bir bağımlılık oluşturur. Bağımlılığı kırmak için, org üst düzey etki alanının ad sunucusu, example.org delegasyonuyla birlikte tutkal içerir. Tutkal kayıtları, ns1.example.org için IP adresleri sağlayan adres kayıtlarıdır. Çözümleyici, etki alanının yetkili sunucularından birini sorgulamak için bu IP adreslerinden birini veya daha fazlasını kullanır ve bu da DNS sorgusunu tamamlamasını sağlar. ⓘ

Kayıt önbelleğe alma

Uygulamalarda ad çözümlemenin uygulanmasında standart bir uygulama, sonuçları yerel olarak veya ara çözümleyici ana bilgisayarlarda önbelleğe alarak Alan Adı Sistemi sunucuları üzerindeki yükü azaltmaktır. Bir DNS isteğinden elde edilen sonuçlar her zaman, sonuçların atılması veya yenilenmesi gereken bir sona erme süresi olan yaşama süresi (TTL) ile ilişkilendirilir. TTL, yetkili DNS sunucusunun yöneticisi tarafından ayarlanır. Geçerlilik süresi birkaç saniyeden günlere hatta haftalara kadar değişebilir. ⓘ

Bu dağıtılmış önbellekleme mimarisinin bir sonucu olarak, DNS kayıtlarında yapılan değişiklikler ağ boyunca hemen yayılmaz, ancak tüm önbelleklerin süresinin dolması ve TTL'den sonra yenilenmesi gerekir. RFC 1912, uygun TTL değerlerini belirlemek için temel kuralları iletir. ⓘ

Protokol altmış sekiz yıla kadar önbelleğe almayı veya hiç önbelleğe almamayı desteklediğinden, bazı çözümleyiciler TTL değerlerini geçersiz kılabilir. Negatif önbelleğe alma, yani bir kaydın mevcut olmadığı gerçeğinin önbelleğe alınması, istenen türde hiçbir veri bulunmadığını bildirirken Yetki Başlangıcı (SOA) kaydını içermesi gereken bir bölge için yetkili isim sunucuları tarafından belirlenir. SOA kaydının minimum alanının değeri ve SOA'nın TTL'si, olumsuz yanıtın TTL'sini belirlemek için kullanılır. ⓘ

Ters arama

Ters DNS araması, IP adresi bilindiğinde alan adları için DNS'nin sorgulanmasıdır. Bir IP adresiyle birden fazla etki alanı adı ilişkilendirilebilir. DNS, IP adreslerini alan adları biçiminde, altyapı üst düzey alan adı arpa içindeki işaretçi (PTR) kayıtlarında özel olarak biçimlendirilmiş adlar olarak saklar. IPv4 için etki alanı in-addr.arpa'dır. IPv6 için, ters arama etki alanı ip6.arpa'dır. IP adresi, IPv4 için ters sıralı sekizli gösterimde ve IPv6 için ters sıralı nibble gösteriminde bir ad olarak temsil edilir. ⓘ

Bir ters arama gerçekleştirirken, DNS istemcisi, herhangi bir DNS sorgusunda olduğu gibi temsilci zincirini izleyerek bir PTR kaydı için adı sorgulamadan önce adresi bu biçimlere dönüştürür. Örneğin, 208.80.152.2 IPv4 adresinin Wikimedia'ya atandığını varsayarsak, bu adres ters sırada bir DNS adı olarak gösterilir: 2.152.80.208.in-addr.arpa. DNS çözümleyicisi bir işaretçi (PTR) isteği aldığında, 208.in-addr.arpa bölgesi için American Registry for Internet Numbers (ARIN) sunucularını işaret eden kök sunucuları sorgulayarak başlar. ARIN sunucuları 152.80.208.in-addr.arpa'yı Wikimedia'ya devreder ve çözümleyici 2.152.80.208.in-addr.arpa için başka bir sorgu gönderir, bu da yetkili bir yanıtla sonuçlanır. ⓘ

İstemci araması

DNS çözümleme sırası ⓘ

Kullanıcılar genellikle bir DNS çözümleyiciyle doğrudan iletişim kurmazlar. Bunun yerine DNS çözümlemesi web tarayıcıları, e-posta istemcileri ve diğer İnternet uygulamaları gibi uygulamalarda şeffaf bir şekilde gerçekleşir. Bir uygulama alan adı araması gerektiren bir istekte bulunduğunda, bu tür programlar yerel işletim sistemindeki DNS çözümleyicisine bir çözümleme isteği gönderir ve bu da gerekli iletişimi sağlar. ⓘ

DNS çözümleyicisi neredeyse her zaman son aramaları içeren bir önbelleğe (yukarıya bakın) sahip olacaktır. Önbellek isteğin yanıtını sağlayabiliyorsa, çözümleyici önbellekteki değeri isteği yapan programa geri gönderir. Önbellek cevabı içermiyorsa, çözümleyici isteği bir veya daha fazla belirlenmiş DNS sunucusuna gönderir. Çoğu ev kullanıcısının durumunda, makinenin bağlandığı İnternet servis sağlayıcısı genellikle bu DNS sunucusunu sağlayacaktır: böyle bir kullanıcı ya bu sunucunun adresini manuel olarak yapılandırmış ya da DHCP'nin ayarlamasına izin vermiş olacaktır; ancak, sistem yöneticilerinin sistemleri kendi DNS sunucularını kullanacak şekilde yapılandırdığı durumlarda, DNS çözümleyicileri kuruluşun ayrı olarak tutulan ad sunucularına işaret eder. Her durumda, bu şekilde sorgulanan ad sunucusu, başarılı bir sonuç bulana ya da bulamayana kadar yukarıda özetlenen süreci izleyecektir. Daha sonra sonuçlarını DNS çözümleyicisine geri gönderir; bir sonuç bulduğunu varsayarsak, çözümleyici bu sonucu gelecekte kullanmak üzere usulüne uygun olarak önbelleğe alır ve sonucu isteği başlatan yazılıma geri gönderir. ⓘ

Bozuk çözümleyiciler

Bazı büyük İSS'ler DNS sunucularını, örneğin TTL'lere uymayarak veya ad sunucularından biri yanıt vermediği için bir alan adının mevcut olmadığını belirterek kuralları ihlal edecek şekilde yapılandırmıştır. ⓘ

Web tarayıcıları gibi bazı uygulamalar, ağ üzerinden tekrarlanan aramalardan kaçınmak için dahili bir DNS önbelleği tutar. Bu uygulama, bu tür verilerin geçmişini gizlediği için DNS sorunlarını ayıklarken ekstra zorluk yaratabilir. Bu önbellekler genellikle bir dakika gibi çok kısa önbellekleme süreleri kullanır. ⓘ

Internet Explorer dikkate değer bir istisnadır: IE 3.x'e kadar olan sürümler DNS kayıtlarını varsayılan olarak 24 saat boyunca önbelleğe alır. Internet Explorer 4.x ve sonraki sürümler (IE 8'e kadar) varsayılan zaman aşımı değerini yarım saate düşürür, bu değer varsayılan yapılandırma değiştirilerek değiştirilebilir. ⓘ

Google Chrome, DNS sunucusuyla ilgili sorunlar tespit ettiğinde belirli bir hata mesajı görüntüler. ⓘ

Diğer uygulamalar

Alan Adı Sistemi başka işlevler ve özellikler de içerir. ⓘ

Ana bilgisayar adları ve IP adreslerinin bire bir eşleşmesi gerekmez. Birden fazla ana bilgisayar adı tek bir IP adresine karşılık gelebilir, bu da birçok web sitesinin tek bir ana bilgisayardan sunulduğu sanal barındırmada kullanışlıdır. Alternatif olarak, tek bir ana bilgisayar adı, bir kuruluş veya küresel İnternet genelinde birden fazla sunucu örneğine hata toleransı ve yük dağıtımını kolaylaştırmak için birçok IP adresine çözümlenebilir. ⓘ

DNS, isimleri IP adreslerine çevirmenin yanı sıra başka amaçlara da hizmet eder. Örneğin, posta aktarım aracıları e-postayı teslim edecek en iyi posta sunucusunu bulmak için DNS'yi kullanır: Bir MX kaydı, bir etki alanı ile bir posta değiştirici arasında bir eşleme sağlar; bu, ek bir hata toleransı ve yük dağıtımı katmanı sağlayabilir. ⓘ

DNS, kara listeye alınmış e-posta ana bilgisayarlarının IP adreslerinin verimli bir şekilde depolanması ve dağıtılması için kullanılır. Yaygın bir yöntem, söz konusu ana bilgisayarın IP adresini daha üst düzey bir alan adının alt etki alanına yerleştirmek ve bu adı olumlu veya olumsuz bir gösterge belirten bir kayda çözümlemektir. ⓘ

Örneğin:

• 102.3.4.5 adresi kara listeye alınmıştır. 127.0.0.1 adresine çözümlenen 5.4.3.102.blacklist.example adresine işaret eder.
• 102.3.4.6 adresi kara listede değildir ve 6.4.3.102.blacklist.example adresine işaret eder. Bu ana bilgisayar adı ya yapılandırılmamıştır ya da 127.0.0.2'ye çözümlenir.

E-posta sunucuları, kendilerine bağlanan belirli bir ana bilgisayarın kara listede olup olmadığını öğrenmek için blacklist.example adresini sorgulayabilir. Abonelik tabanlı ya da ücretsiz olan bu tür kara listelerin çoğu e-posta yöneticileri ve anti-spam yazılımları tarafından kullanılabilir. ⓘ

Bilgisayar veya ağ arızası durumunda esneklik sağlamak için, genellikle her etki alanını kapsamak üzere birden fazla DNS sunucusu sağlanır. Global DNS'in en üst seviyesinde, on üç grup kök isim sunucusu bulunur ve bunların ek "kopyaları" anycast adresleme yoluyla dünya çapında dağıtılır. ⓘ

Dinamik DNS (DDNS), bir DNS sunucusunu bir istemci IP adresiyle anında günceller, örneğin ISS'ler veya mobil sıcak noktalar arasında geçiş yaparken veya IP adresi idari olarak değiştiğinde. ⓘ

DNS mesaj formatı

DNS protokolü, sorgular ve yanıtlar olmak üzere iki tür DNS mesajı kullanır; her ikisi de aynı biçime sahiptir. Her ileti bir başlık ve dört bölümden oluşur: soru, yanıt, yetki ve ek bir boşluk. Bir başlık alanı (flags) bu dört bölümün içeriğini kontrol eder. ⓘ

Başlık bölümü aşağıdaki alanlardan oluşur: Kimlik, Bayraklar, Soru sayısı, Cevap sayısı, Yetki kaynak kayıtlarının (RR'ler) sayısı ve Ek RR'lerin sayısı. Her alan 16 bit uzunluğundadır ve verilen sırada görünür. Tanımlama alanı yanıtları sorgularla eşleştirmek için kullanılır. Bayrak alanı aşağıdaki gibi alt alanlardan oluşur:

Başlık bayrakları biçimi ⓘ

Saha	Açıklama	Uzunluk (bit)
QR	Mesajın bir sorgu mu (0) yoksa bir yanıt mı (1) olduğunu belirtir	1
OPCODE	Tür QUERY (standart sorgu, 0), IQUERY (ters sorgu, 1) veya STATUS (sunucu durum isteği, 2) olabilir	4
AA	Yetkili Yanıt, bir yanıtta, DNS sunucusunun sorgulanan ana bilgisayar adı için yetkili olup olmadığını belirtir	1
TC	TrunCation, bu mesajın aşırı uzunluk nedeniyle kesildiğini belirtir	1
RD	Özyineleme İsteniyor, istemcinin özyinelemeli bir sorgu isteyip istemediğini belirtir	1
RA	Yineleme Kullanılabilir, bir yanıtta, yanıtlayan DNS sunucusunun yinelemeyi destekleyip desteklemediğini belirtir	1
Z	Sıfır, gelecekteki kullanım için ayrılmıştır	3
RCODE	Yanıt kodu, NOERROR (0), FORMERR (1, Biçim hatası), SERVFAIL (2), NXDOMAIN (3, Var olmayan alan) vb. olabilir.	4

Bayraktan sonra başlık, aynı sırayla takip eden bölümlerin her birindeki kayıt sayısını içeren dört adet 16 bitlik tamsayı ile sona erer. ⓘ

Soru bölümü

Soru bölümü, diğer bölümlerde kullanılan kaynak kaydı formatından daha basit bir formata sahiptir. Her soru kaydı (bölümde genellikle sadece bir tane bulunur) aşağıdaki alanları içerir:

Kaynak kaydı (RR) alanları ⓘ

Saha	Açıklama	Uzunluk (sekizli)
İSİM	İstenen kaynağın adı	Değişken
TİP	RR Türü (A, AAAA, MX, TXT, vb.)	2
SINIF	Sınıf kodu	2

Alan adı, birleştirilen ayrı etiketlere bölünür; her etiketin önüne o etiketin uzunluğu eklenir. ⓘ

DNS aktarım protokolleri

DNS-over-UDP/53 ("Do53")

1983'te ortaya çıkışından yakın zamana kadar DNS öncelikle 53 numaralı Kullanıcı Datagram Protokolü (UDP) bağlantı noktasındaki sorguları yanıtlamıştır. Bu tür sorgular, istemciden tek bir UDP paketinde gönderilen ve sunucudan tek bir UDP paketinde gönderilen açık metin yanıtıyla yanıtlanan açık metin isteğinden oluşur. Yanıtın uzunluğu 512 baytı aştığında ve hem istemci hem de sunucu DNS için Uzantı Mekanizmalarını (EDNS) desteklediğinde, daha büyük UDP paketleri kullanılabilir. DNS-üzerinden-UDP kullanımı, diğer şeylerin yanı sıra, aktarım katmanı şifrelemesi, kimlik doğrulama, güvenilir teslimat ve ileti uzunluğu eksikliği nedeniyle sınırlıdır. ⓘ

TCP/53 üzerinden DNS ("Do53/TCP")

1989 yılında RFC 1123, DNS sorguları, yanıtları ve özellikle bölge aktarımları için isteğe bağlı İletim Kontrol Protokolü (TCP) aktarımını belirtmiştir. TCP, uzun yanıtların parçalanması yoluyla daha uzun yanıtlara, güvenilir teslimata ve istemciler ile sunucular arasında uzun ömürlü bağlantıların yeniden kullanılmasına olanak tanır. ⓘ

DNSCrypt

2011'de IETF standartları çerçevesi dışında geliştirilen DNSCrypt protokolü, özyinelemeli çözümleyicilerin aşağı akış tarafında DNS şifrelemesini tanıttı; burada istemciler, sunucuların DNS'de yayınlanan (üçüncü taraf sertifika yetkililerine güvenmek yerine) ve DNSSEC imzalarıyla korunabilen genel anahtarlarını kullanarak sorgu yüklerini şifreler. DNSCrypt, HTTPS şifreli web trafiği ile aynı bağlantı noktası olan TCP veya UDP bağlantı noktası 443'ü kullanır. Bu, yalnızca sorgunun içeriğiyle ilgili gizliliği değil, aynı zamanda önemli ölçüde güvenlik duvarı aşma özelliğini de beraberinde getirmiştir. 2019'da DNSCrypt, önerilen "Oblivious DNS "e benzer şekilde, bir giriş düğümünün farklı bir sunucunun ortak anahtarıyla şifrelenmiş bir sorgu aldığı ve bunu bir çıkış düğümü olarak hareket eden ve özyinelemeli çözümlemeyi gerçekleştiren sunucuya ilettiği "anonimleştirilmiş" bir modu desteklemek için daha da genişletildi. Giriş düğümü sorgunun içeriğini bilmediğinden ve çıkış düğümleri istemcinin kimliğini bilmediğinden kullanıcı/sorgu çiftlerinin gizliliği sağlanır. DNSCrypt ilk olarak 2011 yılının Aralık ayında OpenDNS tarafından üretimde uygulanmıştır. ⓘ

DNS-over-TLS ("DoT")

Şifrelenmiş DNS için bir IETF standardı 2016 yılında ortaya çıkmış ve sadece DNS yükü yerine tüm bağlantıyı korumak için standart Taşıma Katmanı Güvenliği (TLS) kullanmıştır. DoT sunucuları TCP bağlantı noktası 853'ü dinler. RFC7858, fırsatçı şifrelemenin ve kimliği doğrulanmış şifrelemenin desteklenebileceğini belirtir, ancak sunucu veya istemci kimlik doğrulamasını zorunlu kılmaz. ⓘ

HTTPS üzerinden DNS ("DoH")

DNS sorgu aktarımı için rakip bir standart 2018 yılında tanıtıldı ve DNS sorgu verilerini HTTPS üzerinden tünelledi (bu da HTTP'yi TLS üzerinden taşır). DoH, DNSCrypt gibi TCP bağlantı noktası 443 üzerinde seyahat ettiği ve bu nedenle web trafiğine benzediği için DNS'ye daha web dostu bir alternatif olarak tanıtıldı, ancak pratikte kolayca ayırt edilebilirler. DoH, DoT'ye göre kullanıcı anonimliğini azalttığı için yaygın olarak eleştirilmiştir. ⓘ

DNS-over-TOR

Diğer İnternet protokolleri gibi DNS de VPN'ler ve tüneller üzerinden çalıştırılabilir. 2019'dan bu yana kendi sık kullanılan kısaltmasını hak edecek kadar yaygın hale gelen bir kullanım, Tor üzerinden DNS'dir. Oblivious DNS'in gizlilik kazanımları, TLS tarafından sağlanan aktarım katmanı şifrelemesiyle eşleştirilmiş, önceden var olan Tor giriş ve çıkış düğümleri ağının kullanılmasıyla elde edilebilir. ⓘ

HTTPS üzerinden Oblivious DNS ("ODoH")

2021 yılında, DoH'un "kayıtsız" bir uygulaması önerilmiş ve giriş/çıkış ayrımını HTTPS tünelleme ve TLS taşıma katmanı şifrelemesiyle tek bir tanımlı protokolde birleştiren taslak formda uygulanmıştır. ⓘ

Kaynak kayıtları

Alan Adı Sistemi, ağ kaynakları için bir bilgi öğeleri veritabanı belirtir. Bilgi öğelerinin türleri, DNS kayıt türlerinin bir listesi olan kaynak kayıtları (RR'ler) ile kategorize edilir ve düzenlenir. Her kaydın bir türü (adı ve numarası), bir sona erme süresi (yaşama süresi), bir sınıfı ve türe özgü verileri vardır. Aynı türdeki kaynak kayıtları, özel bir sıralamaya sahip olmayan bir kaynak kaydı kümesi (RRset) olarak tanımlanır. DNS çözümleyicileri sorgu üzerine tüm kümeyi döndürür, ancak sunucular yük dengeleme sağlamak için round-robin sıralaması uygulayabilir. Buna karşılık, Alan Adı Sistemi Güvenlik Uzantıları (DNSSEC) kanonik sıralamada tüm kaynak kaydı kümesi üzerinde çalışır. ⓘ

Bir İnternet Protokolü ağı üzerinden gönderildiğinde, tüm kayıtlar RFC 1035'te belirtilen ortak biçimi kullanır:

Kaynak kaydı (RR) alanları ⓘ

Saha	Açıklama	Uzunluk (sekizli)
İSİM	Bu kaydın ait olduğu düğümün adı	Değişken
TİP	Sayısal formda RR türü (örneğin, MX RR'ler için 15)	2
SINIF	Sınıf kodu	2
TTL	RR'nin geçerli kalacağı saniye sayısı (Maksimum 231-1, yani yaklaşık 68 yıl)	4
RDLENGTH	RDATA alanının uzunluğu (sekizli olarak belirtilir)	2
RDATA	RR'ye özgü ek veriler	Değişken, RDLENGTH'e göre

NAME, ağaçtaki düğümün tam nitelikli alan adıdır . Tel üzerinde, isim, pakette daha önce belirtilen alan adlarının sonlarının mevcut alan adının sonuyla değiştirilebildiği etiket sıkıştırması kullanılarak kısaltılabilir. ⓘ

TYPE kayıt türüdür. Verinin formatını gösterir ve kullanım amacı hakkında ipucu verir. Örneğin, A kaydı bir alan adından IPv4 adresine çevirmek için kullanılır, NS kaydı bir DNS bölgesinde hangi ad sunucularının aramalara yanıt verebileceğini listeler ve MX kaydı bir e-posta adresinde belirtilen bir alan adı için postayı işlemek için kullanılan posta sunucusunu belirtir. ⓘ

RDATA, adres kayıtları için IP adresi veya MX kayıtları için öncelik ve ana bilgisayar adı gibi türe özgü verilerdir. İyi bilinen kayıt türleri RDATA alanında etiket sıkıştırması kullanabilir, ancak "bilinmeyen" kayıt türleri kullanmamalıdır (RFC 3597). ⓘ

İnternet ana bilgisayar adlarını, sunucularını veya IP adreslerini içeren yaygın DNS kayıtları için bir kaydın SINIFI IN (İnternet için) olarak ayarlanır. Ayrıca Kaos (CH) ve Hesiod (HS) sınıfları da mevcuttur. Her sınıf, DNS bölgelerinin potansiyel olarak farklı delegasyonlarına sahip bağımsız bir ad alanıdır. ⓘ

Alan adı sistemi, bir bölge dosyasında tanımlanan kaynak kayıtlarına ek olarak, bölge aktarımları (AXFR/IXFR) gerçekleştirirken veya EDNS (OPT) için olduğu gibi yalnızca diğer DNS düğümleriyle iletişimde (kablo üzerinde) kullanılan çeşitli istek türleri de tanımlar. ⓘ

Joker Karakter DNS kayıtları

Alan adı sistemi, yıldız işareti olan '*' ile başlayan adları belirten joker DNS kayıtlarını destekler; örneğin, *.example. Joker alan adlarına ait DNS kayıtları, tüm etiketleri belirtilen alt öğeler de dahil olmak üzere sorgu adının eşleşen bileşenleriyle değiştirerek tek bir DNS bölgesi içinde kaynak kayıtları oluşturmaya yönelik kuralları belirtir. Örneğin, aşağıdaki yapılandırmada x.example DNS bölgesi, x.example alt etki alanlarının alt etki alanları da dahil olmak üzere tüm alt etki alanlarının a.x.example posta değiştiricisini (MX) kullanacağını belirtir. Posta değiştirici IP adresini belirtmek için a.x.example için A kaydı gereklidir. Bunun sonucunda bu alan adı ve alt alan adları joker eşleşmelerinin dışında kalacağından, a.x.example alt alan adı için ek bir MX kaydının yanı sıra tüm alt alan adları için joker MX kaydının da DNS bölgesinde tanımlanması gerekir. ⓘ

x.example.       MX 10 a.x.example.
*.x.example.     MX 10 a.x.example.
*.a.x.example.   MX 10 a.x.example.
a.x.example.     MX 10 a.x.example.
a.x.example.     AAAA 2001:db8::1 <span title="Kaynak: İngilizce Vikipedi, Bölüm &quot;Wildcard DNS records&quot;" class="plainlinks">[https://en.wikipedia.org/wiki/Domain_Name_System#Wildcard_DNS_records <span style="color:#dddddd">ⓘ</span>]</span>

RFC 1034'teki orijinal tanım eksik olduğu ve uygulayıcılar tarafından yanlış yorumlamalara yol açtığı için joker kayıtların rolü RFC 4592'de geliştirilmiştir. ⓘ

Protokol uzantıları

Orijinal DNS protokolünün yeni özelliklerle genişletilmesi için sınırlı hükümleri vardı. Paul Vixie 1999 yılında RFC 2671'de (yerini RFC 6891 almıştır) DNS için Uzatma Mekanizmaları (EDNS) adı verilen ve kullanılmadığında ek yükü artırmadan isteğe bağlı protokol öğeleri sunan bir uzatma mekanizması yayınlamıştır. Bu, herhangi bir bölge dosyasında değil, yalnızca protokolün tel iletimlerinde bulunan OPT sözde kaynak kaydı aracılığıyla gerçekleştirilmiştir. UDP datagramlarında DNS mesaj boyutunun artırılması gibi ilk uzantılar da önerilmiştir (EDNS0). ⓘ

Dinamik bölge güncellemeleri

Dinamik DNS güncelleştirmeleri, yetkili bir DNS sunucusunda tutulan bir bölge veritabanından dinamik olarak kaynak kayıtları eklemek veya kaldırmak için UPDATE DNS işlem kodunu kullanır. Bu özellik RFC 2136'da açıklanmıştır. Bu özellik, ağ istemcileri önyüklendiklerinde veya ağda başka bir şekilde kullanılabilir hale geldiklerinde DNS'ye kaydetmek için kullanışlıdır. Önyükleme yapan bir istemciye DHCP sunucusundan her seferinde farklı bir IP adresi atanabileceğinden, bu tür istemciler için statik DNS atamaları sağlamak mümkün değildir. ⓘ

Güvenlik sorunları

Başlangıçta, ağ genel halkın katılımına açık olmadığından, güvenlik endişeleri DNS yazılımı veya ilk İnternet'te kullanılacak herhangi bir yazılım için önemli tasarım hususları değildi. Ancak 1990'larda İnternet'in ticari sektöre doğru genişlemesi, veri bütünlüğünü ve kullanıcı kimlik doğrulamasını korumak için güvenlik önlemleri gereksinimlerini değiştirdi. ⓘ

Çeşitli güvenlik açığı sorunları keşfedildi ve kötü niyetli kullanıcılar tarafından istismar edildi. Bu sorunlardan biri, verilerin yetkili bir kaynak sunucu olduğu iddiasıyla önbellek çözümleyicilerine dağıtıldığı ve böylece veri deposunun potansiyel olarak yanlış bilgilerle ve uzun sona erme süreleriyle (yaşam süresi) kirletildiği DNS önbellek zehirlenmesidir. Daha sonra, meşru uygulama talepleri kötü niyetle işletilen ağ ana bilgisayarlarına yönlendirilebilir. ⓘ

DNS yanıtları geleneksel olarak kriptografik bir imzaya sahip değildir, bu da birçok saldırı olasılığına yol açar; Alan Adı Sistemi Güvenlik Uzantıları (DNSSEC), kriptografik olarak imzalanmış yanıtlar için destek eklemek üzere DNS'yi değiştirir. DNSCurve, DNSSEC'e alternatif olarak önerilmiştir. TSIG gibi diğer uzantılar, güvenilir eşler arasında kriptografik kimlik doğrulama için destek ekler ve genellikle bölge aktarımı veya dinamik güncelleme işlemlerini yetkilendirmek için kullanılır. ⓘ

Bazı alan adları sahtecilik efektleri elde etmek için kullanılabilir. Örneğin, paypal.com ve paypa1.com farklı isimlerdir, ancak kullanıcılar kullanıcının seçtiği yazı tipine bağlı olarak grafiksel bir kullanıcı arayüzünde bunları ayırt edemeyebilir. Birçok yazı tipinde l harfi ve 1 rakamı çok benzer, hatta aynı görünür. Bu sorun, ISO 10646'daki birçok karakter kodu tipik bilgisayar ekranlarında aynı görünebileceğinden, uluslararasılaştırılmış alan adlarını destekleyen sistemlerde ciddi bir sorundur. Bu güvenlik açığı zaman zaman kimlik avında kullanılmaktadır. ⓘ

İleri doğrulamalı ters DNS gibi teknikler de DNS sonuçlarının doğrulanmasına yardımcı olmak için kullanılabilir. ⓘ

DNS, yapılandırmalarına dikkat edilmediği takdirde, başka türlü güvenli veya özel bağlantılardan da "sızabilir" ve DNS zaman zaman kötü niyetli kişiler tarafından güvenlik duvarlarını aşmak ve genellikle zararsız olarak görüldüğünden veri sızdırmak için kullanılmıştır. ⓘ

Gizlilik ve izleme sorunları

Başlangıçta halka açık, hiyerarşik, dağıtık ve yoğun önbellekli bir veritabanı olarak tasarlanan DNS protokolünde hiçbir gizlilik kontrolü yoktur. Kullanıcı sorguları ve ad sunucusu yanıtları şifrelenmeden gönderilmekte, bu da ağ paketi koklama, DNS ele geçirme, DNS önbellek zehirlenmesi ve ortadaki adam saldırılarına olanak sağlamaktadır. Bu eksiklik, siber suçlular ve ağ operatörleri tarafından pazarlama amaçları, tutsak portallarda kullanıcı kimlik doğrulaması ve sansür için yaygın olarak kullanılmaktadır. ⓘ

Kullanıcı gizliliği, İçerik Dağıtım Ağlarının yararı için DNS sorgularında (RFC 7871) istemci IP bilgisi seviyesinin artırılmasına yönelik önerilerle daha da açığa çıkmaktadır. ⓘ

DNS ile ilgili gizlilik sorunlarına karşı kullanılan ana yaklaşımlar:

• DNS çözümlemesini VPN operatörüne taşıyan ve kullanıcı trafiğini yerel İSS'den gizleyen VPN'ler,
• Geleneksel DNS çözümlemesini anonim .onion alan adlarıyla değiştiren Tor, hem ad çözümlemesini hem de kullanıcı trafiğini onion yönlendirme karşı gözetiminin arkasına gizler,
• Proxy'ler ve genel DNS sunucuları, gerçek DNS çözümlemesini, genellikle çok az veya hiç istek kaydı ve DNS düzeyinde reklam veya pornografi engelleme gibi isteğe bağlı ek özellikler vaat eden üçüncü taraf bir sağlayıcıya taşır.
  • Genel DNS sunucuları geleneksel DNS protokolü kullanılarak sorgulanabilir, bu durumda yerel gözetime karşı hiçbir koruma sağlamazlar veya bu tür bir koruma sağlayan HTTPS üzerinden DNS, TLS üzerinden DNS ve DNSCrypt ⓘ

Yerel ağ operatörü tarafından DNS incelemesini engelleyen çözümler, kurumsal ağ güvenlik politikalarını ve İnternet sansürünü engellediği için eleştirilmektedir. Ayrıca, DNS çözümlemesini kullanıcı trafiğinden para kazanmasıyla bilinen az sayıda şirketin eline bıraktığı ve genellikle İnternet için zararlı olarak algılanan DNS isim çözümlemesini merkezileştirdiği için gizlilik açısından da eleştirilmektedir. ⓘ

Google, Android'de platformun, Chrome'da tarayıcının ve 8.8.8.8 hizmetinde DNS çözümleyicisinin hakim sağlayıcısıdır. Bu senaryo, tek bir kurumsal varlığın İnternet'in tüm isim alanını kapsayıcı bir şekilde kontrol ettiği bir durum olabilir mi? Netflix, uygulamanın üzerinde çalıştığı platformdan bağımsız olarak kendi DNS çözümleme mekanizmasını kullanan bir uygulamaya sahipti. Ya Facebook uygulaması DoH'u da içeriyor olsaydı? Apple'ın iOS'u yerel DNS çözümlemesini atlamak ve Apple'ın platformlarından gelen tüm DNS sorgularını Apple tarafından işletilen bir dizi ad çözümleyicisine yönlendirmek için bir DoH çözümleme mekanizması kullansaydı ne olurdu?

- DNS Gizliliği ve IETF ⓘ

Alan adı kaydı

Bir alan adını kullanma hakkı, İnternet Tahsisli Sayılar ve İsimler Kurumu (ICANN) veya OpenNIC gibi İnternet'in isim ve sayı sistemlerini denetlemekle görevli diğer kuruluşlar tarafından akredite edilen alan adı kayıt kuruluşları tarafından devredilir. ICANN'e ek olarak, her bir üst düzey alan adı (TLD), bir kayıt kuruluşu işleten bir idari kuruluş tarafından teknik olarak korunur ve hizmet verilir. Bir kayıt kuruluşu, yetkili bölgesi içindeki isimlerin veritabanını işletmekten sorumludur, ancak bu terim çoğunlukla TLD'ler için kullanılır. Kayıt sahibi, alan adı kaydı talebinde bulunan kişi veya kuruluştur. Kayıt kuruluşu, ilgili bölgede ad atamaya yetkili (akredite) olan her alan adı kayıt kuruluşundan kayıt bilgilerini alır ve WHOIS protokolünü kullanarak bilgileri yayınlar. 2015 yılı itibariyle RDAP kullanımı düşünülmektedir. ⓘ

ICANN TLD'lerin, TLD kayıt kuruluşlarının ve alan adı kayıt kuruluşlarının tam listesini yayınlar. Alan adlarıyla ilişkili alan adı sahibi bilgileri, WHOIS hizmetiyle erişilebilen çevrimiçi bir veritabanında tutulur. 290'dan fazla ülke kodu üst düzey alan adının (ccTLD'ler) çoğu için WHOIS (Alan adı sahibi, ad sunucuları, sona erme tarihleri, vb.) bilgilerini alan adı kayıt kuruluşları tutar. Örneğin, DENIC, Almanya NIC, DE alan adı verilerini elinde tutmaktadır. Yaklaşık 2001 yılından itibaren, çoğu Jenerik üst düzey alan adı (gTLD) kayıt kuruluşu, kalın kayıt kuruluşu yaklaşımı olarak adlandırılan bu yaklaşımı benimsemiştir, yani WHOIS verilerini kayıt kuruluşu veritabanları yerine merkezi kayıt kuruluşlarında tutmaktadır. ⓘ

COM ve NET üzerindeki üst düzey alan adları için ince kayıt modeli kullanılmaktadır. Alan adı kaydı (örneğin, GoDaddy, BigRock ve PDR, VeriSign, vb.) temel WHOIS verilerini (yani, kayıt şirketi ve ad sunucuları, vb.) tutar. Öte yandan ORG'yi kullanan kuruluşlar veya alan adı sahipleri yalnızca Kamu Yararı Sicilinde yer alır. ⓘ

Genellikle ağ bilgi merkezleri (NIC) olarak adlandırılan bazı alan adı kayıt kuruluşları, WHOIS veri kümelerine erişim sağlamanın yanı sıra son kullanıcılar için kayıt kuruluşu olarak da işlev görür. COM, NET ve ORG alan adları gibi üst düzey alan adı kayıt kuruluşları, birçok alan adı kayıt kuruluşundan oluşan bir kayıt kuruluşu modeli kullanır. Bu yönetim yönteminde, kayıt kuruluşu yalnızca alan adı veritabanını ve kayıt kuruluşlarıyla olan ilişkiyi yönetir. Tescil ettirenler (bir alan adının kullanıcıları), bazı durumlarda bayilerin ek alt yükleniciliği yoluyla tescil ettirenin müşterileridir. ⓘ

RFC belgeleri

Standartlar

Alan Adı Sistemi, Internet Engineering Task Force (Internet standartları) tarafından yayınlanan Request for Comments (RFC) belgeleri ile tanımlanır. Aşağıda DNS protokolünü tanımlayan RFC'lerin bir listesi bulunmaktadır.

• RFC 1034, Alan Adları - Kavramlar ve Özellikler
• RFC 1035, Alan Adları - Uygulama ve Spesifikasyon
• RFC 1123, İnternet Ana Bilgisayarları için Gereksinimler-Uygulama ve Destek
• RFC 1995, DNS'de Artımlı Bölge Aktarımı
• RFC 1996, Bölge Değişikliklerinin Anında Bildirimi için Bir Mekanizma (DNS NOTIFY)
• RFC 2136, Alan Adı Sisteminde Dinamik Güncellemeler (DNS UPDATE)
• RFC 2181, DNS Spesifikasyonuna İlişkin Açıklamalar
• RFC 2308, DNS Sorgularının Negatif Önbelleğe Alınması (DNS NCACHE)
• RFC 2672, Terminal Dışı DNS Adı Yeniden Yönlendirme
• RFC 2845, DNS için Gizli Anahtar İşlem Kimlik Doğrulaması (TSIG)
• RFC 3225, DNSSEC'in Çözümleyici Desteğini Gösterme
• RFC 3226, DNSSEC ve IPv6 A6 farkında sunucu/çözücü ileti boyutu gereksinimleri
• RFC 3596, IP Sürüm 6'yı Desteklemek için DNS Uzantıları
• RFC 3597, Bilinmeyen DNS Kaynak Kaydı (RR) Türlerinin İşlenmesi
• RFC 4343, Alan Adı Sistemi (DNS) Büyük/Küçük Harf Duyarsızlığı Açıklaması
• RFC 4592, Alan Adı Sisteminde Joker Karakterlerin Rolü
• RFC 4635, HMAC SHA TSIG Algoritma Tanımlayıcıları
• RFC 5001, DNS Ad Sunucusu Tanımlayıcısı (NSID) Seçeneği
• RFC 5011, DNS Güvenliği (DNSSEC) Güven Çapalarının Otomatik Güncellemeleri
• RFC 5452, DNS'yi Sahte Yanıtlara Karşı Daha Dayanıklı Hale Getirmek için Önlemler
• RFC 5890, Uygulamalar için Uluslararasılaştırılmış Alan Adları (IDNA): Tanımlar ve Belge Çerçevesi
• RFC 5891, Uygulamalarda Uluslararasılaştırılmış Alan Adları (IDNA): Protokol
• RFC 5892, Unicode Kod Noktaları ve Uygulamalar için Uluslararasılaştırılmış Alan Adları (IDNA)
• RFC 5893, Uygulamalar için Uluslararasılaştırılmış Alan Adları (IDNA) için Sağdan Sola Komut Dosyaları
• RFC 6891, DNS için Uzantı Mekanizmaları (EDNS0)
• RFC 7766, TCP Üzerinden DNS Aktarımı - Uygulama Gereksinimleri ⓘ

Önerilen güvenlik standartları

• RFC 4033, DNS Güvenliği Giriş ve Gereksinimler
• RFC 4034, DNS Güvenlik Uzantıları için Kaynak Kayıtları
• RFC 4035, DNS Güvenlik Uzantıları için Protokol Değişiklikleri
• RFC 4509, DNSSEC Delegasyon İmzalayıcı (DS) Kaynak Kayıtlarında SHA-256 Kullanımı
• RFC 4470, NSEC Kayıtlarını Asgari Düzeyde Kapsama ve DNSSEC Çevrimiçi İmzalama
• RFC 5155, DNS Güvenliği (DNSSEC) Kareli Kimlik Doğrulamalı Varoluş Reddi
• RFC 5702, DNSSEC için DNSKEY ve RRSIG Kaynak Kayıtlarında RSA ile SHA-2 Algoritmalarının Kullanımı
• RFC 5910, Genişletilebilir Sağlama Protokolü (EPP) için Alan Adı Sistemi (DNS) Güvenlik Uzantıları Eşlemesi
• RFC 5933, DNSSEC için DNSKEY ve RRSIG Kaynak Kayıtlarında GOST İmza Algoritmalarının Kullanımı
• RFC 7830, EDNS(0) Dolgu Seçeneği
• RFC 7858, Aktarım Katmanı Güvenliği (TLS) üzerinden DNS için Özellikler
• RFC 8310, TLS üzerinden DNS ve DTLS üzerinden DNS için Kullanım Profilleri
• RFC 8484, HTTPS üzerinden DNS Sorguları (DoH) ⓘ

Deneysel RFC'ler

• RFC 1183, Yeni DNS RR Tanımları ⓘ

En İyi Güncel Uygulamalar

• RFC 2182, İkincil DNS Sunucularının Seçimi ve Çalıştırılması (BCP 16)
• RFC 2317, Sınıfsız IN-ADDR.ARPA delegasyonu (BCP 20)
• RFC 5625, DNS Proxy Uygulama Yönergeleri (BCP 152)
• RFC 6895, Alan Adı Sistemi (DNS) IANA Hususları (BCP 42)
• RFC 7720, DNS Kök Ad Hizmeti Protokolü ve Dağıtım Gereksinimleri (BCP 40) ⓘ

Bilgilendirici RFC'ler

Bu RFC'ler tavsiye niteliğindedir, ancak bir standart veya BCP tanımlamamasına rağmen yararlı bilgiler sağlayabilir. (RFC 1796) ⓘ

• RFC 1178, Bilgisayarınız İçin Bir Ad Seçme (FYI 5)
• RFC 1591, Alan Adı Sistemi Yapısı ve Delegasyonu
• RFC 1912, Yaygın DNS İşletim ve Yapılandırma Hataları
• RFC 2100, Ana Bilgisayarların Adlandırılması
• RFC 3696, Adların Denetlenmesi ve Dönüştürülmesi için Uygulama Teknikleri
• RFC 3833. Alan Adı Sisteminin (DNS) Tehdit Analizi
• RFC 4892, Ad Sunucusu Örneğini Tanımlayan Bir Mekanizma için Gereksinimler
• RFC 5894, Uygulamalar için Uluslararasılaştırılmış Alan Adları (IDNA): Arka Plan, Açıklama ve Gerekçe
• RFC 5895, Uygulamalarda Uluslararasılaştırılmış Alan Adları için Karakter Eşleme (IDNA) 2008
• RFC 7626, DNS Gizlilik Hususları
• RFC 7706, Birini Geri Döngüde Çalıştırarak Kök Sunuculara Erişim Süresini Azaltma
• RFC 8499, DNS Terminolojisi ⓘ

Bilinmiyor

Bu RFC'lerin resmi statüsü Bilinmiyor'dur, ancak yaşları nedeniyle bu şekilde açıkça etiketlenmemiştir. ⓘ

• RFC 920, Alan Adı Gereksinimleri - Belirtilen orijinal üst düzey alan adları
• RFC 1032, Etki Alanı Yöneticileri Kılavuzu
• RFC 1033, Etki Alanı Yöneticileri İşlem Kılavuzu
• RFC 1101, Ağ Adlarının ve Diğer Türlerin DNS Kodlamaları ⓘ

DNS’in Tarihçesi

Bilgisayar ağları üzerindeki isimlendirme sorunu ilk olarak internetin babası sayılan Arpanet zamanında ortaya çıkmıştır. 1970’lerde ArpaNet günümüz ağları ile karşılaştırılamayacak kadar küçük durumdaydı ve yalnızca birkaç yüz ile ifade edilebilen sisteme hizmet veriyordu. Bu tarihlerde isimlendirme için tek noktada tutulan bir dosyanın bulunması ve diğer tüm sistemlerin bu dosyayı belli aralıklarla kendi taraflarında güncellemesi isimlendirme sorununu çözmüştü. ⓘ

Adres-isim tanımlamalarını içeren HOSTS.TXT dosyası SRI tarafından SRI-NIC (Stanford Research Institute – Network Information Center) adında bir bilgisayar üzerinde tutulmaktaydı. Bu dosya her adrese bir isim karşılık gelecek şekilde düzenlenmişti. Arpanet üzerindeki yeni isim tanımlamaları ve değişiklikleri SRI’ya gönderilen e-postalar arcılığı ile yapılıyor ve HOSTS.TXT’in kopyası File Transfer Protocol ile alınıyordu. ⓘ

Arpanet üzerinde TCP/IP kullanımına paralel olarak ortaya çıkan bağlantı patlaması, isim çözümü için birçok sunucuda ve her bilgisayara özgün bir isim atanmasında problemler yaşanmaktaydı. Ayrıca yalnızca isim çözümlenmesi için oldukça yüksek miktarda bant genişliği harcanmaktaydı. Buna rağmen kullanılan isim veritabanlarının uyumlu olması her zaman sağlanamamaktaydı. ⓘ

Bu durumun ortaya çıkmasından sonra Arpanet daha ölçeklenebilir bir isim çözümleme yapısı için araştırmalara başladı. Paul Mockapetris bu işle görevlendirildi. Mockapetris 1984 yılında Domain Name System (DNS)’i tanımlayan RFC 882 ve RFC 883’ü yayınladı. Bunlar daha sonra hâlen geçerli olan RFC 1034 ve RFC 1035 tarafından güncellendiler. ⓘ

DNS'in Yapısı

Resolving (Çözümleme) - Aranılan bir kaydı bulma işlemi

• Mesela http://google.com.tr 3 Ekim 2020 tarihinde Wayback Machine sitesinde arşivlendi. adresine karşılık gelen IPv4 adresinin olmasının bulunması. Çözümleme yapan yazılımlar iki çeşit işlem yaparlar; özyineli çözümleme ve özyineli olmayan çözümleme. Sorgularda gönderilen RD (recursion required - özyineli gerekli) bitlerine göre sorgunun türü belirlenir. Özyineli olmayan sorgulara cevap veren sunucular cevap olarak ardışık isim sunucuları verirler. Sonuç olarak yapılan bir sorgu özyineli değil ise http://google.com.tr 3 Ekim 2020 tarihinde Wayback Machine sitesinde arşivlendi. için doğrudan 8.8.8.8 IP'si ya da "makine bulunamadı" cevabı verilebilir. Fakat özyineli bir sorguda cevabı bulmak için başka bir isim sunucusunun IP'sini verebilir. ⓘ

Authoritive Nameserving (Yetkili İsim Sunumu)

• Bir alan hakkında bilgi bulunduran sunucudur. Mesela yildiz.edu.tr alanının MX (Mail eXchanger), NS (Name Server), A (Address)(Bunlar - Resource Record - Özkaynak Kaydı olarak bilinir) kayıtlarının tutulduğu isim sunucusudur ⓘ

DNS Sorgulama

DNS; mail sunucuları, domain isimleri ve IP adresleri gibi bilgileri tutan hiyerarşik bir yapıdır. Bir DNS istemcisi, ad çözümlemesi yapmak için DNS sunucularını sorgular. DNS hizmetleri; kullanıcının girdiği bir DNS adını çözüp, IP adresi gibi o ad ile ilişkili bilgileri oluşturur. ⓘ

DNS sorgulaması yapmadan önce yapılan bir tarama sonucunda, DNS bilgileri 'name servers(NS)' ya da 'domain servers' olarak görülür. Bu bilgilerin erişiminden sonra DNS sorgulamasıyla daha fazla bilgiye ulaşılır. ⓘ

Yanlış yapılandırılmış bir DNS sunucusu sonucunda 'Bölge Transferi(Zone Transfer)' olarak bilinen atak yapılabilir. Bölge transferi ile DNS sorgusu yapılan hedefle ilgili birçok bilgiye ulaşılabilir. Bölge transferi; DNS sunucusunun çalıştığı domain ile ilgili bütün verileri içerir. Bu önemli bilgilerin içinde e-posta sunucusunun ismi, IP adresi, kullanılan işletim sistemi ile ilgili bilgiler vardır. ⓘ

Bölge transferlerine karşı bir önlem olarak güvenlik duvarında(firewall) veya ağ geçitlerindeki yönlendiricilerde 53 numaralı TCP portu gelen tüm yetkisiz bağlantılara karşı kapalı tutulmalıdır. ⓘ

DNS sorgulamasından bir korunma yöntemi olarak alan adı bir domain değilse, -.tr uzantısı ile sonlanmıyorsa 'private domain' haline getirmek bazı tehlikelerden korur. Private domain olan alan adlarında kişisel bilgiler 'Private' halini alır. Yani gerçek bilgiler gizlenir. Ama private domain her domain sağlayıcıda yoktur. ⓘ

DNS Sorgulamalarına Karşı Alınacak Önlemler

• DNS bilgileri önemli bilgilerdir. DNS sunucuları ayarlanırken sistemle ilgili çok az bilgi verilmelidir. Sunucuya isim verilirken işletim sistemini çağrıştıracak bir isim verilmemelidir. Ayrıca kullanılan işletim sistemiyle ilgili yer boş bırakılmalıdır.
• Güvenlik duvarı kullanılmalıdır ya da yetkisiz bağlantıları önlemek için ağ geçitlerindeki yönlendiricilerdeki port durumlarına dikkat edilmelidir. DNS, UDP ile 53 numaralı portu; bölge transferi(Zone Transfer) ise TCP ile 53 numaralı portu kullandığından bunun önlemleri alınmalıdır. Bu portlar yetkisiz bağlantılara karşı kapatılmalıdır.
• İç ağ için ayrı, internet için ayrı bir DNS sunucusu kullanmak. Kullanıcı internete çıkmak isterse iç DNS sunucusu bu isteği alıp proxy sunucusu gibi davranarak isteği dış DNS sunucusuna iletir. Böylece ağ dışından olan biri sadece dış DNS'teki isimlere erişir.
• com : Ticari kuruluşları gösterir.
• edu : Eğitim kurumlarını gösterir.
• org : Ticari olmayan, hükûmete de bağlı bulunmayan kurumları gösterir.
• net : Internet omurgası işlevini üstlenen ağları gösterir.
• gov : Hükûmete bağlı kurumları gösterir.
• mil : Askeri kurumları gösterir.
• num : Telefon numaralarını bulabileceğiniz yerleri gösterir.
• arpa : Ters DNS sorgulaması yapılabilecek yerleri gösterir. ⓘ

Bu isimlere yakın zaman önce biz gibi uzantılar da eklenmiştir. Alan isimleri, ağaç yapısı denilen ve belli bir kurala göre dallanan bir yapıda kullanılmaktadır. Amerika Birleşik Devletleri haricinde, internete bağlı olan tüm ülkelerdeki adresler, o ülkenin ISO3166 ülkekodu ile bitmektedir. Türkiye'deki tüm alt alan adresleri, .tr ile bitmektedir. Örneğin; marine.ulakbim.gov.tr adresinde;

• tr Türkiye'yi,
• gov alt alanın devlet kurumu olduğunu
• ulakbim bu devlet kurumunu
• marine bu kurumda bulunan bir makineyi göstermektedir. ⓘ

İç bağlantılar

• Bind ⓘ

ⓘ