DNS bozulduğunda karşılaştığınız hataların A'dan Z'ye listesi. Burada üç tür kayıt yan yana durur: her DNS yanıtının taşıdığı yanıt kodları (RCODE), modern çözümleyicilerin bir hatayı açıklamak için eklediği Genişletilmiş DNS Hataları (EDE, RFC 8914) ve tarayıcıların, işletim sistemlerinin ve komut satırı araçlarının kod yerine yazdığı mesajlar. Her kayıt anlamını, olağan nedenini ve sonra neyin kontrol edileceğini söyler.
Ham kodu görmek için doğrudan sorgulayın: dig example.com başlıkta status: NXDOMAIN ve çözümleyici gönderdiyse OPT bölümünde bir EDE: satırı gösterir. Aynı durumu DNS Sorgulama aracı da gösterir. En yaygın üç kodun ayrıntılı açıklaması için: NXDOMAIN, SERVFAIL, REFUSED: DNS hatanız aslında ne anlama geliyor.
Eşleşen kayıt yok.
Sunucu, istemcinin gönderdiği DNS Cookie'yi (RFC 7873) reddetti; genellikle sunucu sırrı değiştiği ya da bir anycast düğümü onu paylaşmadığı için. İstemci, sunucunun döndürdüğü yeni cookie ile tekrar dener; tek bir BADCOOKIE zararsızdır. Tekrarlayan hatalar farklı cookie sırları olan anycast düğümlerine veya OPT kaydını değiştiren bir ara cihaza işaret eder.
İmzalı mesajlarda TSIG hataları; genellikle sunucular arasındaki bölge aktarımları, NOTIFY veya dinamik güncellemeler. BADSIG: imza doğrulanmıyor (yanlış sır). BADKEY: anahtar adı veya algoritma karşı tarafça bilinmiyor. BADTIME: saatler izin verilenden fazla farklı (varsayılan 300 saniye). Anahtar adını, algoritmayı ve sırrı iki sunucuda bayt bayt karşılaştırın ve NTP'yi kontrol edin.
Sunucu, sorgudaki EDNS sürümünü desteklemiyor. Kullanılan tüm istemciler EDNS sürüm 0 kullanır; bu yüzden BADVERS genellikle gerçek bir sürüm uyuşmazlığı değil, bozuk bir sunucu veya ara cihaz demektir. dig +edns=0 example.com @server ile test edin; o da başarısızsa sunucunun EDNS işleyişi hatalıdır.
Çözümleyici işletmecisi, ad bir engelleme listesinde olduğu için çözümlemeyi reddetti: Quad9, AdGuard gibi çözümleyicilerde veya kurumsal DNS güvenlik duvarında kötü amaçlı yazılım, oltalama ya da reklam filtrelemesi. Yanıt genellikle NXDOMAIN veya bir "sinkhole" adresidir. Alan adının itibarını kontrol edin; hatalı tespitse çözümleyici işletmecisinden çıkarılmasını isteyin.
Çözümleyici yeniden denemek yerine daha önce önbelleğe aldığı bir hatayı döndürüyor. Yetkili sunucuların kısa bir kesintisinden sonra tipiktir: sorun giderilmiştir ama bazı çözümleyiciler birkaç dakika daha SERVFAIL verir. Yetkili sunucuların artık yanıt verdiğini doğrulayın, sonra bekleyin veya çözümleyicinin önbelleğini temizleyin.
Windows nslookup tarafından, sorgunuzdan önce, başlangıçta yazdırılır. nslookup kendi DNS sunucusunun IP adresi için PTR kaydı arar ve bu ters ad yoktur; genellikle 192.168.x.1 adresindeki bir modemde olur. Görseldir: alttaki sorgu yine çalışır. Kaldırmak için yerel DNS'inizde sunucunun adresine bir PTR kaydı ekleyin.
Çözümleyici, işletmecinin kendi politikası (Blocked) veya kullanıcının seçimi (Filtered) yüzünden değil, mahkeme kararı ya da ulusal engelleme listesi gibi dış bir zorunluluk nedeniyle yanıtı vermiyor. Başka bir çözümleyici genellikle gerçek yanıtı döndürür; yerel yasalara tabidir.
dig, denediği hiçbir sunucudan yanıt alamadı (yeni sürümler communications error to … timed out yazar). Bu bir DNS yanıtı değil, ağ hatasıdır: sunucu kapalı, UDP/TCP 53 portu engelli veya adres yanlış. Yerel çözümleyiciyi elemek için dig @1.1.1.1 deneyin, yolu Traceroute ile ve 53 portunu Port Kontrolü ile kontrol edin.
curl: (6) Could not resolve host: example.com, sistem çözümleyicisinin adres döndürmediği anlamına gelir: NXDOMAIN, A/AAAA kaydı yok veya erişilebilir DNS sunucusu yok. Hangisi olduğunu görmek için dig example.com çalıştırın. Konteynerlerde konteynerin içindeki /etc/resolv.conf dosyasını kontrol edin; 127.0.0.53 gibi yalnızca ana makinede çalışan bir çözümleyiciye oradan erişilemez.
nslookup bekledi (varsayılan 2 saniye) ve DNS sunucusundan yanıt alamadı. Ardından yanıt gelen tek bir zaman aşımı yalnızca yavaş veya kayıplı bir yoldur; tekrarlayan zaman aşımları sunucunun erişilemez, aşırı yüklü veya güvenlik duvarıyla engelli olduğunu gösterir. nslookup example.com 1.1.1.1 ile başka bir sunucu deneyin ve yavaşı ölüden ayırmak için bekleme süresini nslookup -timeout=10 ile artırın.
Windows, DNS yanıt kodlarını hata numaralarına eşler: 9001 FORMAT_ERROR (FORMERR), 9002 SERVER_FAILURE (SERVFAIL), 9003 NAME_ERROR (NXDOMAIN), 9004 NOT_IMPLEMENTED (NOTIMP), 9005 REFUSED. 9501 DNS_INFO_NO_RECORDS NODATA'dır: ad var ama o türde kayıt yok. Resolve-DnsName 9003'ü "DNS name does not exist" olarak gösterir. Listedeki ilgili kayda bakın; yerel önbelleği ipconfig /flushdns ile temizleyin.
Chrome, olumsuz bir yanıt almak yerine yapılandırılmış DNS sunucusuna hiç ulaşamadı. Olağan nedenler: artık var olmayan bir DNS sunucu adresi (eski modem, kaldırılmış VPN), DNS'i yakalayan bir VPN veya güvenlik ürünü, bozuk bir DNS-over-HTTPS ayarı. Bağdaştırıcının DNS sunucularını kontrol edin, test için VPN veya filtreleme yazılımını kapatın ve ipconfig /flushdns çalıştırın.
Chrome'un DNS sınaması başarısız oldu ve çalışan bir ağ bağlantısı da bulamadı. DNS ayarlarına değil, önce bağlantıya bakın (Wi-Fi, kablo, giriş sayfası isteyen ağ, modem). Diğer uygulamalar çalışıyorsa bir güvenlik duvarı veya VPN özellikle Chrome'u engelliyor olabilir.
Chrome NXDOMAIN yanıtı aldı: çözümleyici adın var olmadığını söylüyor. Önce yazımı kontrol edin. Alan adı sizinse: kayıtlı mı, süresi dolmamış ve clientHold durumunda değil mi (bkz. WHOIS), kayıt firmasındaki ad sunucuları bölgeyi barındıranlarla eşleşiyor mu (DNS Sorgulama, NS türü), kayıt yeni mi oluşturuldu (negatif önbellekleme, bkz. NXDOMAIN)? Chrome'un kendi önbelleğini chrome://net-internals/#dns adresinden temizleyin.
Üst bölgede bir DS kaydı var ama bölgedeki hiçbir DNSKEY onunla eşleşmiyor; güven zinciri kopar ve doğrulayan çözümleyiciler SERVFAIL döndürür. Klasik nedenler: eski DS'yi kaldırmadan DNS sağlayıcısı değiştirmek veya yeni DS'yi yeni anahtardan önce yayımlayan bir anahtar değişimi. Üst bölgedeki DS'yi bölgedeki DNSKEY ile DNSSEC Kontrolü aracıyla karşılaştırın; DS'yi kayıt firmasında kaldırın veya güncelleyin.
DNSSEC doğrulaması başarısız: imzalar var ama güven zincirine göre doğrulanmıyor. Doğrulayan çözümleyiciler (Google, Cloudflare, Quad9, çoğu ISS) SERVFAIL döndürürken doğrulama yapmayanlar yanıt vermeye devam eder; bu yüzden alan adı bazı ağlarda çalışır, bazılarında çalışmaz. Daha belirgin EDE'ye bakın (Signature Expired, DNSKEY Missing, RRSIGs Missing) ve DNSSEC Kontrolü çalıştırın.
Çözümleyici yanıtın güvenli, güvensiz veya sahte olduğuna karar veremedi; örneğin ihtiyaç duyduğu bir DNSKEY veya DS'yi alamadı. Genellikle bir imzalama hatasından çok erişilemeyen veya yavaş bir yetkili sunucunun yan etkisidir. Her ad sunucusunun DNSKEY sorgularına, büyük yanıtlar için TCP üzerinden de, yanıt verdiğini kontrol edin.
"DSO-TYPE not implemented": sunucunun türünü bilmediği bir DNS Stateful Operations isteğine (RFC 8490, uzun ömürlü TCP/TLS oturumlarında kullanılır) verilen yanıt. Sıradan sorgularda karşılaşmazsınız; yalnızca DNS push bildirimleri gibi DSO tabanlı yazılım geliştirirken önemlidir.
Tarayıcı ana bilgisayar adını bir IP adresine çeviremedi. DNS_PROBE_FINISHED_* hatalarının genel biçimidir: ad yok, A/AAAA kaydı yok veya çözümleyici başarısız oldu. Adı DNS Sorgulama ile kontrol edin; orada çözülüp tarayıcıda çözülmüyorsa işletim sistemi önbelleğini ve chrome://net-internals/#dns önbelleğini temizleyin ve tarayıcının Güvenli DNS ayarını kontrol edin.
Ad, istemci filtreleme istediği için filtrelendi: kullanıcının veya ağ yöneticisinin seçtiği aile dostu ya da reklam engelleyici bir çözümleyici profili (örneğin CleanBrowsing aile filtresi, NextDNS profilleri). Engelleme yanlışsa profili veya çözümleyiciyi değiştirin.
Çözümleyici, politika gereği gerçekten farklı bir yanıtı bilerek döndürdü: kötü amaçlı bir alan adı için sinkhole adresi, kapalı bahçe (walled-garden) sayfası veya giriş portalı. Normal olması gereken bir ad için görüyorsanız başka bir çözümleyiciyle karşılaştırın ve işletmeciye adın neden değiştirildiğini sorun.
"Biçim hatası": sunucu sorguyu ayrıştıramadı. Bugün neredeyse her zaman bozuk EDNS işleyişi demektir: OPT kaydında, bilinmeyen bir EDNS seçeneğinde veya büyük UDP boyutunda takılan eski bir sunucu, yük dengeleyici veya güvenlik duvarı. DNS Flag Day 2019'dan beri büyük çözümleyiciler EDNS olmadan tekrar denemez; bu tür alan adları doğrudan çalışmaz. Yetkili sunucuyu dig +norec example.com @ns1.example.com ile ve bir de +noedns ile test edin; yalnızca EDNS'li sorgu başarısızsa sunucuyu veya ara cihazı güncelleyin ya da yeniden yapılandırın.
Node'un dns.lookup() işlevi (http, fetch ve çoğu istemci kullanır) sistem çözümleyicisini çağırır. ENOTFOUND = ad çözülmüyor: NXDOMAIN veya A/AAAA kaydı yok. EAI_AGAIN = geçici hata: DNS sunucusu zaman aşımına uğradı veya SERVFAIL döndürdü; yeniden denemek işe yarayabilir. Docker veya Kubernetes'te alan adından önce konteynerin /etc/resolv.conf dosyasını ve küme DNS'ini kontrol edin.
Yetkili sunucu, çözümleyicinin geçersiz veya kullanılamaz saydığı veri döndürdü; örneğin bozuk bir kayıt veya yetki devriyle çelişen bir yanıt. Her ad sunucusunu doğrudan sorgulayıp karşılaştırın: olağan neden, bölgenin bozuk bir kopyasını sunan tek bir sunucudur.
Linux C kütüphanesinin EAI_NONAME için metni; ping, ssh, wget ve diğerleri yazdırır: adın adresi yok. Ya NXDOMAIN, ya A/AAAA kaydı yok, ya da ad /etc/hosts içinde değil ve DNS yapılandırılmamış. getent hosts example.com (uygulamalarla aynı yolu kullanır) ve dig example.com (yalnızca DNS) ile kontrol edin; aradaki fark /etc/nsswitch.conf veya /etc/hosts dosyasına işaret eder.
Çözümleyici başka bir sunucuyla konuşurken ICMP unreachable veya reddedilen TCP bağlantısı gibi kurtarılamaz bir ağ hatasıyla karşılaştı. Ad sunucusunun önündeki yönlendirmeye veya güvenlik duvarına işaret eder. Her ad sunucusu IP'sine giden yolu Traceroute ile kontrol edin.
Çözümleyici, bölgenin hiçbir yetkili sunucusundan kullanılabilir bir yanıt alamadı: hepsi zaman aşımına uğradı, reddetti veya erişilemezdi. Size dönen yanıt SERVFAIL'dir. Üst bölgede listelenen her NS'nin bölge için yanıt verdiğini (sağlayıcı değişikliğinden sonra lame delegation yaygındır), UDP ve TCP 53'ün açık olduğunu ve sunucuların çözümleyiciyi hız sınırına takmadığını kontrol edin.
DS kaydının gösterdiği DNSKEY'de Zone Key bayrağı ayarlı değil (256 veya 257 bayraklarında vardır, 0'da yoktur); bu yüzden anahtar bölgeyi doğrulayamaz. Genellikle elle oluşturulmuş veya bir araçla dönüştürülmüş, bayrakları yanlış bir anahtardır. Anahtarı DNS yazılımınızla yeniden üretin ve eşleşen bir DS yayımlayın.
Ayrı bir kod değildir: durum NOERROR ama yanıt bölümü boştur. Ad vardır, yalnızca sorduğunuz kayıt türü yoktur; örneğin A kaydı olan ama MX kaydı olmayan bir alan adı. NXDOMAIN'den (ad hiç yok) çok farklıdır. E-posta sorunlarında sık görülür: MX yoksa gönderenler A kaydına geri döner. Her türü DNS Sorgulama ile kontrol edin.
Sorgu başarılı oldu. Bu bir kayıt aldığınız anlamına gelmez: yanıt bölümüne bakın, boşsa bu NODATA'dır. NOERROR yanlış veriyle geliyorsa önbelleklemeye (DNS Yayılımı) veya hangi ad sunucusunun yanıt verdiğine bakın.
Windows nslookup'un NXDOMAIN için ifadesi: *** dns.server can't find example.com: Non-existent domain. Anlamı ve kontrolleri NXDOMAIN ile aynıdır. Yalnızca başlangıçta, sorgunuzdan önce görünüyorsa "Can't find server name for address" kaydına bakın.
Sorduğunuz sunucu bölge için yetkili değil ve özyineleme (recursion) sunmuyor, bu yüzden yanıt veremez. Genellikle yalnızca yetkili bir sunucuya başkasının alan adını sordunuz ya da üst bölge, artık bölgeyi barındırmayan bir sunucuya yetki devrediyor (lame delegation). İstemcileri özyinelemeli bir çözümleyiciye yönlendirin veya NS kayıtlarını düzeltin.
Sunucu henüz yanıt vermeye hazır değil: hâlâ başlıyor, bölgeleri yüklüyor veya önbelleğini dolduruyor. Saniyeler ile dakikalar içinde düzelmesi gerekir. Devam ederse sunucu günlüklerinde yüklenemeyen bir bölge arayın.
Sunucu istenen işlemi veya sorgu türünü desteklemiyor; örneğin ANY sorgularını kısıtlayan sunucular (RFC 8482) veya izin vermeyen bir sunucuya aktarım ya da güncelleme isteği. ANY yerine belirli kayıt türünü sorgulayın.
Bağlama göre iki anlamı vardır. Dinamik DNS UPDATE'te (RFC 2136): sunucu, güncellemedeki bölge için yetkili değildir; güncellemeyi birincil sunucuya gönderin. TSIG ile (RFC 8945): istek yetkili değildir; genellikle bölge aktarımında veya güncellemede eksik ya da yanlış bir TSIG anahtarı. Her iki tarafta allow-transfer / allow-update ayarlarını ve anahtarı kontrol edin.
"Uygulanmadı": sunucu bu tür isteği (opcode) desteklemiyor; örneğin yalnızca düz sorgulara yanıt veren bir sunucuya veya cihaza gönderilen NOTIFY, UPDATE veya IXFR. Bazen bozuk ara cihazlar EDNS sorgularına da döndürür. İstek türünü ve o sunucunun bunu işlemesi gerekip gerekmediğini kontrol edin.
Dinamik UPDATE'te: güncellemedeki bir ad, güncellenen bölgenin içinde değil. Genellikle istemci host.other.example kayıtlarını example.com bölgesine gönderdi. Güncellemedeki bölge veya kayıt adlarını düzeltin.
Yanıt bir adın veya türün olmadığını iddia ediyor ama NSEC/NSEC3 kanıtı taşımıyor; bu yüzden doğrulayan çözümleyici bu inkâra güvenemez. Genellikle NSEC kayıtlarını atan bir imzalayıcı veya sunucu, ya da kısmen imzalanmış bir bölge. Bölgeyi yeniden imzalayın ve DNSSEC Kontrolü ile denetleyin.
"Var olmayan alan adı": yetkili bir sunucu adın var olmadığını söyledi. Kendi alan adınız için kontrol edin: kayıt gerçekten sunulan bölgede yayımlandı mı; ad tam olarak doğru yazıldı mı (çift www.www yok); kayıt firmasındaki NS'ler DNS sağlayıcınızla eşleşiyor mu; alan adının süresi dolmamış ve askıya alınmamış mı (WHOIS). Yeni oluşturulan bir ad, SOA minimum TTL süresi boyunca önbelleklerde NXDOMAIN kalabilir (negatif önbellekleme). Ayrıntılı anlatım: NXDOMAIN, SERVFAIL, REFUSED rehberi.
Dinamik UPDATE'te: bir önkoşul "bu kayıt kümesi var olmalı" dedi ama yok. Güncellemenin tamamı reddedilir. Eski bir kaydın var olmasını bekleyen ACME/Let's Encrypt DNS istemcilerinde veya DHCP kaynaklı güncellemelerde yaygındır. Güncellemeden önce bölgenin mevcut içeriğini kontrol edin.
Genel kategori: çözümleyicinin tanımlı hiçbir koda uymayan bir açıklaması var ve bunu EDE'nin serbest metin kısmına koyar; örneğin dig çıktısında EDE: 0 (Other): (…). O metni okuyun; genellikle asıl sorunu adlandırır.
Çözümleyici size hizmet vermeyi reddediyor: adresiniz erişim listesinde yok. Bir şirket veya ISS çözümleyicisini kendi ağının dışından kullanırken ya da yalnızca kendi müşterilerine hizmet veren bir çözümleyicide tipiktir. Ağınızın atadığı çözümleyiciyi veya genel bir çözümleyiciyi kullanın.
Sunucu sorguyu anladı ve politika gereği yanıt vermeyi reddetti. Özyinelemeli bir çözümleyiciye sorduysanız: izinli istemci listesinde değilsiniz. Yetkili bir sunucuya sorduysanız: o bölgeyi barındırmıyor (çoğu zaman sağlayıcı değişikliğinden kalan bir NS kaydı) veya bölge aktarımı gibi istek türünü reddediyor. Kayıt firmasındaki her NS'nin bölgeyi gerçekten sunduğundan emin olun: her birini dig +norec example.com @nsX ile sorgulayın. Daha fazlası: NXDOMAIN, SERVFAIL, REFUSED rehberi.
Bölge imzalı (üst bölgede DS, DNSKEY mevcut) ama yanıt imzasız geldi, bu yüzden doğrulama başarısız. Tipik nedenler: bölgenin imzasız bir kopyasını sunan ikincil bir ad sunucusu veya RRSIG kayıtlarını atan bir yük dengeleyici ya da DNS proxy'si. Her NS'yi dig +dnssec ile sorgulayıp karşılaştırın.
nslookup'ın başarısız bir sorguyu bildirme biçimi, ardından neden gelir: ** server can't find example.com: NXDOMAIN (ad yok), : SERVFAIL (çözümleyici başarısız), : REFUSED (sunucu reddetti); bir IP için : NXDOMAIN eksik PTR kaydıdır. İlgili kayda bakın. Windows'ta NXDOMAIN ifadesi "Non-existent domain" şeklindedir.
Çözümleyici denedi ama yanıt üretemedi. Bu, adın var olmadığı anlamına gelmez. Olağan nedenler, sıklık sırasıyla: DNSSEC doğrulama hatası (doğrulama yapmayan ağlarda çalışır, Google/Cloudflare/Quad9'da başarısız olur; DNSSEC Kontrolü), hiçbir ad sunucusunun yanıt vermemesi, lame delegation veya ikincil sunucuda süresi dolmuş bölge. Yanındaki EDE koduna bakın; genellikle nedeni adlandırır. Sonra yetkili sunucuları doğrudan sorgulayın. Ayrıntılı anlatım: NXDOMAIN, SERVFAIL, REFUSED rehberi.
RRSIG'in son geçerlilik zamanı geçti. İmzalar imzalayıcı tarafından düzenli olarak yenilenir; imzalama durduysa (cron görevi, hizmet veya sağlayıcı otomasyonu bozulduysa) bölge günlerce çalışır, sonra doğrulamanın açık olduğu her yerde başarısız olur. Bölgeyi yeniden imzalayın ve otomasyonu düzeltin; bitiş tarihlerini DNSSEC Kontrolü ile görün.
RRSIG'in başlangıç zamanı, çözümleyicinin bakış açısından gelecekte. Genellikle imzalayan sunucunun saati ileride veya çözümleyicinin saati geride. İmzalayıcıda NTP'yi kontrol edin; imzalayıcılar küçük farkları karşılamak için başlangıcı normalde bir saat geriye alır.
Çözümleyici kaydı yetkili sunuculardan yenileyemedi ve önbellekten süresi dolmuş bir kopya sundu (serve-stale, RFC 8767). Bir yanıt aldınız ama yetkili tarafta sorun var. Bayat yanıt penceresi bitmeden, genellikle bir ile üç gün içinde, ad sunucularının yanıt verdiğini kontrol edin.
Stale Answer gibi, ama önbellekteki öğe olumsuz bir yanıttı: çözümleyici yetkili sunuculara ulaşamadı ve süresi dolmuş bir NXDOMAIN'i tekrarladı. Adı yeni oluşturduysanız asıl çözüm yetkili taraftadır; çözümleyici sunuculara ulaşana kadar yeni kaydınızı göremez.
Linux C kütüphanesinin EAI_AGAIN için metni: çözümleyici kesin bir yanıt vermedi. DNS sunucusu zaman aşımına uğradı, SERVFAIL döndürdü veya hiç yapılandırılmamış. "Name or service not known" (kesin hayır) ile aynı değildir. /etc/resolv.conf dosyasını kontrol edin; systemd-resolved varsa resolvectl status ve resolvectl query example.com çalıştırın. Sunucularda çoğu zaman giden 53 portunu engelleyen bir güvenlik duvarı veya kapalı bir DNS sunucusudur.
DNS over QUIC için tanımlıdır (RFC 9250): sunucu, 0-RTT erken verisiyle gönderilen bir sorguyu işlemez, çünkü erken veri yeniden oynatılabilir. İstemci, el sıkışma tamamlandıktan sonra yeniden göndermelidir. Yalnızca DoQ yazılımı geliştiriyor veya işletiyorsanız önemlidir.
UDP yanıtı sığmadığı için TC (kesilmiş) bayrağı ayarlıydı ve dig sorguyu TCP üzerinden tekrarladı. Büyük yanıtlarda normaldir: DNSSEC anahtarları, uzun TXT/SPF kayıtları, çok sayıda A kaydı. Yalnızca TCP denemesi de başarısız olursa sorundur: TCP 53 portu her yetkili sunucuda açık olmalıdır (RFC 7766). dig +tcp example.com @ns1.example.com ile test edin.
Bölge, çözümleyicinin desteklemediği veya devre dışı bıraktığı bir algoritmayla imzalanmış; bu yüzden bölgeyi imzasız sayar (koruma yok ama yanıt yine sunulur). RSA/MD5, DSA ve imzalama için giderek terk edilen RSA/SHA-1 (5 ve 7 numaralı algoritmalar) ile görülür. ECDSA P-256 (13) veya Ed25519 (15) ile yeniden imzalayın; NODA yasaklı algoritmaları işaretler.
Üst bölgedeki DS kaydı, çözümleyicinin desteklemediği bir özet türü kullanıyor; genellikle SHA-1 (tür 1) veya GOST (tür 3). Kullanılabilir başka DS yoksa bölge imzasız sayılır. Kayıt firmasında SHA-256 (tür 2) ile bir DS yayımlayın ve eskisini kaldırın.
Bölgenin NSEC3 parametreleri, çözümleyicinin kabul ettiğinden fazla karma yinelemesi kullanıyor (RFC 9276). Çözümleyiciye göre bölge güvensiz sayılır veya yanıtlar SERVFAIL olur. RFC 9276'nın önerdiği gibi NSEC3 yinelemesini 0'a ayarlayın ve boş tuz kullanın; mevcut değeri dig NSEC3PARAM example.com ile görün.
Özyineleme (recursion) yapmayan bir sunucuya, genellikle yetkili bir ad sunucusuna sordunuz. Onu doğrudan sorgulamak istediyseniz zararsızdır; kendi bölgeleri için yanıt doğrudur. Herhangi bir alan adı için tam yanıt bekliyorsanız yanlış sunucuyu gösteriyorsunuz: özyinelemeli bir çözümleyici kullanın. Uyarıyı kaldırmak için +norec ekleyin.
"Ad olmaması gerekirken var." Dinamik UPDATE'te bir önkoşul adın olmamasını istedi ama ad mevcut. Ayrıca bir DNAME yerine koyması 255 bayttan uzun bir ad oluşturacaksa da döndürülür (RFC 6672). Güncellemeler için bölgenin mevcut durumunu kontrol edin; DNAME için hedefi kısaltın.
Dinamik UPDATE'te: bir önkoşul bir kayıt kümesinin olmamasını istedi ama küme var. Güncellemenin tamamı reddedilir. İki istemci aynı kaydı oluşturmak için yarıştığında yaygındır. Önce mevcut kaydı okuyun, sonra güncelleyin.
Kaynaklar: RFC 1035 (RCODE 0–5), RFC 2136 (6–10), RFC 8490 (11), RFC 6891 ve RFC 8945 (16–22), RFC 7873 (23), RFC 8914 (EDE 0–24), RFC 9250 (EDE 26), RFC 9276 (EDE 27), IANA DNS Parameters kaydı. Bir alan adını bütünüyle NODA ile kontrol edin.
