FortiGate Firewall DNS Ayarı: Ad Çözümleme ve DNS Sunucusu

FortiGate Firewall DNS ayarı, cihazın adları hangi sunucuya soracağını belirler ve Network → DNS ekranında yapılır. Microsoft’un ve NIST’in tarif ettiği düzende FortiGate adları kurumun iki iç DNS sunucusuna sorar; internetteki adları iç sunucu kendisi çözer. Bu yazı FortiGate Firewall yapılandırma rehberimizin 5. adımıdır.

Lab’daki en çarpıcı ölçüm ikincil sunucudan geldi: ikincil alanda bir Public DNS (internetteki herkese açık DNS sunucusu) varken iç DNS’in cevabı 100 milisaniye yavaşlayınca aynı iç adın 20 çözümünden 19’u yanlış bir adrese gitti.

Örnekteki sınır kapısında görevliye her gün yer sorulur. Küçük bir sokağın yerini duvardaki ayrıntılı bölge haritası gösterir; ülkenin yol atlası büyüktür, ama o sokağı hiç göstermez. Doğru cevap, soruyu doğru kaynağa sormaktan geçer. FortiGate’te bölge haritası kurumun iç DNS sunucusu, atlas da Public DNS’tir.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde bir FortiGate’i devraldığımızda baktığımız ilk ayarlardan birini anlatır: cihaz iç adları kime soruyor?

FortiGate’in DNS’e Neden İhtiyacı Var? Fabrika Ayarında FortiGuard

FortiGate yalnız trafiği geçirmez, kendisi de ad çözer. Güncellemeleri ve imza paketlerini FortiGuard sunucularından adla ister, adres nesnelerindeki alan adlarını düzenli aralıkla IP adresine çevirir. Merkezi girişteki LDAP sunucusunu ve ikinci NTP sunucusunu da lab’da adla yazdık (dc01.ad.sistemkusu.com); bu adları da DNS çözer. Fabrika ayarında bütün bu sorular Fortinet’in kendi DNS sunucularına gider. Lab cihazımın fabrika yapılandırması şuydu:

config system dns
    set primary 96.45.45.45
    set secondary 96.45.46.46
    set protocol cleartext
    set timeout 5
    set retry 2
    set dns-cache-limit 5000
    set dns-cache-ttl 1800
    set cache-notfound-responses disable
    set server-select-method least-rtt
    set log disable
end

Bloktaki dört satır yazının geri kalanını belirler:

1. primary ve secondary: FortiGuard’ın iki DNS sunucusu. İnternete çıkamayan bir cihaz ikisine de ulaşamaz ve kurumun iç adlarını ikisi de bilmez.
2. protocol cleartext: sorgular şifresiz, UDP 53 üzerinden gider.
3. timeout 5 ve retry 2: cevap gelmeyen bir sorgu 5 saniye beklenir ve iki kez yeniden denenir.
4. server-select-method least-rtt: iki sunucu arasında o an en hızlı cevap verene sorulur. İkincil sunucu tuzağı bu satırdan çıkıyor.

İnternete çıkışı olmayan lab cihazımda bir adı çözmeye çalıştım (execute ping www.example.com). Cevap 15 saniye sonra geldi: Unable to resolve hostname. Bu süre fabrika ayarının kendisidir: 5 saniyelik zaman aşımı, ilk deneme ve iki tekrarla üç kez dolar.

Örnekteki sınır kapısında bu, görevlinin elinde yalnız uzaktaki bir merkezin adresinin olmasıdır: merkeze ulaşamadığı gün hiçbir yeri gösteremez.

FortiGate’in DNS Ayarı Nasıl Olmalı?

FortiGate adları kurumun iç DNS sunucularına sorar ve iki alana da iç adları bilen sunucular yazılır. İnternetteki adları iç sunucu kendisi çözer. Seçim yöntemi failover olur, ki ikinci sunucu yalnız birinci susunca sorulsun. Kurumda iç DNS varsa FortiGate başkalarına DNS servisi vermez.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. Microsoft, DNS istemci ayarları belgesinde (Şubat 2026) domain’e bağlı bilgisayarların servis sağlayıcının DNS’ine yönlendirilmemesini istiyor; dış adları iç DNS sunucusu kendi DNS forwarder’ıyla çözer. Domain üyesi olmayan sunucular da Active Directory’nin DNS’ini birincil ve ikincil olarak kullanabilir. Aynı belgenin bir notu ikincil sunucu tuzağını açıklıyor: istemciyi öbür sunucuya yalnız cevapsızlık geçirir, yanlış ama yetkili bir cevap geçirmez.
2. NIST, SP 800-81 Rev. 3 güvenli DNS rehberinde (Mart 2026) istemcinin en az iki DNS sunucusu olmasını öneriyor (bölüm 5.1). İç ağdan internete giden DNS, yetkili sunucular dışında firewall kuralıyla kapatılır (bölüm 4.2.2); özyinelemeli sunucu yalnız iç istemcilere cevap verir (bölüm 4.3). Şifreli DNS’i (DNS over TLS, DNS over HTTPS) öneriyor ve uygulanabilirliğin yazılımın desteğine bağlı olduğunu yazıyor (bölüm 4.2.1.1).
3. CISA, TA13-088A uyarısında open resolver’ların (internetten herkesin soru sorabildiği özyinelemeli DNS sunucuları) amplifikasyon saldırılarında araç olduğunu yazıyor; özyineleme yalnız kurumun adres aralığındaki istemcilere yapılır.
4. Fortinet iki ayarın sınırını kendisi tanımlıyor. Cihazın komut yardımına göre least-rtt sunucuyu en kısa gidiş-dönüş süresine, failover yazılış sırasına göre seçer. Yönetim kılavuzuna göre FortiOS 7.0, kendi sorgularını TLS (TCP 853) ya da HTTPS (TCP 443) üzerinden şifreleyebilir.

Lab cihazımın fabrika ayarlarını bu önerilerle yan yana koydum:

Lab’da iç DNS, Active Directory’nin domain controller’ı dc01 (192.168.1.10). Domain controller’da DNS’in nasıl kurulduğunu Active Directory DNS yapılandırması yazımızda, DNS’in bir adı nasıl zincir halinde çözdüğünü DNS nedir yazımızda anlattık.

FortiGate’e Kaç DNS Sunucusu Yazılmalı?

İki: kurumda iki domain controller varsa ikisinin adresi. Biri yeniden başlarken ya da arızalandığında öbürü iç adları çözmeye devam eder.

Kurumda tek iç DNS sunucusu varsa ikinci bir iç sunucu en doğru cevaptır. O kurulana kadar ikincil alana bir Public DNS’in adresi yazılabilir, ama yalnız iki koşulla:

1. Seçim yöntemi failover olur. Fabrika ayarındaki least-rtt ile aşağıdaki ölçümde iç adlar yanlış adrese çözüldü.
2. Bedeli bilinir. İç sunucu sustuğu sürece iç adlar Public DNS’e sorulur ve yanlış cevap alır; o cevap iç sunucu döndükten sonra da önbellekte kalır. Aşağıda ikisini de ölçtüm.

Lab’da tek domain controller var. Bu yüzden lab cihazında ikincil alanda 8.8.8.8 duruyor ve seçim yöntemi failover.

Public DNS İç Adı Neden Yanlış Çözer?

Bir ad iki yerde farklı cevap alabilir. İç DNS kurumun kendi kaydını verir; Public DNS o kaydı hiç görmemiştir ve kendi bildiğini söyler. Lab’da bu fark sandığımdan daha sessiz çıktı:

1. İç DNS’e sorulunca: dc01.ad.sistemkusu.com → 192.168.1.10. Doğru adres.
2. 8.8.8.8’e sorulunca: aynı ad → 216.150.1.129. Bu adres sitemizin barındırıldığı sunucuya ait.

8.8.8.8 “böyle bir ad yok” demedi, çünkü internetteki sistemkusu.com alanında joker karakterli bir kayıt (*) var. Bu kayıt alan altında var olmayan her ada aynı adresleri verir; lab’ın iç alan adı ad.sistemkusu.com da o alanın altında kalıyor.

Alan adınızda böyle bir kayıt yoksa cevap NXDOMAIN, yani “böyle bir ad yok” olur; lab’ın ilk düzeninde 20 çözümün 12’si böyle bitmişti. İki cevap da yanlıştır. FortiGate ikisinden sonra da öbür sunucuya dönmedi; Microsoft bu davranışı Windows’un DNS istemcisi için yazıyor, FortiGate’te aynısını ölçtüm.

Örnekteki sınır kapısında atlas o sokağı bilmez, ama bölge için bir dipnotu vardır: “Bu bölgedeki bütün adresler şehir merkezindeki postanededir.” Atlasa bakan görevli aracı postaneye gönderir ve kendinden emindir.

FortiGate’te İç Ağdan İnternete Giden DNS Nasıl Kapanır?

NIST’in önerisi (bölüm 4.2.2) istemcinin internetteki DNS sunucularına doğrudan sormamasıdır: istemci iç DNS’e sorar, dışarıya yalnız iç DNS sunucusu çıkar. FortiGate’te bunu internet çıkış kuralının servis listesi yapar. Lab’da personel ağının internet kuralı “Ic ag internet cikisi” yalnız web ve ping açıyor, listede DNS yok.

Arayüzde yol Policy & Objects → Firewall Policy, kurala çift tıklanır. Service alanında yalnız gereken servisler durur: HTTP, HTTPS ve PING. Bu alana DNS ya da her şeyi açan ALL yazılmaz.

Aynı kuralın komut satırındaki karşılığı:

config firewall policy
    edit 1
        set name "Ic ag internet cikisi"
        set service "HTTP" "HTTPS" "PING"
    next
end

Personel ağındaki bir makineden internetteki bir DNS sunucusuna sordum (dig @1.1.1.1 example.com). Cevap gelmedi. FortiGate’in trafik logu sorgunun internet portunda örtük retle (policyid=0) düştüğünü yazdı:

date=2026-10-05 time=07:39:07 ... srcip=10.34.30.10 srcport=59337 srcintf="personel" srcintfrole="lan" dstip=1.1.1.1 dstport=53 dstintf="port3" dstintfrole="wan" ... action="deny" policyid=0 policytype="policy" service="DNS" ...

Ayrı bir ret kuralı bu yüzden gerekmiyor: listede olmayan servis, kural listesinin sonundaki örtük retle düşüyor. Logu ayrı bir kural adıyla görmek isteyen kurum, internet kuralının üstüne DNS servisli bir DENY kuralı koyar ve Log Violation Traffic’i açar. İç DNS sunucusunun kendisi ise dışarıya sormak zorunda: onun internet kuralı yalnız onun adresinden ve yalnız DNS servisiyle yazılır. Lab’da iç DNS (dc01) FortiGate’in arkasında durmuyor, bu yüzden o kural lab cihazında yok.

FortiGate’te DNS Sunucusu ve Yerel Alan Adı Ayarı

Ayardan önce üç şey hazır olur:

1. İç DNS sunucularının adresleri: lab’da dc01 (192.168.1.10).
2. FortiGate’ten iç DNS’e giden yol: lab’da yönetim ağından sunucu ağına bir statik rota var. FortiGate soruyu sunucuya bakan arayüzünün adresinden gönderir; lab’da bu, yönetim portunun adresi 192.168.10.1.
3. İç DNS sunucusunun bu adresten gelen soruya izni: iç DNS’te bir erişim listesi varsa FortiGate’in bu adresi listeye eklenir.

Sunucular belli olunca ayar Network → DNS ekranında yapılır:

1. DNS servers: Use FortiGuard Servers yerine Specify.
2. Primary DNS server: birinci iç DNS sunucusunun adresi. Lab’da 192.168.1.10.
3. Secondary DNS server: ikinci iç DNS sunucusunun adresi. Lab’da tek domain controller olduğu için 8.8.8.8; koşulları yukarıda.
4. Local domain name: kurumun iç alan adı, lab’da ad.sistemkusu.com. FortiGate kısa bir adı (web01) bu alan adını ekleyerek (web01.ad.sistemkusu.com) çözer.
5. Apply ile kaydedilir.

Sunucu adreslerinin yanındaki rozet, FortiGate’in o sunucudan son aldığı cevap süresidir. Arayüzde DNS Protocols bölümü de var: TLS (TCP/853) ve HTTPS (TCP/443) FortiGate’in kendi sorgularını şifreler.

Sorgu iç ağda kalıp domain controller’a gidiyorsa şifresiz DNS iç ağın içindedir. Kurumun iç DNS’i yoksa ve FortiGate bir Public DNS’e soruyorsa NIST’in önerdiği şifreli protokol açılır. Lab cihazımda bunu ölçemedim: değerlendirme sürümünün komut satırı protocol için yalnız cleartext seçeneğini sunuyor.

Seçim yöntemi arayüzde yok; CLI’dan verilir. Arayüzden kaydettiğim ayar ve failover satırı CLI’da şöyle görünüyor:

config system dns
    set primary 192.168.1.10
    set secondary 8.8.8.8
    set domain "ad.sistemkusu.com"
    set server-select-method failover
end

FortiGate DNS Ayarını Doğrulamak: Ping ve dnsproxy

En kısa sınama, CLI’da bir adı çözdürmektir. Kısa adla verdiğim execute ping web01 yerel alan adını ekleyerek çözüldü:

PING web01.ad.sistemkusu.com (192.168.1.40): 56 data bytes

Paketin nereden çıktığını ntp01 üzerinden yakaladım. FortiGate soruyu yönetim portunun adresinden (192.168.10.1) gönderdi, domain controller cevabı aynı adrese verdi:

07:42:36.622834 IP 192.168.10.1.2074 > 192.168.1.10.53: 22+ A? dc01.ad.sercebilisim.com. (42)
07:42:36.623407 IP 192.168.1.10.53 > 192.168.10.1.2074: 22* 1/0/0 A 192.168.1.10 (58)

Ayrıntılı durum diagnose test application dnsproxy 3 komutundadır. Komutun çıktısı yalnız etkileşimli bir oturumda ve diagnose debug enable açıkken görünüyor; betikten gönderilen komutta ekran boş kaldı. Lab cihazımda son ayarla çıktı buydu:

DNS servers:
192.168.1.10:53 vrf=0 tz=0 encrypt=none req=14 to=0 res=14 rt=1 ready=1 timer=0 probe=0 failure=0 last_failed=0
8.8.8.8:53 vrf=0 tz=0 encrypt=none req=0 to=0 res=0 rt=0 ready=1 timer=0 probe=0 failure=0 last_failed=0
...
vfid=0 vrf=0 domain=ad.sistemkusu.com
DNS_CACHE: hash-size=2048, ttl=1800, min-ttl=60, max-num=5000

Çıktıda dört şey okunur:

1. req=14 res=14: iç DNS’e giden ve cevaplanan soru sayısı. İkisi eşitse soru kaybolmuyor.
2. req=0 (8.8.8.8 satırı): failover ile ikincil sunucuya tek soru gitmemiş.
3. ready=1: sunucu kullanıma hazır.
4. ttl=1800: önbelleğin üst sınırı, 30 dakika. Bir cevap en fazla bu kadar önbellekte kalır; aşağıda bunun bedelini ölçtüm.

FortiGate Kendi Adına Neleri Soruyor?

İç DNS’in istemci listesinde FortiGate’ten gelen, sizin yapmadığınız sorular görülür. İki dakika boyunca FortiGate’in kendi sorularını yakaladım; 30 soru geldi ve adlar üç gruptu:

1. Fortinet servisleri: en sık msgctrl1.fortinet.com (14 soru), ayrıca usupdate.fortiguard.net ve productapi.fortinet.com. Mesaj, güncelleme ve ürün servislerinin adlarıdır.
2. Fabrikadan gelen adres nesneleri: login.microsoft.com, login.microsoftonline.com, login.windows.net. FortiGate bunları Policy & Objects → Addresses altında FQDN türünde adres nesnesi olarak getiriyor ve düzenli aralıkla IP adresine çeviriyor.
3. Sizin adla yazdığınız tanımlar: lab’da LDAP sunucusu ve ikinci NTP sunucusu.

Bu adlar çözüldüğü için sorular seyrek geldi. Lab’ın ilk düzeninde, adlar hiç çözülemezken, FortiGate aynı adları her birkaç saniyede bir yeniden sormuş ve iç sunucuya dakikada 61 soru göndermişti.

İkincil DNS Tuzağı: İç Adlar Yanlış Adrese Gitti

Kurumlarda sık görülen düzen şudur: birincil DNS iç sunucu, ikincil DNS “yedek olsun” diye bir Public DNS. Lab’da bu düzeni fabrika seçim yöntemiyle (least-rtt) kurdum ve aynı iç adı (dc01.ad.sistemkusu.com) her seferinde önbelleği temizleyerek (diagnose test application dnsproxy 1) çözdürdüm. Sonuç üç durumda farklı çıktı:

1. İç DNS hızlıyken: 20 çözümün 20’si doğru. dc01 1 milisaniyede, 8.8.8.8 daha geç cevap verdiği için FortiGate soruları iç sunucuya gönderdi. Tuzak bu durumda görünmez.
2. Ayar uygulandıktan hemen sonra: ayarı üç kez yeniden uygulayıp her seferinde ilk 8 çözümü saydım. 24 çözümün 9’u yanlış adrese gitti; FortiGate sunucuları tanımadığı ilk sorularda ikisine sırayla soruyor.
3. İç DNS yavaşlayınca: ntp01 üzerinde yalnız dc01’in DNS cevaplarını 100 milisaniye geciktirdim; ping hâlâ 0,6 milisaniyeydi. 20 çözümün 19’u 8.8.8.8’e gitti ve yanlış adres aldı.

İkinci durumun ilk turu:

tur1-1 PING dc01.ad.sistemkusu.com (192.168.1.10)
tur1-2 PING dc01.ad.sistemkusu.com (216.150.1.129)
tur1-3 PING dc01.ad.sistemkusu.com (192.168.1.10)
tur1-4 PING dc01.ad.sistemkusu.com (216.150.1.129)
tur1-5 PING dc01.ad.sistemkusu.com (192.168.1.10)
tur1-6 PING dc01.ad.sistemkusu.com (216.150.1.1)

Yanlış adres yalnız bir ping’i bozmaz. FortiGate’te adla yazılan her tanım o adrese gider: LDAP sunucusu, NTP sunucusu ya da bir kuralda kullanılan iç sunucu nesnesi. Yük altında yavaşlayan bir domain controller, FortiGate’in bu tanımlarını sessizce internetteki bir adrese çevirir.

Aynı 100 milisaniyelik gecikmeyle seçim yöntemini değiştirip 20 çözümü tekrarladım:

config system dns
    set server-select-method failover
end

failover ile 20 çözümün 20’si iç sunucudan doğru geldi. Bu yöntemde ikinci sunucu yalnız birinci cevap vermediğinde sorulur; yavaş cevap da cevaptır. Ayarı üç kez yeniden uyguladığımda da ilk 18 çözümün 18’i doğru geldi.

Bu ayarı ezen bir seçenek daha var. WAN arayüzü adresini DHCP ya da PPPoE ile alıyorsa, fabrika ayarında açık gelen Override internal DNS servis sağlayıcının DNS’ini listenin başına koyar. Lab’da bu seçenek açıkken iç sunucuya tek soru gitmedi; ölçümü FortiGate Firewall WAN ayarı yazımızda gösterdim.

Örnekteki sınır kapısında atlas yedek değildir; yerel sokağı sorana yanlış yeri gösterir. Harita ile atlası o an hangisi eline daha yakınsa ona bakarak kullanan görevli, aynı soruya bir gün doğru, bir gün yanlış cevap verir.

Birincil DNS Susarsa: 5 Saniye Bekleme ve Yanlış Cevap

failover düzeninde iç DNS’in tamamen sustuğu durumu da ölçtüm: dc01’e giden DNS’i ntp01 üzerinde düşürdüm.

1. İnternet adı çözüldü, ama beklemeyle. www.example.com ikincil sunucudan geldi; FortiGate ikinciye ancak 5 saniyelik zaman aşımı dolunca gitti ve komutun tamamı 6,4 saniye sürdü. Aynı soruyu switch için switch DNS yazımızda ölçmüştük.
2. İç ad yanlış adrese çözüldü. dc01.ad.sistemkusu.com aynı gecikmeyle 216.150.1.129’a gitti.

Birincil Döndü ama İç Ad Hâlâ Yanlış: Önbellek

İç DNS’i geri açtım ve iç adı birer dakika arayla yeniden çözdürdüm. FortiGate 1,5 dakika sonra bile yanlış adresi kullanıyordu. Önbellek dökümü (diagnose test application dnsproxy 7) nedenini gösterdi:

vfid=0, name=dc01.ad.sistemkusu.com, ttl=1706:1576:1670
	 216.150.1.129 (ttl=1706) 216.150.1.193 (ttl=1706)

İkincil sunucunun verdiği yanlış cevap önbellekte duruyor ve önünde 1.576 saniye, yani yaklaşık 26 dakika daha var. 8.8.8.8 bu kayda 30 dakikalık bir ömür vermişti ve FortiGate’in önbellek sınırı da 30 dakika. İç sunucu dönse de FortiGate bu süre boyunca ona sormaz.

İç DNS’te bir kesintiden sonra sırayla şunlara bakılır:

1. İç adı çözdürün (execute ping ile). Adres iç ağ dışındaysa önbellekte yanlış bir cevap vardır.
2. Önbelleği okuyun (diagnose test application dnsproxy 7). Adın satırındaki adres ve kalan süre görünür.
3. Önbelleği temizleyin (diagnose test application dnsproxy 1). Lab’da temizledikten hemen sonra iç ad yeniden 192.168.1.10’a çözüldü.

Ekrandaki rozet de kesintiyi gecikmeyle gösteriyor. İç DNS sustuktan 20 saniye sonra birincil sunucunun rozeti hâlâ 10 ms diyordu; bir dakika sonra Unreachable oldu:

FortiGate’i İç Ağa DNS Sunucusu Yapmak

Kurumda iç DNS sunucusu varsa bilgisayarlar adları doğrudan ona sorar ve FortiGate’in DNS servisi kapalı kalır. İç DNS yoksa FortiGate iç ağa DNS sunucusu olabilir: bilgisayarlar adları FortiGate’e sorar, FortiGate de kendi DNS ayarındaki sunuculara iletir.

Bu durumda servis yalnız iç ağ arayüzünde açılır, çünkü CISA ve NIST, bir open resolver’ın saldırılarda araç olarak kullanıldığını yazıyor.

Özellik fabrika ayarında gizlidir ve kapalıdır. Servisi açmadan önce yönetim ağındaki bir istemciden FortiGate’e ad sordum ve cevap gelmedi:

;; no servers could be reached

Servis şu adımlarla açılır:

1. System → Feature Visibility altında DNS Database açılır. Network menüsünde DNS Servers görünür.
2. Network → DNS Servers → DNS Service on Interface altında Create New seçilir.
3. Interface: servisin dinleyeceği arayüz. İstemcilerin bulunduğu iç ağ arayüzü seçilir; internete bakan arayüz hiçbir zaman seçilmez.
4. Mode: Recursive önce FortiGate’in kendi DNS kayıtlarına bakar, bulamazsa sistem DNS’ine iletir. Forward to System DNS doğrudan iletir.
5. DNS Filter ve DNS over HTTPS: servise DNS filtresi bağlar ve istemcilere şifreli DNS sunar. İkisi de bu yazının dışında kaldı.

Aynı kaydın komut satırındaki karşılığı kısadır:

config system dns-server
    edit "port1"
    next
end

Servis açılınca aynı istemci iç adı çözdü:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7315
web01.ad.sistemkusu.com. 1200	IN	A	192.168.1.40
;; Query time: 1 msec
;; SERVER: 192.168.10.1#53(192.168.10.1) (UDP)

İki ölçüm servisin sınırını gösteriyor:

1. İstemci adına yapılan soruyu önbelleğe almadı. Ömrü 1.200 saniye olan bir kaydı 5 saniye arayla dört kez sordum; FortiGate dördünü de iç DNS’e iletti. Oysa FortiGate’in kendi soruları önbelleğe giriyor.
2. Servis yalnız seçilen arayüzde çalışıyor. 30 Eylül’deki ilk ölçümde servisi iç ağ portunda açtığımda dış ağdan FortiGate’in dış adresine sorduğum soru cevapsız kaldı.

Bilgisayarların DNS olarak FortiGate’i kullanması için bu adres onlara DHCP ile, DNS sunucusu seçeneğinde verilir; FortiGate’in DHCP formunda bu, DNS server satırındaki Same as Interface IP seçeneğidir ve DHCP sunucusu yazımızda anlattık. Lab’da iç DNS olduğu için ölçümden sonra servisi sildim; silince istemcinin sorusu yine cevapsız kaldı.

Doğrulama: FortiGate Adları Doğru Kaynağa mı Soruyor?

Ayar bittiğinde beş şey kontrol edilir; her biri yukarıda lab’da ölçüldü:

1. İç ad iç adrese çözülüyor. execute ping ile kısa ad ve tam ad denenir; ikisinin adresi de kurumun iç ağındadır.
2. dnsproxy 3 sayaçları: iç DNS satırında req ve res eşit, ikincil satırda failover ile soru yok.
3. Seçim yöntemi failover: show system dns çıktısında set server-select-method failover satırı görünür; görünmüyorsa fabrika değeri least-rtt geçerlidir.
4. İç DNS’te bir kesintiden sonra önbellek: iç ad yanlış adrese çözülüyorsa önbellek temizlenir.
5. DNS servisi: iç DNS varsa show system dns-server boş döner; servis açıksa yalnız iç ağ arayüzü listededir.

Sonuç: FortiGate’in İki DNS Sunucusu da İç Adları Bilmeli

FortiGate’in DNS ayarı kısa bir formdur, ama cihazın güncellemelerinden LDAP sunucusuna kadar her ad ondan geçer. Doğru düzende iki alana da iç DNS sunucuları yazılır, seçim yöntemi failover olur ve kurumda iç DNS varsa FortiGate DNS servisi vermez. Lab’da dört şey beklenenden farklı çıktı:

1. Public DNS iç ada “yok” demedi. Alan adındaki joker karakterli kayıt yüzünden yanlış bir adres verdi.
2. least-rtt hızlı bir iç DNS’te zararsız göründü. Tuzak ancak ayar uygulandıktan hemen sonra (24 çözümün 9’u) ve iç DNS yavaşlayınca (20 çözümün 19’u) ortaya çıktı.
3. Yanlış cevap iç DNS döndükten sonra da kaldı. Önbellekte 26 dakika daha duracaktı; elle temizlemek gerekti.
4. Ekrandaki rozet kesintiyi bir dakika kadar geç gösterdi.

Örnekteki sınır kapısında görevli yerel sokağı her zaman bölge haritasında arar; ülke atlasını ancak harita cevap veremediğinde açar ve harita dönünce atlasın verdiği yanlış adresi defterinden siler. Açılış listesinin kalanı 20 adımlık kontrol listesinde duruyor.

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