Popüler araçlar

Tema

DNS Sağlık Kontrolü

DNS için alan adı doğrulama: kayıt kuruluşundaki yetki devri, doğrudan sorulan her ad sunucusu, SOA, DNSSEC ve e-posta kayıtları. Bu DNS kontrol aracı 40 kontrol yapar, her biri çözümüyle.

Seviyeler Zonemaster ve RFC'lerden · her ad sunucusu TCP üzerinden sorulur · Google Public DNS · RDAP

Bir kök sunucudan .nl kayıt kuruluşuna iner, ardından sidn.nl alan adının her ad sunucusuna doğrudan sorar · 40 kontrol · yaklaşık 3 sn.nl kayıt kuruluşu → her ad sunucusu · 40 kontrol

Deneyin
Örnek23 Eki 2026 tarihinde kaydedildi · sunucumuzdan.nl3 NSDNSSEC imzalı

sidn.nl, DNSSEC dahil çalıştırılan her kontrolü geçiyor

kayıt şirketi: SIDN·2,9 sn

40 geçti

A+: bilgi seviyesinin üstünde hiçbir şey yok. Her ad sunucusu yetkili yanıt verdi ve diğerleriyle uyuştu, zamanlayıcılar Zonemaster'ın aralığında ve Google Public DNS, DNSSEC zincirini kökten itibaren doğruluyor.

Önce sorunlar

Cloudflare'in uç ağındaki sunucumuzdan TCP üzerinden sorulur: kök, .nl kayıt kuruluşu ve her ad sunucusu doğrudan; e-posta kayıtları ve doğrulama için Google Public DNS ve Cloudflare. Kontrol ettiğiniz şeylerin kaydını tutmuyoruz.

DNS kontrolü neleri test eder?

DNS sağlık kontrolü, bir alan adını çözümleyicinin onu bulduğu yoldan izler ve her adımı test eder: kayıt kuruluşundaki yetki devri, doğrudan sorulan her ad sunucusu, bu sunucuların birbiriyle uyuşup uyuşmadığı, SOA kaydı, DNSSEC ve e-posta kayıtları. Bu araç yedi grupta 40 kontrol çalıştırır ve her birini dayandığı kaynağın belirlediği seviyede notlar.

Çoğu DNS sorgulama aracı bir çözümleyiciye sorar ve gelen yanıtı notlar. Bu, arkasındaki sunucuları gizler: çözümleyici hangi ad sunucusu çalışıyorsa ondan yanıt verir, bu yüzden bozuk bir sunucu diğerleri de bozulana kadar görünmez kalır. Burada her ad sunucusu özyineleme kapalıyken TCP üzerinden sorulur, NS kayıtlarının kayıt kuruluşundaki kopyası bölgenin kendi kopyasıyla karşılaştırılır ve DNSSEC zinciri kayıt kuruluşundaki DS'ten bölgedeki imzalara kadar doğrulanır.

Her değişiklikten sonra bir DNS denetimi olarak kullanın: araç, yalnızca sitenin açılıp açılmadığını değil, alan adının dayandığı DNS kayıtlarını kontrol eder (site için Site Erişim Kontrolü sitenin kendisine bakar). Raporu kopyala, sonucu bir destek talebine yapıştırabileceğiniz düz metin bir DNS raporuna dönüştürür.

Kökh.root-servers.net
.com.com kayıt kuruluşuh.gtld-servers.net
8 ad sunucusuRoute 53 + NS1
Bölgegithub.com
  • DNSSEC7 kontrolkökten başlayan güven zinciri: github.com bölgesinin zinciri .com noktasında duruyor (DS yok)
  • Üst bölge ve yetki devri6 kontrolkayıt kuruluşunun yönlendirmesi: 8 ad · 295 bayt · glue gerekmiyor
  • Ad sunucuları14 kontrolher sunucuya doğrudan soruldu: 8 sunucudan 8 tanesi yetkili · TCP üzerinden · EDNS · özyineleme yok
  • Tutarlılık3 kontrolsunucular uyuşuyor mu: 2 SOA seri numarası, her DNS sağlayıcısında bir tane · aynı MX ve SPF
  • SOA4 kontrolzamanlayıcılar Zonemaster'ın alt sınırlarının altında: bildirim
  • CAA1 kontrol7 kayıt · 4 CA'ya izin var
  • E-posta DNS'i5 kontrolMX sağlayıcısı: Microsoft 365 · SPF: 10 sorgudan 10 tanesi · DMARC quarantine
Her kontrol grubunun baktığı yer, github.com'un gerçek yolu üzerinde (23 Ekim 2026): kökten .com kayıt kuruluşu üzerinden bölgenin Route 53 ve NS1'deki ad sunucularına.
github.com için DNS kontrol sonucu: A notu, yedi grupta 40 kontrol ve kökten 8 ad sunucusuna uzanan yolgithub.com için DNS kontrol sonucu: A notu, yedi grupta 40 kontrol ve kökten 8 ad sunucusuna uzanan yolNotYalnızca seviyelerden: kritik yok, hata yok, iki uyarı A eder. Halka puanı gösterir: 100 üzerinden 90.40 kontrol, her biri bir hücreSayfadaki sırayla gruplanır. Kehribar ve mavi hücreler uyarılar ve bildirimlerdir; taralı hücreler çalıştırılamadı.Önce sorunlarDüzeltilecek bir şeyi olan gruplar en üstte açılır; her satırda kaynağı ve çözümü yer alır.YolBir kök sunucu, Verisign'ın işlettiği .com kayıt kuruluşu, ardından doğrudan sorulan her ad sunucusu: yanıtı, seri numarası ve EDNS'i.Güven zinciriYolun yanındaki DNSSEC şeridi: zincirin sağlam olduğu yerde yeşil, durduğu yerde kesik çizgili, koptuğu yerde kırmızı.
github.com için bir DNS sağlık kontrolü. Her bölümün neyi gösterdiğini görmek için bir numara seçin.

Not nasıl hesaplanır?

Harf notu yalnızca başarısız olanların seviyesinden gelir, asla bir puan tablosundan değil: herhangi bir kritik sorun F demektir, iki veya daha fazla hata D, bir hata ya da beş veya daha fazla uyarı C, üç veya dört uyarı B, bir veya iki uyarı (ya da yalnızca bildirimler) A, bilgi seviyesinin üstünde hiçbir şey yoksa A+.

Seviyeler, atıf yapılan kaynağın kendi seviyeleridir: testi Zonemaster tanımlıyorsa Zonemaster'ın varsayılan profili, tanımlamıyorsa RFC'nin MUST veya SHOULD ifadesi. 100 üzerinden puan yalnızca aynı harfteki alan adlarını sıralar (100'den her kritik için 30, her hata için 12, her uyarı için 4, her bildirim için 1 düşülür). Sunucumuzun çalıştıramadığı kontroller hiçbir zaman alan adının aleyhine sayılmaz; kontrollerin dörtte biri veya fazlası çalıştırılamazsa not kısmi olarak belirtilir.

  1. A+100bilgi seviyesinin üstünde hiçbir şey yokINFO “kesinlikle bir sorun olduğunu göstermez”sidn.nl100
  2. A90–991–2 uyarı ya da yalnızca bildirimlerNOTICE “bölge yöneticisinin bilmesi gereken, ancak hiç de sorun olmayabilecek bir durum”github.com90example.com95bücher.de90
  3. B75–893–4 uyarıWARNING “bazı koşullarda sorun olacak, ancak sıradan bir kullanıcının fark etmesi pek olası olmayan bir durum”cloudflare.com87google.com83
  4. C60–741 hata ya da 5 veya daha fazla uyarıERROR “bölgenin işleyişini büyük olasılıkla (ya da kesinlikle) olumsuz etkileyen bir durum”örneklemde yok
  5. D45–592 veya daha fazla hatadnssec-failed.org55
  6. F0–44herhangi bir kritik sorunCRITICAL “makul olarak var olmadığı söylenebilir”bir .com alan adı44

puan = 100 − 30 × kritik − 12 × hata − 4 × uyarı − 1 × bildirim, harfin aralığı içinde tutulur

kısmikontrollerin dörtte biri veya fazlası sunucumuzdan çalıştırılamadı, not bunu belirtir

Not merdiveni; 23 Ekim 2026 tarihinde kontrol ettiğimiz alan adları kayıtlı notlarına göre yerleştirildi. Seviyeler Zonemaster'ın önem derecesi tanımlarından alıntılanmıştır.

Üst ve alt bölgenin NS kayıtları eşleşiyor mu?

Eşleşmeleri gerekir: kayıt kuruluşu (üst bölge) ve bölgenin kendisi (alt bölge) birer NS kümesi yayımlar ve RFC 1912 §2.8 ikisinin aynı tutulmasını ister. Kayıt kuruluşu bölge için yanıt vermeyen bir sunucuyu gösteriyorsa buna lame yetki devri denir: sunucu REFUSED yanıtı verir ya da yetkili (AA) bayrağı olmadan yanıt verir.

Çözümleyiciler bir sonraki sunucuya geçer, yani tek bir lame sunucu zaman kaybettirir; listelenen her sunucu lame ise alan adı çözümlenmez. Zonemaster yalnızca kayıt kuruluşunun listelediği adları hata (EXTRA_NAME_PARENT), yalnızca bölgenin listelediği adları bildirim, hiç çalışan sunucu olmamasını ise kritik olarak değerlendirir.

github.comeşleşiyor

.com kayıt kuruluşu
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Bölge
  • aynı 8 ad

8 sunucudan 8 tanesi AA ile yanıt veriyor

bir .net alan adıuyuşmuyor

.net kayıt kuruluşu
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Bölge
  • ns1.hover.com
  • ns2.hover.com

ortak ad yok · ns2.domaindirect.com sunucusu REFUSED · 2 hata

bir .com alan adılame yetki devri

.com kayıt kuruluşu
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Bölge
  • kimse yanıt vermiyorSERVFAIL

her sunucu REFUSED · çözümleyiciler SERVFAIL yanıtı veriyor · CRITICAL

23 Ekim 2026 tarihinde kaydedilen üç yetki devri. Bozuk olan ikisinin adları gizlendi; ad sunucuları ve yanıtları gerçektir.

Bir alan adının kaç ad sunucusuna ihtiyacı var?

En az iki; önerilen sayı üç. RFC 1034 §4.1 her bölgenin en az iki sunucuda bulunmasını şart koşar, RFC 2182 §5 ise kurum düzeyindeki çoğu bölge için üç önerir. Zonemaster'da tek ad sunucusu bir hatadır; iki sunucu bir bilgi notuyla geçer.

Nerede oldukları kaç tane olduklarından daha önemlidir, bu yüzden ad sunucusu kontrolü ağlarına da bakar. Aynı ağdaki sunucular birlikte çöker: Zonemaster her adres tek bir otonom sistemdeyse uyarı verir (IPV4_ONE_ASN); bu, her adresi birçok noktadan yanıt veren Google, Cloudflare veya Akamai gibi anycast sağlayıcılar için de geçerlidir. Anycast yükü dağıtır; yine de tek bir işletmecidir.

  • google.com4 NS · 1 ağtek ağ
  • github.com8 NS · 2 ağdağıtılmış
  • sidn.nl3 NS · 2 ağdağıtılmış
  • cloudflare.com5 NS · 1 ağtek ağ
  • nasa.gov6 NS · 1 ağtek ağ
  • example.com2 NS · 1 ağtek ağ

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“Kurum düzeyindeki çoğu bölge için, en az biri diğerlerinden iyice uzakta olması gereken üç sunucu sağlanması önerilir.” RFC 2182 §5
Her nokta bir ad sunucusu; adresinin duyurulduğu ağa (AS) göre renklendirildi; 23 Ekim 2026 tarihinde kaydedilen çalıştırmalardan. Tek bir ağ, anycast olsun ya da olmasın, Zonemaster'ın IPV4_ONE_ASN uyarısıdır.

SOA kaydı değerleriniz doğru mu?

Değerleri büyük bir DNS sağlayıcısı belirlediyse neredeyse kesinlikle sorun yoktur, bir kontrol aracı onları işaretlese bile. Refresh, retry ve expire yalnızca bölgeyi bölge aktarımıyla kopyalayan ikincil sunucuları yönlendirir. Minimum, negatif önbellek TTL'idir (RFC 2308): çözümleyicilerin bir adın var olmadığını ne kadar süre hatırlayacağını belirler.

RIPE-203 (1999), refresh 86400, retry 7200, expire 3600000 ve minimum 172800 önerir; sonuncusu RFC 2308'den öncesine aittir. Zonemaster daha düşük alt sınırlar koyar: refresh 14400 ve retry 3600 (bildirim), expire 604800 (tek uyarı), minimum 300 ile 86400 arası (bildirim). Cloudflare, Route 53 ve Azure'un varsayılanları refresh ve retry alt sınırlarının altında kalır; büyük sağlayıcılar arasındaki tek uyarı Google Cloud DNS'in 3 günlük expire değeridir.

refreshZonemaster ≥ 4 sa. · ◆ 1 günretryZonemaster ≥ 1 sa. · ◆ 2 sa.expireZonemaster ≥ 7 gün · ◆ 41,7 günminimumZonemaster 5 dk. – 1 gün · ◆ 2 gün
Cloudflare2,8 sa.40 dk.7 gün30 dk.2 bildirim
Amazon Route 532 sa.15 dk.14 gün1 gün2 bildirim
Google Cloud DNS6 sa.1 sa.3 gün5 dk.1 uyarı
Azure DNS1 sa.5 dk.28 gün5 dk.2 bildirim
GoDaddy8 sa.2 sa.7 gün1 sa.geçti
Namecheap BasicDNS12 sa.1 sa.7 gün1 sa.geçti
google.com (kendi sunucuları)15 dk.15 dk.30 dk.1 dk.1 uyarı · 3 bildirim

Zonemaster'ın alt sınırının altındageçtibildirimuyarıRIPE-203 (1999)

Her sağlayıcının değerleri, bölgelerinin 23 Ekim 2026 tarihinde dig ile sunduğu şekliyle: Cloudflare, Route 53 ve Google Cloud DNS belgeleriyle uyuşuyor; GoDaddy'nin yardım sayfası minimum 600 diyor, örnek bölgeleri ise 3600 sunuyor; Azure DNS ve Namecheap BasicDNS için yayımlanmış varsayılan değer bulamadık, bu yüzden onlarınki bölgelerinin değerleridir. 1 dakikadan 6 haftaya logaritmik ölçek.

DNSSEC kontrolü: DS, DNSKEY ve imzalar

DNSSEC kontrolü güven zincirini izler: kayıt kuruluşundaki DS kaydı bölgedeki bir anahtarın (DNSKEY) özeti olmalı, o anahtar bölgenin anahtar kümesini imzalamalı ve her imza (RRSIG) doğrulanmalı ve geçerlilik süresi içinde olmalıdır. Bu kontrol özeti hesaplar ve her imzayı kendisi doğrular, ardından Google Public DNS'e zincirin doğrulanıp doğrulanmadığını sorar.

Herhangi bir halka koparsa doğrulayan çözümleyiciler SERVFAIL yanıtı verir: alan adı, arkalarındaki herkes için ortadan kaybolur. Kasıtlı olarak bozuk tutulan bir test bölgesi olan dnssec-failed.org, aynı anda iki kopukluk gösterir. Algoritmalar IANA'nın kayıt defterine göre değerlendirilir (RFC 9904): 8, 13 ve 15 önerilir; SHA-1 ile imzalayan 5 ve 7 ise artık kullanılmamalıdır (RFC 9905) ve Zonemaster bunları hata olarak değerlendirir.

cloudflare.comgüvenli

  1. .com üzerinde DS 2371algoritma 13 · SHA-256 · 329968…26F2B9
  2. özet 2371 anahtarıyla eşleşiyor
  3. DNSKEY 2371 · KSKbayraklar 257 · ECDSA P-256 (13)
  4. anahtar kümesini imzalar · 61 gün sürenin 50,8 gün kadarı kaldı
  5. DNSKEY 34505 · ZSKbayraklar 256 · ECDSA P-256 (13)
  6. kayıtları imzalar · SOA: 2 gün sürenin 1 gün kadarı kaldı
  7. Google Public DNSAD bayrağı ayarlı: güvenli

dnssec-failed.orggeçersiz

  1. .org üzerinde DS 42069algoritma 13 · SHA-256
  2. bölgede 42069 anahtarı yok
  3. DNSKEY 50719 · KSKbölgenin gerçek anahtar imzalama anahtarı (KSK)
  4. anahtar kümesindeki imzasının süresi 112 gün önce doldu
  5. DNSKEY 32784 · ZSKSOA'yı imzalar: geçerli, 7 gün sürenin 5,7 gün kadarı kaldı
  6. güvenilir hiçbir şey ona ulaşmıyor
  7. Google Public DNSSERVFAIL; CD ayarlanınca yanıt veriyor: geçersiz

İmzalama algoritmaları (IANA kayıt defteri, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519bunları kullanın
  • MAY14 ECDSAP384SHA384 · 16 ED448izin verilir
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

yukarıdaki iki zincir de 13 ile imzalıyor

23 Ekim 2026 tarihinde kaydedilen iki zincir: cloudflare.com'un zinciri sağlam; dnssec-failed.org'un zinciri DS'te ve ardından süresi dolmuş bir imzada kopuyor.

E-posta DNS'i: MX, SPF ve DMARC

E-posta kontrolleri, alıcı sunucuların okuduğunu okur: MX kayıtları (ya da alan adının e-posta almadığını söyleyen null MX, RFC 7505), RFC 7208'in 10 DNS sorgusu sınırı içinde tek bir SPF kaydı ve bir DMARC politikası (Mayıs 2026'da RFC 7489'un yerini alan RFC 9989).

SPF yalnızca bulunmaz, değerlendirilir: her include izlenir ve sayılır. github.com'un kaydı tam olarak 10 sorgu artı bir boş sorgu (void lookup) gerektirir: geçerli, ama hiç pay kalmamış. Hiç e-posta göndermeyen bir alan adı bunu açıkça söylemelidir; example.com park edilmiş alan adlarına özgü kümeyi yayımlar: null MX, v=spf1 -all ve p=reject. Ayrıntılar için SPF Kayıt Kontrolü ve DMARC Kontrolü daha derine iner.

github.comgönderir ve alır

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 sunucu · takma ad değil
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 DNS sorgusundan 10 tanesi2 boş sorgudan 1 tanesi · geçerli, hiç pay kalmamış
DMARC
p=quarantine; sp=rejectraporlar 1 adrese gider · alt alan adları: reject

example.compark edilmiş alan adı kümesi

MX
0 .null MX: e-posta almaz (RFC 7505)
SPF
v=spf1 -alle-posta göndermez · 0 sorgu
DMARC
p=reject; sp=rejectexample.com olduğunu iddia eden her şey reddedilir
github.com ve example.com, 23 Ekim 2026 tarihinde yayımlandığı şekliyle.

Komut satırından DNS sorgulama ve sağlık kontrolü (dig)

Dört adımda dig ve delv bu kontrolün özünü tekrarlar: yetki devrini kökten izleyin, özyineleme kapalıyken bir ad sunucusuna doğrudan sorun, kayıt kuruluşundaki DS'i bölgenin anahtarlarıyla karşılaştırın ve zinciri doğrulayan bir çözümleyiciye değerlendirtin.

Sunucumuzun gördüğünü görmek için +tcp ekleyin; UDP'yi test etmek için çıkarın, ki Cloudflare ağındaki bir web aracı bunu yapamaz. Yanıtın başlığında aa yetkili bir yanıtı işaret eder; kayıt kuruluşunun listelediği bir sunucudan gelen REFUSED ya da aa bayrağı olmayan bir yanıt, lame yetki devridir.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (kısaltıldı)
com.          172800 IN NS a.gtld-servers.net.   ;; kaynak: h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; kaynak: h.gtld-servers.net · 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; DS yok: imzasız 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Kök, .com için 13 sunucusuna yönlendiriyor
  2. Kayıt kuruluşunun github.com için NS kümesi, 2 gün saklanır
  3. aa: önbellekten değil, yetkili bir yanıt
  4. SOA: seri numarası 1, ardından refresh, retry, expire, minimum
  5. .com üzerinde DS yok: DNSSEC'in doğrulayacağı bir şey yok
  6. delv zinciri kökten itibaren doğruladı
github.com ve cloudflare.com için gerçek yanıtlar (23 Ekim 2026), kısaltılmış. Numaralı işaretler notlarla eşleşir.

DNS kontrol araçları neden farklı sonuç verir?

Çünkü farklı sayılara göre not verirler. Klasik araçlar sağlayıcıların varsayılan değerlerini işaretler: intoDNS, google.com'un 1800 saniyelik expire değerine “NOT OK” der ve github.com'un iki seri numarası için hata verir; oysa bu, iki DNS sağlayıcısı için normaldir. Zonemaster seri numaralarını uyarı olarak değerlendirir ve null MX'i tanır; bizim ilk sürümümüz ikisinde de yanılıyordu.

Ayrıca ağı farklı yerlerden görürler. Zonemaster (AFNIC ve Swedish Internet Foundation) UDP ve TCP üzerinden, IPv4 ve IPv6'da sorar. Bu kontrol Cloudflare'in uç ağında (edge) çalışır: yalnızca TCP üzerinden sorar, IPv6'ya bağlanmaz ve Cloudflare'in kendi adreslerine bağlanamaz; bu yüzden o sunucular 1.1.1.1 üzerinden okunur ve kontrolleri test edilmedi olarak işaretlenir, asla başarısız sayılmaz. Bir intoDNS alternatifi olarak, yalın bir OK ya da NOT OK yerine her seviyenin arkasındaki kaynağı gösterir.

DurumintoDNSZonemasterDNS Robot v1Bu kontrol
github.comiki SOA seri numarası (iki DNS sağlayıcısı)hata“Looks like your nameservers do not agree on the SOA serial.”uyarıMULTIPLE_SOA_SERIALSbaşarısız“Serial mismatch detected: 1656468023 vs 1.”uyarıaçıklandı: her DNS sağlayıcısında bir seri numarası
google.comSOA expire 1.800 snuygun değil“Your SOA EXPIRE number is: 1800. That is NOT OK”uyarıEXPIRE_MINIMUM_VALUE_LOWERbaşarısız“too low (min recommended: 14 days)”uyarıexpire değerinin neyi etkilediğiyle birlikte
example.comnull MX (0 .)hata“0 No A Record (no glue either)”bilgiZ09_VALID_NULL_MXgeçti“Found 1 MX record(s)”geçtinull MX tanındı
cloudflare.comSOA retry 2.400 sn—alıntılanmadıbildirimRETRY_MINIMUM_VALUE_LOWERbaşarısız“too high (max recommended: 15min)”bildirimCloudflare'in varsayılanı
cloudflare.comDNSSEC ile imzalıkontrol edilmediDNSSEC testi yokgeçtiDNSSEC02 · 05 · 08: zincir doğrulandıdikkat“DNSSEC does not appear to be enabled for this domain.”geçtiDS → KSK → RRSIG doğrulandı, Google doğruluyor
Aynı alan adları dört kontrol aracında. intoDNS ve v1 sonuçları 22–23 Ekim 2026 tarihlerindeki sayfalarından ve yanıtlarından alıntılandı; Zonemaster'ın seviyeleri test belirtimlerinden. Son sütun bu kontrol: her bulguyu dayandığı kaynağın belirlediği seviyede notlayan bir intoDNS alternatifi.

DNS sağlık kontrolü: sık sorulan sorular

DNS sağlık kontrolü nedir?

DNS sağlık kontrolü ya da DNS doğrulama, bir alan adının DNS'inin tüm internetin ona ulaşabileceği şekilde kurulup kurulmadığını test eder: kayıt kuruluşundaki yetki devri, her ad sunucusu, SOA kaydı, DNSSEC ve e-posta kayıtları. Her bulgu ne kadar zarar verebileceğine göre bilgiden kritiğe kadar notlanır; bu DNS doğrulayıcı uyguladığı kuralı (bir Zonemaster testi ya da bir RFC bölümü) ve çözümü gösterir.

Alan adı doğrulama, DNS sağlık kontrolüyle aynı şey mi?

Her zaman değil. “Alan adı doğrulama”, bir sertifika yetkilisinin DV sertifikası vermeden önce yaptığı kontrolün ve Google Workspace ya da Microsoft 365'in alan adının sahibi olduğunuzu kanıtlamak için istediği TXT kaydının da adıdır. Bu alan adı doğrulayıcı, alan adının DNS'ini kontrol eder: yetki devri, ad sunucuları, SOA, DNSSEC ve e-posta kayıtları. Sertifika için SSL Sertifika Kontrolü sayfasına bakın.

Lame yetki devri nedir ve nasıl düzeltilir?

Lame yetki devri, kayıt kuruluşunun listelediği ama alan adınız için yanıt vermeyen bir ad sunucusudur: REFUSED der ya da yetkisiz yanıt verir. Uyuşmazlığın olduğu tarafta düzeltin: bölgeyi o DNS sağlayıcısında ekleyin ya da kayıt şirketinizde ad sunucularını bölgeyi barındıran sunucularla değiştirin. Listelenen her sunucu lame ise alan adı hiç çözümlenmez.

DNS sağlayıcım anycast kullanıyor. Tek ağ uyarısı neden?

Çünkü tek bir işletmeci, tek bir arıza noktası demektir. Anycast her adresin birçok noktadan yanıt vermesini sağlar; bu, bir noktanın çökmesine karşı korur, sağlayıcının kendi kesintisine ya da yapılandırmasındaki bir hataya karşı değil. Zonemaster bu nedenle IPV4_ONE_ASN bulgusunu uyarı seviyesinde tutar ve RFC 2182 farklı ağlardaki sunucuları ister. Başka bir ağdaki ikinci bir DNS sağlayıcısı uyarıyı kaldırır.

SOA zamanlayıcılarım işaretlendi. Değiştirmem gerekir mi?

Genellikle hayır. Refresh, retry ve expire yalnızca bölgenizi bölge aktarımıyla kopyalayan ikincil sunucular için önemlidir; Cloudflare ve Route 53 gibi büyük sağlayıcılar bunları bölgeniz için kullanmaz ve varsayılanları uygundur. Zonemaster'ın uyarı dediği tek değer, bir haftanın altındaki expire'dır. Değerleri yalnızca kendi birincil ve ikincil sunucularınızı işletiyorsanız değiştirin.

Bazı kontroller neden “test edilmedi” olarak işaretli?

Çünkü sunucumuz onları çalıştıramadı, bir şey yanlış olduğu için değil. Sunucumuz Cloudflare'in ağında çalışır; bu ağdan Cloudflare'in kendi adreslerine bağlantı açılamaz, ayrıca sunucumuz yalnızca TCP üzerinden sorar ve IPv6'ya bağlanmaz. Bu sunucular bunun yerine Cloudflare'in çözümleyicisi 1.1.1.1 üzerinden okunur. Test edilmeyen kontroller notu asla düşürmez; dörtte biri veya fazlası test edilemezse not kısmi olarak işaretlenir.

Ad sunucularım neden farklı SOA seri numaraları bildiriyor?

Ya ikincil bir sunucu bir değişikliğe henüz yetişmedi ya da alan adınız aralarında bölge aktarımı yapmayan iki DNS sağlayıcısı kullanıyor ve her biri kendi seri numarasını tutuyor. İkinci durum normaldir: github.com'un Route 53 sunucuları 1, NS1 sunucuları ise 1656468023 diyor. Zonemaster her farkı uyarı olarak listeler; biz hangi durumun söz konusu olduğunu açıklarız.

Bu bir DNSSEC kontrol aracı mı ve DNSSEC olmaması notu düşürür mü?

Evet: kayıt kuruluşundaki DS'i bölgenin anahtarlarıyla karşılaştırır, her imzayı doğrular, ardından Google Public DNS'e sorar. İmzasız bir bölge bir Zonemaster uyarısıdır (DS07_NOT_SIGNED), bu yüzden not en fazla A olur. Bozuk bir zincir, hiç olmamasından çok daha kötüdür: doğrulayan çözümleyiciler alan adını reddeder; bu, notu C veya altına düşüren bir hatadır.

DNS kontrolünü ne sıklıkla yapmalıyım?

Ad sunucularında, DNSSEC'te veya e-posta kayıtlarında yapılan her değişiklikten sonra ve yeni bir DNS sağlayıcısına ya da kayıt şirketine geçmeden önce ve sonra. Bunun dışında ayda bir kez yeterlidir: süresi dolmak üzere olan bir imzayı, yanıt vermeyi bırakmış bir ad sunucusunu ya da sizin yapmadığınız bir kayıt kuruluşu değişikliğini yakalar. Her sonucun kendi bağlantısı vardır, böylece çalıştırmaları karşılaştırabilirsiniz.

Kontrol ettiğim alan adlarını saklıyor musunuz?

Hayır. Kontrol, Cloudflare'in uç ağındaki sunucumuzda çalışır ve köke, kayıt kuruluşuna, ad sunucularınıza, Google Public DNS'e ve Cloudflare'in çözümleyicisine sorar; adresinizle birlikte hiçbir şey kaydedilmez. Tamamlanan bir çalıştırma, tekrar veya paylaşılan bir bağlantı hemen yanıt alsın diye 10 dakika tutulur, sonra silinir. Ad sunucularınız her çalıştırmada sunucumuzdan yaklaşık 20 soru alır.

İlgili araçlar