Switch DNS Server Ayarı: Name Server ve Alan Adı

Switch DNS server ayarı, switch’e adları adrese çevirecek sunucuyu ve kısa adların hangi alan adıyla tamamlanacağını söyleyen iki satırdır: ip name-server ve ip domain-name. Bu rehberde lab switch’ime iç DNS sunucusunu tanıtıyorum. İki satırın söylemediği üç şeyi de ölçüyorum. DNS tanımlı değilken switch’in adı kime sorduğunu, yanlış yazılmış bir adın nereye gittiğini ve kapalı bir DNS sunucusunun her aramaya kaç saniye eklediğini paketiyle gösteriyorum.

Bir süpermarket şubesi tedarikçilerini adıyla bilir, numarasını ezberlemez. Numarayı genel müdürlüğün tedarikçi rehberinden öğrenir ve bir süre not defterinde tutar. Bu yazıda switch şubedir, DNS sunucusu genel müdürlüğün tedarikçi rehberidir, switch’in ad önbelleği de görevlinin not defteridir.

Bu yazı, switch yapılandırma rehberimizdeki kontrol listesinin 4. adımıdır ve Kurumsal Network Kurulumu hizmetimizin switch tarafına aittir. Aynı işi müşterilerimizin ağında nasıl yürüttüğümüzü switch kurulumu ve VLAN yapılandırma hizmeti sayfamızda anlattık.

DNS’in ne olduğunu ve bir sorgunun hangi duraklardan geçtiğini DNS nedir yazımızda anlattık. Bu rehber o zincirin en ucundaki soran cihaza, switch’e odaklanıyor.

DNS Tanımlı Olmayan Switch Adı Nasıl Çözdü?

İşe switch’in bugünkü hâline bakarak başlıyorum. Sahada verilen standart cevap şudur: switch’e DNS sunucusu yazılmamışsa switch ad çözemez.

Lab switch’imde durum buydu:

gmsw01#show hosts

Host name: gmsw01
Name/address lookup is enabled
Name servers (Preference order): Name servers are not configured
...
cache: TTL (Hours)

Host                     Total   Elapsed Type      Addresses
------------------------ ------- ------- --------- -------------------------
No hostname is mapped to an IP address

Name servers are not configured satırı DNS sunucusu olmadığını söylüyor. Aynı dakikada switch’ten domain controller’ın tam adına ping attım:

gmsw01#ping dc01.ad.sistemkusu.com
 Pinging dc01.ad.sistemkusu.com with 0 bytes of data:

Reply From 192.168.1.10: icmp_seq = 0. time= 4925 usec.
Reply From 192.168.1.10: icmp_seq = 1. time= 6948 usec.
...

Ad çözüldü ve cevap doğru adresten geldi. Bu çıktıdaki asıl öğretici satır ping’in kendisi değil, ilk çıktıdaki Name/address lookup is enabled satırıdır. Switch’in ad araması fabrika ayarında açıktı ve sorulacak bir sunucu olmadığında da susmadı. Soruyu kime sorduğunu kurulumdan sonra paketle gösteriyorum; kısa cevap, bütün ağa sorduğudur.

Şube benzetmesinde bu, rehberi olmayan bir görevlinin mağazanın ortasında “sütçünün numarasını bilen var mı?” diye seslenmesidir. İlk cevap verene inanır. DNS ayarı işte bu seslenmeyi, tek bir rehbere yöneltilmiş bir soruya çevirir.

Switch’e DNS Tanımlamanın Faydası: Neden Atlanır?

Seslenmenin kapanması, switch’e DNS tanımlamanın kazandırdığı dört şeyden yalnız biridir. Dördü de aynı yere çıkar: switch’in yönetim tarafındaki adresler, yapılandırmada ve akılda tutulması kolay adlara dönüşür.

1. Sunucu taşındığında switch’lere dokunulmaz. Saat, log ya da kimlik doğrulama sunucusu adla yazılmışsa, sunucunun adresi değiştiğinde DNS’teki tek kayıt güncellenir. Lab switch’im adı yapılandırmada tuttu ve kayıt değişince yeni adrese gitti; bunu aşağıda ölçtüm. Adresleri IP ile yazılmış bir ağda aynı taşıma, her switch’e tek tek girmek demektir.
2. Soru tek bir sunucuya gider. DNS tanımlı switch adı bütün ağa değil, yazdığınız sunucuya sorar. Yönetim ağındaki diğer cihazlar soruyu artık duymaz. Bu, DNS spoofing’in en kolay yolunu kapatır ama spoofing’i engellemez; nedenini paket bölümünde ölçtüm.
3. Yapılandırma kendini anlatır. sntp server "ntp01.ad.sistemkusu.com" satırını okuyan kişi sunucunun ne olduğunu bilir. sntp server 192.168.1.15 satırını okuyan kişinin ise adresin kime ait olduğunu ayrıca bulması gerekir.
4. Teşhis switch’in içinden adla yapılır. Switch’te ping dc01 yazmak, adres listesine bakmadan sunucuya ulaşılıp ulaşılmadığını gösterir.

Atlanmasının sebebi anlaşılırdır. Switch trafiği adlara bakmadan taşır, DNS eksikliği hiçbir port ışığını söndürmez ve hiçbir kullanıcı şikâyetine dönüşmez. Eksiklik ancak biri saat ya da log sunucusunu adla yazmaya kalktığında görünür. O güne kadar ad araması açık kaldıysa, switch’e yazılan her ad sessizce bütün ağa sorulur.

Şube benzetmesinde bu, tedarikçileri ezberden numarayla arayan bir şubedir. Rehber masada kapalı durur ve eksikliğini kimse fark etmez, ta ki bir tedarikçinin numarası değişene kadar.

Switch DNS Ayarından Önce: Sunucu, Yol ve Alan Adı

Switch’e bir DNS sunucusu yazmadan önce üç şeyi kontrol ediyorum.

Birincisi, hangi DNS sunucusu? Switch’in adla bulacağı sunucular (saat, log, kimlik doğrulama) kurum içindedir ve bu adları yalnız iç DNS bilir. Lab’da bu iş dc01 adlı domain controller’da duruyor ve alanı ad.sistemkusu.com. Domain controller internetteki adları da kendi DNS forwarder’ı üzerinden çözer; DNS forwarder’ın kurulumunu Active Directory DNS yapılandırması rehberimizde anlattık.

İkincisi, switch sunucuya ulaşıyor mu? Switch’in yönetim adresi yönetim ağında, DNS sunucusu sunucu ağında durur ve aradaki yolu ağ geçidi açar. Yönetim ağının neden ayrı tutulduğunu management VLAN yazımızda anlattık. Lab’da bu iki ağ arasında yönlendirici yok; ölçüm süresince bir Linux sunucusunu geçici yönlendirici yaptım. Sonra switch’ten DNS sunucusuna ping attım:

gmsw01#ping 192.168.1.10
 Pinging 192.168.1.10 with 0 bytes of data:

Reply From 192.168.1.10: icmp_seq = 0. time= 4277 usec.
Reply From 192.168.1.10: icmp_seq = 1. time= 5834 usec.
Reply From 192.168.1.10: icmp_seq = 2. time= 4711 usec.
Reply From 192.168.1.10: icmp_seq = 3. time= 4135 usec.
...
4 packets transmitted, 4 packets received, 0% packet loss

Arada bir güvenlik duvarı varsa DNS’in kullandığı UDP 53 numaralı portun switch’ten sunucuya açık olması gerekir. Ping’in geçmesi bu portun açık olduğunu göstermez.

Üçüncüsü, hangi alan adı? Kısa bir ad (dc01) yazdığınızda switch onu bu alan adıyla tamamlar. Domain kullanan bir kurumda doğru değer domain’in DNS adıdır; lab’da ad.sistemkusu.com.

Switch’e DNS Sunucusu ve Alan Adı Tanımlamak

Sunucu hazır ve switch ona ulaşıyor. Şimdi switch’e sunucunun adresini ve alan adını yazıyorum.

Ayar iki satırdır:

configure
ip name-server 192.168.1.10
ip domain-name ad.sistemkusu.com
exit

Birinci satır DNS sunucusunun adresini yazar. İkincisi kısa adların tamamlanacağı alan adını tanımlar. İkisi de Enter’a basıldığı anda uygulanır. Ad aramasını açan üçüncü bir satır (ip domain-lookup) gerekmedi, çünkü lab switch’imde bu ayar fabrikadan açık geliyordu.

İkinci bir DNS sunucunuz varsa aynı satıra, tercih sırasıyla yazın: ip name-server 192.168.1.10 192.168.1.11. Switch listeyi soldan sağa dener. Sıranın neden önemli olduğunu aşağıda ilk sunucu kapalıyken ölçtüm.

Şube benzetmesinde birinci satır görevliye genel müdürlüğün rehber hattını göstermektir. İkincisi, “sütçü” dendiğinde rehberin hangi bölge listesine bakılacağını söylemektir.

Switch DNS Ayarını Doğrulamak: show hosts ve Adla Ping

Ayar girildi. Doğrulamanın ilk durağı yine show hosts komutudur:

gmsw01#show hosts

Host name: gmsw01
Default domain: ad.sistemkusu.com sistemkusu.com
Name/address lookup is enabled
Name servers (Preference order): 192.168.1.10
...

Bu çıktıda üç satıra bakılır:

1. Name servers satırında yazdığınız adres görünmelidir. Name servers are not configured yazıyorsa satır girilmemiştir.
2. Name/address lookup is enabled ad aramasının açık olduğunu gösterir. disabled görünüyorsa switch hiçbir adı çözmez.
3. Default domain satırında yazdığınız alan adı görünür. Lab switch’im buraya benim yazmadığım ikinci bir alan da ekledi: sistemkusu.com. Bu ekin ne yaptığını arama listesi bölümünde ölçtüm, çünkü doğrulamanın en sessiz tuzağı oradadır.

Sonra kısa bir adla ping atıyorum. web01 o anda kapalı bir sunucuydu, bu yüzden ping’e cevap gelmedi. Önbellek ise adın çözüldüğünü gösteriyor:

gmsw01#ping web01
 Pinging web01 with 0 bytes of data:
...
4 packets transmitted, 0 packets received, 100% packet loss

gmsw01#show hosts
...
Host                     Total   Elapsed Type      Addresses
------------------------ ------- ------- --------- -------------------------
web01.ad.sistemkusu.co 1200    4       IP        192.168.1.40
m

Switch web01 adını alan adıyla tamamladı (web01.ad.sistemkusu.com) ve 192.168.1.40 adresine çözdü. Adın çözülmesi ile sunucunun cevap vermesi ayrı iki sorudur; bu çıktı birincisini doğruluyor. Aynı ping, alan adı tanımlanmadan önce hemen DNS Lookup failed ile dönmüştü.

Önbellek tablosu hakkında iki not:

• Başlıktaki TTL (Hours) yanlış bir birim söylüyor. Değerler saniyedir. DNS sunucusunda TTL’i 1 saat olan glpi kaydı tabloda 3600, 20 dakika olan web01 kaydı 1200 olarak göründü. TTL’in ne olduğunu DNS makalemizin önbellek bölümünde anlattık.
• Önbelleği temizleyen komut clear host * biçimindedir. clear host all yazdığımda switch all sözcüğünü bir ad sandı ve Unable to remove entry hatası verdi. Önbellek temizlenmedi.

Durum beklediğiniz gibi değilse aşağıdaki sık yapılan hatalar listesinden başlayın.

Ayar şu anda çalışan yapılandırmada duruyor. Kalıcı olması için kaydetmeniz gerekir; çalışan ve kalıcı yapılandırmanın farkını yönetilebilir switch ayarları yazımızda anlattık.

Saat Sunucusunu Adla Yazmak: Yapılandırmaya Ad mı Girer?

DNS çalışıyor. Rehberde DNS adımının saatten önce gelmesinin sebebi buydu: saat sunucusunu adla yazabilmek. Switch NTP ayarı rehberimizde sunucuyu IP adresiyle yazmıştım. Şimdi aynı sunucuyu adıyla yazıyorum. Bunun için DNS sunucusuna ntp01 için bir kayıt ekledim ve saat sunucusunda yönetim ağına izin verdim:

configure
no sntp server 192.168.1.15
sntp server ntp01.ad.sistemkusu.com
exit

Asıl soru, switch’in adı yapılandırmaya nasıl kaydettiğidir. Bazı cihazlar adı bir kez çözer ve bulduğu IP’yi yapılandırmaya yazar; o zaman sunucunun adresi değiştiğinde switch eski adreste kalır. Lab switch’im adı olduğu gibi sakladı:

gmsw01#show running-config | include sntp

sntp unicast client enable
sntp server "ntp01.ad.sistemkusu.com"

Bir dakika sonra saat istemcisi sunucudan cevap aldı:

gmsw01#show sntp status
...
Server          Status                 Last response
--------------- ---------------------- --------------------------
ntp01.ad.sistem Success                22:32:01 Sep 24 2026
ilisim.com

Ad yapılandırmada kaldığı için sunucunun adresi değiştiğinde yalnız DNS kaydını güncellemek yeter. Bunun gerçekten işleyip işlemediğini kurulumdan sonraki ölçümde sınadım. Şube benzetmesinde tedarikçinin numarası değişince şubelere tek tek haber verilmez, rehberdeki satır düzeltilir.

Switch DNS Sorgusu Paket Düzeyinde: Yayın mı, Tek Hedef mi?

Kurulum bitti. Bundan sonraki bölümler kurulumun adımı değil. Switch’in sorgularını aynı ağ kesimindeki bir Linux sunucusunda (ntp01) paket yakalayarak ve DNS sunucusunun sorgu kaydını okuyarak ölçtüm. İsterseniz sık yapılan hatalar listesine geçebilirsiniz.

İlk ölçüm yazının başındaki soruya cevap veriyor. DNS sunucusu tanımlı değilken switch ca01 adını şöyle sordu:

$ sudo tcpdump -n -i ens33 -e "host 192.168.10.2 and (udp port 53 or udp port 5353 or udp port 5355 or udp port 137)"
22:22:57.344395 f4:8e:38:1b:18:4d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 84: 192.168.10.2.53 > 255.255.255.255.53: 3+ A? ca01.ad.sercebilisim.com. (42)
22:22:57.344979 00:0c:29:ae:c6:8c > 00:0c:29:a0:71:9a, ethertype IPv4 (0x0800), length 100: 192.168.1.10.53 > 192.168.10.2.53: 3* 1/0/0 A 192.168.1.35 (58)
...

Hedef adres 255.255.255.255, hedef MAC ff:ff:ff:ff:ff:ff. Switch soruyu belirli bir sunucuya değil, yayın alanındaki herkese gönderdi. Lab’da cevabı dc01 verdi ve cevap doğruydu.

Sorun cevabın doğru olup olmadığında değil, kimin verebildiğindedir. Yayın alanındaki her cihaz bu soruyu duyar ve her cihaz cevap verebilir. Switch ilk gelen cevaba inanır ve cevabı önbelleğine yazar. Yayın alanının nerede bittiğini VLAN yazımızda anlattık; yönetim ağı ayrıysa bu soruyu duyanlar yalnız o ağdaki cihazlardır.

DNS sunucusunu tanımladıktan sonra aynı türden bir soru tek bir hedefe gitti:

22:25:37.495699 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 70)
    192.168.10.2.53 > 192.168.1.10.53: [udp sum ok] 6+ A? glpi.ad.sercebilisim.com. (42)
22:25:37.496126 IP (tos 0x0, ttl 128, id 37269, offset 0, flags [none], proto UDP (17), length 86)
    192.168.1.10.53 > 192.168.10.2.53: [udp sum ok] 6* q: A? glpi.ad.sercebilisim.com. 1/0/0 glpi.ad.sercebilisim.com. A 192.168.1.20 (58)

İki yakalamayı yan yana koyunca fark tek satırda görünüyor. Sunucu tanımsızken hedef 255.255.255.255, tanımlıyken 192.168.1.10. Sorunun içeriği aynıdır, değişen yalnız kime sorulduğudur. Şube benzetmesinde görevli artık mağazanın ortasında seslenmiyor, rehber hattını arıyor.

Bir ara durum daha var ve o da yayına gidiyor. Sunucu tanımlı ama alan adı tanımlı değilken kısa bir ad (ping glpi) sorduğumda switch adı hiç göndermedi. Pakette A? ., yani kökün kendisi soruldu ve yine 255.255.255.255’e. dc01 bunu ServFail ile cevapladı, switch de DNS Lookup failed dedi. Alan adı tanımlanmadan kısa ad kullanmak, işe yaramayan bir yayın sorgusu üretir.

DNS sunucusunun sorgu kaydı aynı soruları sunucu tarafından gösteriyor:

25.09.2026 01:22:27 ... UDP Rcv 192.168.10.2    0002   Q [0001   D   NOERROR] A      (4)dc01(2)ad(12)sercebilisim(3)com(0)
25.09.2026 01:24:20 ... UDP Rcv 192.168.10.2    0004   Q [0001   D   NOERROR] A      (0)
25.09.2026 01:24:20 ... UDP Snd 192.168.10.2    0004 R Q [8281   DR SERVFAIL] A      (0)

Birinci satır yayın sorgusunun sunucuya ulaştığı andır, ikisi ve üçü kök sorusu ile SERVFAIL cevabıdır. Kayıttaki saat sunucunun yerel saatidir (UTC+3); paket yakalamadaki saat UTC’dir. Windows DNS sunucusunda bu kaydın nasıl açıldığını shadow AI yazımızın iç DNS bölümünde anlattık. Kayıt her paketi diske yazdığı için canlıda sürekli açık bırakılmaz.

DNS Spoofing: Tanımlı Sunucu En Kolay Yolu Kapatır, Engellemez

Yayına sorulan soruya sahte bir cevap vermek için aynı yayın alanında durmak yetiyordu. Soru herkese gidiyordu ve switch ilk gelen cevaba inanıyordu. DNS sunucusu tanımlanınca bu yol kapanır, ama DNS spoofing’in kendisi kapanmaz.

Bir DNS istemcisi cevabı, sorunun kimlik numarasını taşıyorsa ve sorunun çıktığı porta geliyorsa kabul eder. Soruyu görmeden sahte cevap üretmek isteyen, bu ikisini tahmin etmek zorundadır. Lab switch’imde ikisi de kolay tahmin ediliyordu:

• Kaynak port her sorguda 53’tü. Yakaladığım bütün sorgular 192.168.10.2.53 adresinden çıktı.
• Sorgu kimliği ardışıktı. Yakalamalarda sırasıyla 3, 4, 6, 7, 8, 9, 10, 11 ve sonrası görünüyor.

RFC 5452, sahte cevaba karşı korumayı bu iki alanı tahmin edilemez kılmaya bağlar: rastgele bir kaynak port ve 0 ile 65535 arasından rastgele bir kimlik. Bu kural özyinelemeli DNS sunucuları için yazılmıştır; switch gibi yalnız soru soran bir istemciyi bağlamaz. Mekanizma yine de aynıdır ve lab switch’im bu iki alanın ikisini de tahmin edilebilir bıraktı. Sahte bir cevabı bu switch’e karşı ben denemedim; bu çıkarım paketlerdeki iki alandan geliyor.

Bu yüzden asıl koruma yönetim ağının kendisidir. Aynı ağdaki bir cihaz kendini DNS sunucusu ya da ağ geçidi gibi gösterebilir; bunun nasıl yapıldığını ARP spoofing bölümümüzde anlattık. Yönetim ağına yalnız yönetim cihazlarının girebilmesi management VLAN yazımızın konusudur. Cevabı imzayla doğrulayan DNSSEC ise lab switch’imin yardım çıktısında görünmüyor; bu doğrulama yapılacaksa DNS sunucusunda yapılır ve DNS makalemizde anlattık.

Rehber hattını arayan görevli de karşıdakinin sesini tanımıyorsa, hatta araya giren birine inanabilir. Hattın kendisini korumak, numarayı doğru aramaktan ayrı bir iştir.

DNS Kaydı Değişince Switch Yeni Adrese Gider mi?

Ad yapılandırmada kalıyor. Bunun işe yaraması için switch’in adı yalnız ilk seferde değil, sonra da sorması gerekir. Bunu sınamak için DNS sunucusundaki ntp01 kaydını 192.168.1.16’ya, yani boş bir adrese çevirdim ve switch’in önbelleğini clear host * ile temizledim.

Switch bir sonraki saat yoklamasında adı yeniden sordu, yeni adresi aldı ve saat istemcisinin durumu Request Timed Out’a düştü. Kayıt boş adresi gösterdiği için bu beklenen sonuçtu. Önemli olan switch’in DNS’teki değişikliği takip etmesidir. Yakalamada her yoklamada, yaklaşık dakikada bir, yeni bir soru görünüyor; switch adresi yapılandırmaya gömmüyor.

İki sınırı var:

1. Önbellek değişikliği geciktirir. Kaydı 192.168.1.15’e geri aldığımda switch’in önbelleği hâlâ 192.168.1.16 gösteriyordu ve kaydın TTL’i (20 dakika) dolana kadar da öyle kalacaktı. Sunucunun adresini değiştirmeden önce kaydın TTL’ini düşürmek bu gecikmeyi kısaltır.
2. Switch önce IPv6 adresini soruyor. Her yoklamada önce AAAA, sonra A sorusu gitti. Kayıtta IPv6 adresi olmadığı için AAAA boş döndü ve switch IPv4 adresini kullandı. A ve AAAA kayıtlarının farkını DNS makalemizde anlattık.

Görevlinin not defterindeki numara da süresi dolana kadar kullanılır. Rehberdeki satır düzeltilse bile şube yeni numarayı, notunu yenilediği gün öğrenir.

Switch DNS Arama Listesi: Yazım Hatası İnternete Çözülüyor

Doğrulamada Default domain satırında benim yazmadığım bir alan görmüştük: sistemkusu.com. Switch yazdığım alan adının üst alanını arama listesine kendiliğinden eklemişti. Bunun ne yaptığını görmek için olmayan bir kısa adla ping attım:

22:27:55.962669 ... 192.168.10.2.53 > 192.168.1.10.53: [udp sum ok] 9+ A? yazim-hatasi01.ad.sercebilisim.com. (52)
22:27:55.968498 ... 192.168.1.10.53 > 192.168.10.2.53: [udp sum ok] 9 NXDomain* q: A? yazim-hatasi01.ad.sistemkusu.com. ...
22:27:56.591874 ... 192.168.10.2.53 > 192.168.1.10.53: [udp sum ok] 9+ A? yazim-hatasi01.sercebilisim.com. (49)
22:27:56.670589 ... 192.168.1.10.53 > 192.168.10.2.53: [udp sum ok] 9 q: A? yazim-hatasi01.sercebilisim.com. 2/0/0 yazim-hatasi01.sercebilisim.com. A 216.150.1.129, yazim-hatasi01.sercebilisim.com. A 216.150.1.1 (81)

Switch önce adı kendi alanında sordu ve NXDomain, yani “böyle bir ad yok” cevabını aldı. Burada durmadı ve adı üst alanda sordu. Bu kez cevap geldi: 216.150.1.129. Bu, web sitemizin adresidir. sistemkusu.com alanında internette her ada cevap veren bir joker kayıt (wildcard) var ve yanlış yazılmış ad ona takıldı.

Tam adı yazmak da korumadı. yazim-hatasi03.ad.sistemkusu.com adını sorduğumda switch adı önce olduğu gibi, sonra iki alanı sonuna ekleyerek sordu. Üçüncü deneme yazim-hatasi03.ad.sistemkusu.com.sistemkusu.com oldu ve yine 216.150.x.x adresine çözüldü. Sonuna nokta koyarak adı kesinleştirmek de mümkün değildi, çünkü switch noktayla biten adı Invalid Host Name diye reddetti.

Listeyi switch’in nasıl kurduğunu da ölçtüm. Alan adını değiştirip show hosts okudum:

Switch iki etiketli alana kadar bütün üst alanları ekliyor, ve .com.tr ile biten bir alanda bu com.tr’nin kendisidir. com.tr kurumun değil, kamunun alanıdır. firma.com.tr kullanan bir kurumda switch’e yanlış yazılan kısa bir ad, com.tr altında o adı almış kim varsa onun adresine çözülebilir.

Bu risk yeni değil. RFC 1535 1993’te tam olarak bu arama davranışını tarif eder ve şu kuralı koyar: örtük arama listesi kullanan çözümleyici, aramasını yerel yönetimin elindeki alanlarla sınırlamak zorundadır. Lab switch’imin yardım çıktısında bu listeyi değiştiren bir komut görünmüyor. Bu yüzden korunma switch’te değil, alışkanlıktadır:

1. Adla yazdığınız her satırdan sonra show hosts okuyun. Önbellekte kurumunuzun adres bloğu dışında bir adres varsa ad yanlış yazılmıştır.
2. Üst alanınızda joker kayıt olup olmadığını bilin. Olmayan bir adı (rastgele-ad.firma.com.tr) sorgulayın; cevap geliyorsa joker kayıt vardır ve switch’in her yazım hatası o adrese gider.
3. En kritik satırlarda adresi IP ile yazmayı tartın. Ad, sunucu taşındığında kolaylık sağlar; IP ise yazım hatasını anında görünür kılar, çünkü yanlış bir IP hiçbir yere çözülmez.

Benzetme burada kopuyor. Rehber hattını arayan görevli, her ada aynı numarayı veren bir santrali birkaç aramada fark eder ve yadırgar. Switch yadırgamaz; gelen her adresi önbelleğine yazar ve kullanır.

İlk DNS Sunucusu Susarsa Switch Ne Kadar Bekler?

Arama listesi yanlış yere gidebiliyor. Sunucu listesi ise yavaşlatabiliyor. İkinci DNS sunucusu bir güvencedir, ama listedeki sırası da bir karardır. Bunu ölçmek için sunucu listesini 192.168.1.11 192.168.1.10 yaptım, yani cevap vermeyen bir adresi birinci sıraya koydum. Kapalı sunucuyu, DNS portu sessizce düşürülen bir adresle taklit ettim:

22:40:56.583296 ... 192.168.10.2.53 > 192.168.1.11.53: [udp sum ok] 37+ A? dc01.ad.sercebilisim.com. (42)
22:40:59.306566 ... 192.168.10.2.53 > 192.168.1.11.53: [udp sum ok] 37+ A? dc01.ad.sercebilisim.com. (42)
22:41:02.308227 ... 192.168.10.2.53 > 192.168.1.11.53: [udp sum ok] 37+ A? dc01.ad.sercebilisim.com. (42)
22:41:05.307145 ... 192.168.10.2.53 > 192.168.1.10.53: [udp sum ok] 37+ A? dc01.ad.sercebilisim.com. (42)
22:41:05.307582 ... 192.168.1.10.53 > 192.168.10.2.53: [udp sum ok] 37* q: A? dc01.ad.sercebilisim.com. 1/0/0 dc01.ad.sercebilisim.com. A 192.168.1.10 (58)

Switch cevap vermeyen sunucuya üç kez, üçer saniye arayla sordu. İkinci sunucuya ancak 8,7 saniye sonra geçti ve cevabı milisaniyenin altında aldı. ping dc01 sonunda çalıştı, ama önbellekte olmayan her ad bu bekleyişi yeniden öder.

Buradan çıkan kural, listenin sırasının bir tercih sırası olduğudur. En güvenilir sunucu birinci sıraya yazılır. Bir DNS sunucusu bakıma alınacaksa önce switch’lerin listesinde sonraya çekilir. Rehber hattının ilk numarası meşgul çalıyorsa görevli üç kez dener, sonra ikinci numarayı arar; her tedarikçi için bu dokuz saniyeyi yeniden kaybeder.

DNS Kullanmayacaksanız: no ip domain-lookup

Buraya kadar DNS’i kullanan switch’i anlattım. Bütün sunucuları IP adresiyle yazacaksanız ad aramasına ihtiyacınız yoktur. Ama yazının başında gördüğümüz gibi DNS sunucusu yazmamak ad aramasını kapatmaz; switch soruyu yayına gönderir. Aramayı kapatan satır ayrıdır:

configure
no ip domain-lookup
exit

Kapattıktan sonra aynı adı sordum ve paket yakalamayı açık tuttum:

gmsw01#show hosts

Host name: gmsw01
Name/address lookup is disabled
...
gmsw01#ping glpi.ad.sistemkusu.com

 DNS Lookup failed

Switch hemen DNS Lookup failed dedi ve yakalamada tek bir paket görünmedi. Karşılaştırma net. Arama açıkken ve sunucu yokken soru bütün ağa gider, arama kapalıyken hiçbir yere gitmez. Rehberin 4. adımını atlıyorsanız bu satırı yine de yazın.

Switch DNS Ayarında Sık Yapılan Hatalar

Doğrulama tutmadıysa ya da switch bir adı beklemediğiniz bir adrese çözdüyse önce aşağıdaki hatalara bakın:

• DNS sunucusu yazmamayı ad aramasını kapatmak sanmak. Lab switch’imde arama fabrikadan açıktı ve sunucu yokken soruyu 255.255.255.255’e gönderdi. DNS kullanmıyorsanız no ip domain-lookup yazın.
• Alan adını tanımlamadan kısa ad kullanmak. Switch kısa adı tamamlayamadı, yayına kök sorusu gönderdi ve DNS Lookup failed dedi.
• Arama listesini kontrol etmemek. show hosts çıktısındaki Default domain satırı switch’in hangi alanlarda arayacağını gösterir. Lab’da buraya kendiliğinden bir üst alan, .com.tr ile biten alanda com.tr eklendi.
• Adla yazılan satırın çözüldüğü adresi okumamak. Yanlış yazılmış bir ad hata vermeden internetteki bir adrese çözülebilir. Her adlı satırdan sonra önbellekteki adresin kurumunuzun bloğunda olduğunu doğrulayın.
• Cevap vermeyen sunucuyu birinci sıraya yazmak. Lab’da her önbellek dışı ad 8,7 saniye bekledi.
• UDP 53’ü kapalı bırakmak. Switch ile DNS sunucusu arasında bir güvenlik duvarı varsa DNS portunu o duvarda açmak gerekir. Ping’in geçmesi bu portun açık olduğunu göstermez.
• Önbelleği clear host all ile temizlemeye çalışmak. Lab switch’imde doğru biçim clear host * oldu; all bir ad sanıldı.
• Kaydetmemek. Ayar yalnız çalışan yapılandırmada kalırsa switch ilk yeniden başlatmada DNS’siz açılır ve ad araması yeniden yayına döner.

Sonuç: DNS Tanımlanmayan Switch Susmaz, Bağırır

Switch’e DNS sunucusu ve alan adı tanımlamak iki satırlık bir iştir. Asıl ders, bu iki satır yazılmadığında da switch’in ad aradığıdır. Lab switch’im sunucu yokken soruyu bütün ağa sordu ve gelen ilk cevaba inandı. Adla yazılan satırlar da dikkat ister. Switch adı yapılandırmada tuttu ve DNS’teki değişikliği takip etti, ama yanlış yazılmış bir adı üst alanlarda arayıp internetteki bir adrese çözdü.

Rehberi olmayan görevli mağazanın ortasında seslenir. Rehberi olan görevli doğru hattı arar, ama tedarikçinin adını yine doğru söylemek zorundadır.

Sıradaki adım switch’in saatini bir NTP sunucusuna bağlamaktır; bunu switch NTP ayarı rehberimizde anlattık, sıralamanın tamamı switch yapılandırma rehberimizde duruyor. DNS ayarının bir kurumsal ağ projesinde nereye oturduğunu Kurumsal Network Kurulumu sayfamızda anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn