Alan Sorunlarını Giderme

Google Açık DNS bir alanı çözemediğinde, bunun nedeni genellikle o alanla veya yetkili alan adı sunucularıyla ilgili bir sorundur. Aşağıdaki adımlar, soruna neden olan noktaları belirlemeye yardımcı olabilir. Böylece alan yöneticileri sorunu çözebilir.

Bu adımlara başlamadan önce, genel sorun giderme sayfasında açıklandığı şekilde dns.google adresindeki alanı kontrol edin. Bu adım, sizi aşağıdaki belirli bir teşhis adımına yönlendirebilir. Aksi takdirde, nedeni bulana kadar aşağıdaki adımların tümünü deneyin.

1. Adım: DNSSEC doğrulama sorunlarını kontrol edin

Alan için dns.google web aramaları, "Status": 2 (SERVFAIL) değerini gösterir ve DNSSEC olmayan sorgular başarılı olursa alanın alan sunucuları veya üst düzey alan (TLD) kayıt otoritesinde (kayıtlı alanların DNSSEC doğrulaması için DS kayıtlarını yayınlayan) bir DNSSSEC sorunu olabilir.

Kayıt operatörü veya DNS hizmetindeki değişiklikler

DNSSEC sorunları, bir alan DNSSEC'yi destekleyen bir kayıt operatöründen veya DNS hizmetinden bir alan adıyla geçiş yaptıktan sonra ortaya çıkabilir. Önceki hizmet, TLD kaydındaki eski DS kayıtlarından ayrılırsa ve yeni hizmet TLD kaydında eşleşen DS kayıtlarına sahip yeni DNSKEY kayıtları oluşturmazsa Google Public DNS gibi çözümleyicileri doğrulamak alanı çözemez.

Bu durumda alan kayıt operatörünüzden eski DS kayıtlarını TLD kayıt defterinden kaldırmasını isteyin.

DNSSEC yanıtları çok büyük

DNSSEC sorunlarının bir diğer nedeni, tek bir IP paketine sığmayacak kadar büyük DNSSEC yanıtları olabilir. Bu durum, kesilebilecek parçalanmış yanıtlar oluşturur. DNSViz "UDP yük boyutu azaltılana kadar yanıt alınmadı" hatasını gösteriyorsa DNSSEC hataları, çok büyük yanıtlardan kaynaklanabilir. Yanıt boyutları, aşağıdaki işlemlerden biri veya daha fazlası azaltılabilir:

  • Yetkili alan adı sunucuları için "minimum sayıda yanıt" yapılandırın
  • Etkin DNSKEY kayıtlarının sayısını iki veya üçe indirin
  • 1280 veya 2048 bit DNSKEY kayıtları (RFC 6781, StackExchange) kullanın
  • RSA imzalarından daha küçük ECDSA imzalarına geçiş (RFC 8624)

Ayrıca, 2. adımdaki araçlar tarafından raporlanan diğer DNSSEC sorunlarını kontrol edin. Alt alan adları (harici veritabanlarında bulunan ve bölgelerin sahip olduğu DNSDNS) veya RRSIG imzaları (manuel olarak yapılandırılmış, hatalı imzalama işlemleri ile birlikte) kanıtlayan hatalı NSEC veya NSEC3 ret reddi kayıtları buna örnek gösterilebilir.

2. Adım: Yetkili alan adı sunucularını kontrol edin

Arşivlenmiş DNSViz sayfası

Google Açık DNS (veya herhangi bir açık çözümleyici) bir alanın çözülmesiyle ilgili sorun yaşıyorsa DNSViz, bu soruna neden olan alan ve alan adı sunucusu sorunlarını gösterir. DNSViz web sayfasına gidin ve sorunlu alan adını girin. DNSViz'in geçmiş verileri yoksa veya yalnızca bir günden daha eski verileri varsa (buradaki sayfada gösterildiği gibi) aşağıdaki daha küçük bir Analiz düğmesini görmek için büyük Analiz düğmesini tıklayın (önceden görünür değilse) ve onu tıklayın. Analiz tamamlandığında sonuçları göstermek için "Devam"ı tıklayın. Ayrıntıları göstermek için sol kenar çubuğundaki kırmızı hataları ve sarı uyarıları tıklayın veya bilgileri bağlam içinde ortaya çıkarmak için işaretçiyi şemadaki nesnelerin üzerinde tutun.

Önceki teşhiste, alanla ilgili olası DNSSEC sorunları belirtildiyse DNSSEC Analiz Aracı web sayfasına gidin ve alan adını girin. Bu analizci DNSSEC hatalarını veya uyarılarını bildirirse, hataları düzeltmeye yönelik öneriler için işaretçiyi kırmızı ⊗ veya sarı ⚠︎ simgelerinin üzerinde tutun.

intoDNS web sayfası, ana sayfaya girilen alanla ilgili DNSSEC olmayan sorunları bildirir ve bunların düzeltilmesine yönelik öneriler gösterir.

Alan yöneticileri, hem Google Açık DNS'e hem de diğer çözücülere sorunlara neden olabildiğinden bu araçların belirttiği hataların çoğunu düzeltmelidir.

3. Adım: Yetki sorunlarını kontrol edin

Google Açık DNS, yalnızca ana alandan gelen yönlendirmelerde döndürülen alan adı sunucularını kullanan "ana odaklı" bir çözümleyicidir. TLD'deki alan adı sunucusu adları ve birleştirici adresler eski veya hatalıysa bu durum yetki sorunlarına yol açabilir.

DNSViz veya inDNS, TLD'de yetkilendirilen alan adı sunucuları ile alt alanın kendisinde bulunan sunucular arasında tutarsızlıklarla ilgili uyarılar bildirirse Google Public DNS'in alanı çözümleyebilmesi için önce bu sorunların ele alınması gerekebilir. Bu araçlar kayıtlı alan adının (NXDOMAIN) mevcut olmadığını bildirirse herhangi bir nedenle alanın süresinin dolmadığından veya askıya alınmış olmadığından emin olun.

Yetkilendirme sorunları, bir alan için alan adı sunucularının adlarının çözümlenmemesinden de kaynaklanabilir. Alan adı sunucularıyla ilgili sorun olup olmadığını görmek için dns.google adresinde alan adı sunucularının A ve AAAA kayıtlarını kontrol edin.

4. Adım: Büyük yanıtları kontrol edin

DNS, trafiğinin büyük bir kısmını taşımak için UDP protokolünü kullanır. Büyük UDP veri şemaları, parçalanmaya ve parçalı UDP aktarımlarının güvenilir olmaması nedeniyle bozulabilir. Bu, DNS Flag Day 2020 programının odağındaydı. Bu çalışma, DNS'nin güvenilirliğini dünya genelinde iyileştirme çabamızın bir parçasıydı. Google Açık DNS bu çalışmaya katıldı ve UDP üzerinden kabul edeceği UDP yanıtlarının boyutunu sınırlandırır. Kendi komut isteminiz veya bir Google Cloud Shell ile aşağıdaki gibi bir sorgu deneyin:

$ dig +short example.com NS
ns1.example.com
ns2.example.com
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com A
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com TXT
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com example.com DNSKEY
...
$ dig +dnssec +nocrypto +bufsize=1400 +timeout=1 @ns1.example.com com DNSKEY
...

Çeşitli kayıt türleri için bu sorgular şunları belirtir:

+dnssec
DNSSEC'yi etkinleştirin (özellikle kullanılabilir olduğunda DNSSEC doğrulaması için gerekli kayıtları döndürün). Bu anahtarlar, sonucun boyutunu önemli ölçüde genişletebilir. Bu, Google Açık DNS davranışını taklit eder.
+bufsize=1400
İzin verilen UDP arabellek boyutunu sınırlayın. Bu, DNS Bayrak Günü 2020 çalışması itibarıyla Google Açık DNS'in emülasyonunu taklit eder.
+timeout=1
Zaman aşımını bir saniye olarak ayarlayın. Bu, Google Açık DNS davranışını taklit eder.
@ns1.example.com
Sorgulanacak yetkili sunucu: @ işaretini koruyun, ancak ilk komutta gösterildiği gibi kendi alanınızın yetkili sunucusuyla değiştirin.

Çıkışa dikkat edin. Aşağıdaki gibi bir satır mı görüyorsunuz?

;; Truncated, retrying in TCP mode.
Bu, yanıtın istenen UDP arabellek boyutundan daha büyük olduğunu, dolayısıyla kesildiğini ve istemcinin TCP'ye geçtiğini gösterir. Yetkili sunucularınız, DNS trafiğini 53 numaralı bağlantı noktası üzerinde işleyebilmelidir. (RFC 7766'ya bakın. Bu durumda, uygulamaların hem UDP hem de TCP taşımasını desteklemesi gerekir.)
;; MSG SIZE rcvd: 2198
1400'ün üzerindeki numaralar için? Bu da büyük bir yanıt olduğunu gösteriyor.
;; Query time: 727 msec
500'ün üzerindeki sayılar için Yavaş yanıtlar (özellikle de 1 saniyeden uzun veya kısa olanlar) Google Açık DNS tarafından silinebilir. Bu durum, özellikle bir UDP girişimi üzerinde bir zaman geçirildikten sonra bir TCP girişimi tarafından harcandığında olası bir durumdur. Sunucunun ve istemcinin coğrafi konumu, gecikmeyi önemli ölçüde etkileyebilir.
;; connection timed out; no servers could be reached
Özellikle yalnızca bazı sorgular için bu durum, sunucunuzun DNS sorgularını zamanında yanıtlayamadığı bir sorun olduğunu gösterir.

Aşağıdaki sorgu varyasyonlarını deneyebilirsiniz:

+tcp parametresi ekleniyor.
Bu sayede dig, TCP'yi hemen kullanmaya zorlanır. Yetkili sunucunuzun TCP sorgularını doğrudan bu şekilde işleyip işlemediğini kontrol edebilirsiniz.
+bufsize=1400 parametresi kaldırılıyor.
Bu işlem, dig adlı tarayıcının varsayılan davranışını (4096'daki boyut) döndürür. Sorgularınız bu ayarla başarısız olursa ancak bu ayar olmadan çalışırsa bu, sunucunuzun TCP yük devretme işlemini iyi bir şekilde işlemediğini gösterir. Büyük yanıtları taşımak için UDP'yi temel almak yalnızca belirli durumlarda işe yarar. En iyi yöntem, DNS için TCP taşıma işlemini desteklemektir.
Tekrarlanan her alan adı sunucusu.
Yukarıdaki örnekte iki yetkili alan adı sunucusu (ns1 ve ns2) vardır. Bazı sorunlara, farklı sunucuların farklı yanıtlar döndürmesi neden olur. Tüm yetkili sunucularda aynı sorguları tekrarlayarak hepsinin tutarlı bir şekilde yanıt verdiğinden emin olun.

Tüm sorgular küçük boyutlu (1.400 bayt veya daha kısa), hızlı (tercihen 500 milisaniye veya daha kısa) ve güvenilir (TCP ve UDP üzerinden tutarlı bir şekilde çalışıyorsa) yanıt boyutu konusunda endişeleriniz yoktur. Diğer sorun giderme bölümlerini okuyun. Yanıtlarınız hızlı olsa bile, coğrafi olarak uzaktaki sorgular daha yavaş olabilir.

Bu kontrollerden herhangi biri başarısız olduysa (büyük mi? yavaş mı? güvenilir değil mi?) ana işlem A'dır.); yanıtınız istenen UDP arabelleği boyutunu ve B'yi aştığında sunucunuzun UDP kesmesiyle yanıt verdiğinden emin olun. Ardından, TCP sorgusu yeniden denemesi gerçekleştirilebilir. DNS güvenilirliği sorunlarını teşhis etmenize yardımcı olacak çeşitli araçlar vardır:

Bu araçlar hata veya uyarı verirse bunları ele aldığınızdan emin olun. Ayrıca bu sitedeki diğer tüm sorun giderme talimatlarını okuduğunuzdan emin olun.

5. Adım: Diğer herkese açık çözümleyicilerin alanı çözüp çözmediğini kontrol etme

Yukarıdaki adımları uyguladıktan sonra sorunun herhangi bir nedenini bulamadıysanız, aşağıdaki komutları bir komut isteminde çalıştırarak example.test. söz konusu alanla (ve sondaki noktaları koruyarak) değiştirin:

Windows

nslookup example.test. resolver1.opendns.com.
nslookup example.test. dns.quad9.net.
nslookup example.test. one.one.one.one.

macOS veya Linux

dig example.test. '@resolver1.opendns.com.'
dig example.test. '@dns.quad9.net.'
dig example.test. '@one.one.one.one.'

Bu komutlar OpenDNS, Quad9 ve Cloudflare 1.1.1.1'in DNS çözümleyicilerini kullanır. Google Public DNS'in yanı sıra ikisinden de çözüm hataları alıyorsanız sorun muhtemelen alanla veya alan adı sunucularıyla ilgilidir.

Birden fazla herkese açık çözümleyiciden başarılı bir sonuç alırsanız Google Açık DNS ile ilgili bir sorun olabilir. Sorun izleyicide alan (veya TLD) için benzer bir sorun bildirilmemişse raporunuzdaki komut çıkışı ve teşhis sayfası metni ya da ekran görüntüleri dahil olmak üzere sorunu bize bildirmeniz gerekir.