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 kayıtlarını göstermektedir. İlgilendiğimiz kısım ÀNSWER SECTION ile başlayan kısımdır. Zaten bu kısımın altındaki satırın başında ; işareti olmadığını görebilirsiniz. Noktalı virgül işaretleri, ilgili satırın bir açıklama satırı olduğunu ifade etmesi bakımından yazılmaktadır.
Cevaptaki diğer bölümler, programın versiyonu hakkında bilgi vermekte, sorgu hakkında bir takım istatistikler paylaşmaktadır.
QUESTION SECTION kısmında sorgunun aslında veritech.net IN A için yapıldığı görülebilir. Bu yüzden cevap olarak veritech.net. 14399 IN A 94.103.32.32 şeklinde gelmiştir cevap. Kısacası A kaydı sorulmuş, cevap olarak da bu bilgi gelmiştir.
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
+trace ile DNS yolunu takip ederken, kök sunuculardan sorgulamaya başladık. Bu sunucular Dünya üzerinde 13 tanedir ve 12 bağımsız organizasyon tarafından yönetilirler. İnternette isim çözümlemenin belkemiği sayılan sunucuların IP adresleri bilinir ve bu adreslere sorgular gönderilir. Bu adreslerin karşılığı kök sunucular haricindeki DNS sunucularda "hint file" adı verilen dosyalarda tutulur. Bu dosyanın güncel haline erişmek için aşağıdaki link izlenebilir:
http://www.internic.net/domain/named.root
DNS yolunu izlerken kök sunucuların isimlerini görmüştük. a.root-servers.net, b.root-servers.net ... gibi isimleri bulunur. Yukarıda linkini verdiğimiz hint dosyası incelenirse, bu sunucuların isimlerinin eskiden farklı olduğu görülebilir. Örneğin e.root-servers.net için "FORMERLY NS.NASA.GOV" ifadesi bulunur. Gerçekten de eskiden kök sunucuların isimleri bulundukları kurumlarla ilişkilendirilmişti ancak sonradan bir isim standardı getirildi. Bugün 13 kök sunucuyu şu kurumlar yönetmektedir.
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.
Kök Sunucu IP Değişikliği
Kök sunucular da zaman zaman IP adreslerini değiştirme ihtiyacı hissederler. Bu tip durumlar uzun süre önce anons edilir ve DNS sunucuların hint dosyalarını güncellemeleri için süre tanınır.
Örneğin d-root sunucusu, yani University of Maryland tarafından yönetilen sunucu, 3 Ocak 2013'te IPv4 adresini değiştireceğini, ancak IPv6 adresinin değişmeyeceğini duyurmuştur. Bu duyuruda, geçişten sonra eski IPv4 adresinin 6 ay daha kullanılacağını, ancak sonunda terk edileceğini de belirtmiştir. Dolayısıyla DNS yöneticilerine hint dosyalarını en kısa sürede güncellemelerini tavsiye etmiştir. Duyuruya şuradan erişebilirsiniz: http://d.root-servers.org/renumber.html
Kök Sunucularda IPv6 Desteği
Yukarıdaki listeye baktığınızda, kitabın yazıldığı Aralık 2015 tarihi itibariyle 2 kök sunucunun (e-root ve g-root) IPv6 desteği vermediği görülebilir. Kök sunucularda IPv6 desteği 29 Ocak 2008 tarihinde IANA tarafından duyurulmuştur ve 6 tane sunucu ile başlamıştır (a, f, h, j, k, m). Daha sonra diğer sunucular da IPv6 desteği vermiştir. Duyuruya ve ilgii rapora şuradan erişebilirsiniz: http://www.iana.org/reports/2008/root-aaaa-announcement.html
Kök sunucuların IPv6 desteği vermesi demek, sunucuların IPv6 adresinin olması, dolayısıyla doğrudan IPv6 ile sorgulanabilmeleri demektir. Bu gelişmeden önce kök sunuculara IPv4 ile sorgu gönderip, IPv6 adres bilgileri edinilebiliyordu. Ama bu durum sorguyu gönderen tarafın hem IPv4 hem de IPv6 protokollerini desteklemesini gerektiriyordu. IPv6 desteği ile bu zorunluluk ortadan kalktı. Tabii kök sunucuların yönlendirdiği DNS sunucular IPv6 desteklemediği sürece bir anlamı kalmayacaktır.
Kök Sunuculara Yapılan Saldırılar
Daha önce nic.tr'ye yapılan saldırının Türkiye için .tr uzantılı alanadlarını etkilediğini belirtmiştik. Benzer şekilde kök sunuculara da saldırılar yapılmakta. Bunların bazıları 2002, 2007, 2015 tarihlerinde yapıldı ve büyük çoğunluğu internet alt yapısını etkileyemedi. 2007'deki saldırı kök sunucularda ciddi sayılabilecek trafiğe neden oldu ve ICANN saldırılar hakkında bir rapor yayımladı: https://www.icann.org/en/system/files/files/factsheet-dns-attack-08mar07-en.pdf
Kök Sunucuların Konumları
Kök sunucular 13 tane olsa da, aslında 13 fiziksel sunucu olarak düşünmemek gerekir. İlk başta 13 fiziksel sunucu bulunuyordu ve tamamı ABD içindeydi ancak zamanla internet kullanımının yaygınlaşması ve talebin dağıtık biçimde karşılanması gerekliliği, sunucuları yaymayı gerektirdi. Bugün 13 IP adresi farklı fiziksel sunucular üzerinde yayın yapmaktadır. Kısacası kök sunucular 12 organizasyon tarafından Dünya üzerinde bir çok ülkede yönetilmektedir. Örneğin VeriSign'ın yönettiği kök sunucular toplamda 70'e yakın sayıdadır. Tamamı aynı IP adresine sahiptir, böylece bulunduğunuz noktadan bu IP adresine erişmeye çalıştığınızda size en yakındaki sunucuya yönlenirsiniz. Eğer bu sunucu cevap vermezse en yakındaki diğer sunucuya yönlenirsiniz. Bu yöntem bir ağ için "routing" metodudur ve anycast olarak adlandırılır. Teknolojinin detayı konumuzun dışında olduğu için ilgilenmeyeceğiz ancak Anycast servisleri RFC4786'da tanımlanmıştır: https://tools.ietf.org/html/rfc4786
Aralık 2015 itibariyle kök sunucular 97 farklı ülkeye yayılmıştır. Türkiye'de de 4 tanesi bulunmaktadır. 2'si İstanbul'da D-ROOT ve L-ROOT anycast'leri olarak çalışmakta, 2'si ise Ankara'da I-ROOT ve L-ROOT anycast'leri olarak çalışmaktadır.
Kök sunucuların konumlarını interaktif bir haritayla http://www.root-servers.org/ adresinden inceleyebilirsiniz, veya trafik detaylarını http://pch.net/root-servers adresinden takip edebilirsiniz.
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