dig
Daha önce "Bir sayfanın İnternetteki Serüveni" başlığında karşılaştığımız dig komutu (Domain Information Groper), bir IP adresi için DNS sorgusu yapmaya yarar. Sistem yöneticilerinin sıkça kullandığı bu aracın bilinmesi gereken birkaç parametresi bulunur.
Temel Kullanım ve Sonuçları
En temel kullanım, bir alan adının DNS kayıtlarını sorgulamak için şu şekilde gerçekleştirilir.
Yukarıdaki çıktı, veritech.net adresinin A kaydını (IPv4 adresi) göstermektedir. Çıktı birkaç bölümden oluşur:
HEADER: Sorgu ve yanıt hakkında genel bilgiler (opcode, status, flags, ID).
QUESTION SECTION: Hangi alan adı ve kayıt tipi için sorgu yapıldığı.
ANSWER SECTION: Sorguya verilen yanıt(lar). İlgilendiğimiz ana kısım burasıdır.
AUTHORITY SECTION: (Bu örnekte yok) Alan adı için yetkili nameserver'ları gösterir.
ADDITIONAL SECTION: (Bu örnekte OPT PSEUDOSECTION var) Yetkili sunucuların IP adresleri gibi ek bilgileri içerebilir.
İstatistikler: Sorgu süresi, kullanılan sunucu, yanıt boyutu gibi bilgiler.
Sadece Yanıtı Görme (+short):
Eğer sadece sorgunun yanıtını (örneğin IP adresini) görmek isterseniz, +short seçeneğini kullanabilirsiniz:
Sorgulanabilecek Kayıt Tipleri
dig ile DNS kaydı sorgularken parametre belirtmezsek, doğrudan A kaydı sorgulanır. Örneğin MX kaydı sorgulamak isteseydik, bunu özellikle belirtmemiz gerekecekti.
Yukarıdaki örnekten -t mx ile MX kaydını tanımlamış oluyoruz. Kullanım kolaylığı bakımından, -t parametresini belirtmenize gerek yoktur. Kısacası doğrudan dig mx veritech.net komutu yukarıdakiyle aynı sonucu verecektir.
Ayrıca, DNS kayıtları sorgularken belirtilen kayıt tipleri, büyük/küçük karakter duyarlı değildir.
Sorguladımız alanadı hakkındaki bütün kayıtlara erişmek isteseydik, tip olarak ANY tanımlayabilirdik.
Sorgulanacak Sunucuyu Tanımlamak
Yukarıdaki sonuçlara bakıldığında ;; SERVER: 127.0.1.1#53(127.0.1.1) şeklinde bir satır görülebilir. Bu satır, sorgulanan sonuçların hangi sunucudan geldiği bilgisini paylaşmaktadır.
NOT: Farkındaysanız buradaki adres 127.0.0.1 değil, 127.0.1.1 şeklindedir. Bu, bazı Debian türevi dağtımlardaki programların buglarını gidermek için getirilmiş bir çözümdür. Bu bug hakkında detaylı bilgi için Debian Bug Reports içindeki #316099 numaralı loga bakılabilir.
dig programına özellikle belirtmediğimiz takdir de, /etc/resolv.conf dosyasında tanımlı nameserver'ları sırayla deneyecektir. Ancak alanadı problemlerini rahat tespit etmek için programa sorguları özellikle tanımladığımız DNS sunucusuna göndermesini söyleyebiliriz.
Aşağıdaki sorgu, veritech.net kayıtlarını 8.8.8.8 üzerindeki Google DNS'e sormaktadır.
Artık sonuçlardaki SERVER ifadesinin değiştiğini görebilirsiniz.
DNS Yolunu Takip Etmek
Bir alanadının çözümlenmesi için hangi yollardan geçtiği, nerede problem oluştuğunu veya oluşabileceğini tespit etmek için faydalı olabilir. Örneğin veriteknik.com.tr adresinin DNS çözümlemesinde nasıl bir yol izlendiğini takip etmek için +trace parametresini kullanabiliriz.
Yukarıdaki çıktıyı inceleyecek olursak:
Önce dig programı, kendi sistemimizde tanımlı kök sunucuları öğreniyor. Bu sunuculara veriteknik.com.tr adresine nasıl gidileceğini soruyor. Kök sunucuların adreslerini kendi bilgisayarımızdaki veritabanından öğrendik. Kök sunucular bize bu bilginin nic.tr'de olduğunu söyledi çünkü .tr uzantılı alanadlarının nic.tr tarafından yönetildiği biliniyor. Sonuçta ilgili IP adreslerini veritabanından verdi.
h.root-servers.net kök sunucusundan aldığımız bilgiye göre nic.tr'nin 5 tane sunucusu var. Bu sunuculara veriteknik.com.tr adresinin nerede bulunduğunu sorduk. İçlerinden biri bize ns1.rackdc.com ve ns2.rackdc.com adreslerine sormamız gerektiğini belirtti.
ns4.nic.tr sunucusundan aldığımız bilgiye göre, veriteknik.com.tr adresi rackdc ns sunucularındaydı. Bu sunuculardan ns1.rackdc.com ise bize veriteknik.com.tr A kaydının 94.103.32.80 adresinde bulunduğunu belirtti.
Yukarıdaki çıktı bir hiyerarşi içerisinde olmaktadır. Eğer zincirin bir noktası kırılırsa, diğer noktalar da kimi zaman uzun vadede, kimi zaman kısa vadede zarar görebilir. Örneğin veriteknik.com.tr adresine daha önce hiç girmemiş olsaydık ve sunucularımız, ağımız kendisinin IP adresini bilmiyor olsaydı, ona ulaşmak için izleyeceğimiz yolu yukarıdaki gibi kök sunuculara sormamız gerekecekti. Kök sunucular hiçbir zaman doğrudan üzerinde veriteknik.com.tr adresini bulundurmaz. Bu durum tahmin edeceğiniz gibi son derece verimsiz olurdu, bu yüzden bir DNS hiyerarşisi bulunmaktadır. Bu hiyerarşi yüzünden alanadınızın DNS adreslerini değiştirdiğinizde, genellikle bu bilginin diğer DNS sunucularına yayılmasının 24 saat süreceği belirtilir. Bu yayılma sırasında spesifik olarak bir sunucunun güncellenip güncellenmediğini sorgulamak için daha önce öğrendiğimiz @ ile soruglama yöntemini kullanabilirsiniz.
Eğer yukarıdaki sorgu hiyerarşisi içerisindeki bir nokta zarar görürse sistem aksar. Bu aksamanın yaşanmaması için birden fazla DNS sunucusu kullanılır. nic.tr'nin 5 DNS sunucusunun bulunmasının sebebi budur. Böylece birisi zarar gördüğünde diğerine sorgu gönderebiliriz. Ancak 14 Aralık 2015 tarihinde yaşanan bir problem bu durumu sekteye uğrattı. ODTÜ yerleşkesindeki nic.tr sunucularına yapılan bir DDoS (Distributed Denial-of-Service) saldırısı nedeniyle .tr uzantılı alanadları çözümlenemedi ve pek çok servise erişim durdu.
.tr uzantılı alanadlarının (Top Level Domain, TLD) yönetiminin hangi IP adreslerinde olduğu ve kurum bilgilerini IANA'nın veritabanından öğrenebilirsiniz: https://www.iana.org/domains/root/db/tr.html
Bütün TLD'lerin listesine ve kimin tarafından yönetildiğini öğrenmek için: https://www.iana.org/domains/root/db
Kök Sunucular ve DNS Hiyerarşisi
+trace çıktısında gördüğümüz gibi, DNS hiyerarşik bir yapıya sahiptir. Sorgular genellikle yerel çözümleyiciden başlar, gerekirse kök sunuculara (.), oradan ilgili üst seviye alan adı (TLD) sunucularına (.tr, .com vb.) ve son olarak alan adının kendi yetkili (authoritative) sunucularına ulaşır.
Kök Sunucular: İnternetin en üst seviyesindeki 13 mantıksal sunucu kümesidir (A'dan M'ye kadar harflendirilmiş). Bu sunucular, TLD sunucularının adreslerini bilir. IP adresleri nadiren değişir ve DNS çözümleyiciler tarafından "hints" dosyaları aracılığıyla bilinir (örn.
/etc/named.root).Anycast: Fiziksel olarak bu 13 kök sunucu, dünya geneline yayılmış yüzlerce sunucudan oluşur. Anycast yönlendirme tekniği sayesinde, bir kök sunucu IP'sine yapılan sorgu, coğrafi olarak en yakın veya ağ açısından en uygun fiziksel sunucuya yönlendirilir. Bu, performansı artırır ve saldırılara karşı dayanıklılığı sağlar. Türkiye'de de farklı kök sunucu operatörlerine ait Anycast sunucuları bulunmaktadır. (http://www.root-servers.org/)
IANA: Kök bölgenin (root zone) ve TLD'lerin yönetimini koordine eden kuruluştur (https://www.iana.org/domains/root/db).
Hostname
IP Adresi
Yönetici Kurum
a.root-servers.net
198.41.0.4, 2001:503:ba3e::2:30
VeriSign, Inc.
b.root-servers.net
192.228.79.201, 2001:500:84::b
University of Southern California (ISI)
c.root-servers.net
192.33.4.12, 2001:500:2::c
Cogent Communications
d.root-servers.net
199.7.91.13, 2001:500:2d::d
University of Maryland
e.root-servers.net
192.203.230.10
NASA (Ames Research Center)
f.root-servers.net
192.5.5.241, 2001:500:2f::f
Internet Systems Consortium, Inc.
g.root-servers.net
192.112.36.4
US Department of Defense (NIC)
h.root-servers.net
198.97.190.53, 2001:500:1::53
US Army (Research Lab)
i.root-servers.net
192.36.148.17, 2001:7fe::53
Netnod
j.root-servers.net
192.58.128.30, 2001:503:c27::2:30
VeriSign, Inc.
k.root-servers.net
193.0.14.129, 2001:7fd::1
RIPE NCC
l.root-servers.net
199.7.83.42, 2001:500:3::42
ICANN
m.root-servers.net
202.12.27.33, 2001:dc3::35
WIDE Project
Yukarıdaki listenin güncel haline https://www.iana.org/domains/root/servers adresinden erişilebilir.
Reverse DNS
Reverse DNS, şu ana kadar gördüğümüz DNS işlemlerinin tersini yapmaktadır. Bildiğiniz üzere DNS sunucular, kendilerine sorulan alanadlarının IP adreslerini cevap olarak döndürürler. Reverse DNS (rDNS) ise bu işlemin tersini yapmaktadır: bir IP adresinin hangi alanadına işaret ettiğini belirtir. Bu işlem DNS seviyesinde olduğu kadar, ISP (Internet Service Provider, İnternet Servis Sağlayıcı) seviyesinde de yapılmalıdır. Böylece gerçekten de bir IP adresinden gelen bilgi doğru alanadına mı işaret ediyor anlaşılabilir. Bu işlem en çok e-posta sunucuları için gerekmektedir, ve doğru rDNS kayıdı yapılmayan e-posta sunucuları pek çok yere e-posta gönderemez.
rDNS kayıtları servis sağlayıcılar üzerinde PTR (Pointer) kaydı olarak tutulur. Bu kayıtları sorgulamak için, dig'in -x parametresi kullanılabilir.
Örneğin, veritech.net adresinin MX kayıdına bakıp hangi eposta sunucusunu kullandığını öğrenelim.
Yukarıdaki sonuçtan, eposta sunucusunun posta.veriportal.com olduğunu öğrendik. Bu sunucunu IP adresini öğrenelim.
Gelen cevaba göre IP adresi 94.103.32.253. Şimdi gerçekten de bu IP adresinin bu alanadına işaret edip etmediğini öğrenelim, böylece bu adresten gelen e-postaların doğru kaynaktan gelip gelmediğini anlamış olacağız.
Yukarıdaki çıktının ANSWER SECTION kısmına bakacak olursak, PTR kaydının posta.veriporta.com olduğunu görüyoruz. Bu kaynağın doğrulandığı anlamına geliyor.
ANSWER SECTION'ın başında yazan 253.32.103.94.in-addr.arpa. ifadesi standart bir rDNS satırı. IP adresinin ters hali ile sonuna .in-addr.arpa eklenmesiyle oluşturulur.
Farklı Port Kullanımı
Nadiren de olsa bazı DNS sunucuları standart 53 portundan değil, farklı porttan servis verebilirler. Bu durumu dig'e belirtmek için kendisine -p parametresiyle portu belirtmek gerekir.
Yukarıdaki komut, yerel ağımızdaki 192.168.19.23 IP adresli DNS sunucusuna 56. porttan bağlanıp veritech.net adresinin A kaydını soracaktır.
Daha Fazla Bilgi
dig programı alanadları için tanımlanmış standartlara uygunluk gösterir. Bu standartlar hakkındaki detaylar RFC 1035'te tanımlanmıştır.
Last updated