Kazmak + iz her zaman doğru mu?

Bir DNS önbelleğinin doğruluğu söz konusu olduğunda, dig +traceDNS kaydına bakan bir internet için yetkili cevabı belirlemenin önerilen yolu olma eğilimindedir. Bu +additional, aynı zamanda tutkal kayıtlarını da gösteren, eşleştirildiğinde özellikle yararlı görünmektedir .

Bazen bu noktada bazı anlaşmazlıklar var gibi gözüküyor - bazı insanlar ara isim sunucularının IP adreslerini aramak için yerel çözücüye güvendiğini söylüyor, ancak komut çıktısı bunun ilk kök listenin ötesinde olduğuna dair hiçbir kanıt sunmuyor. ad sunucularının. Amacı +tracekök sunuculardan başlamak ve aşağı inmekse bunun gerçekleşmeyeceğini varsaymak mantıklı görünüyor . (en azından doğru root ad sunucusu listesine sahipseniz)

dig +traceYerel çözümleyiciyi kök ad sunucularının ötesindeki herhangi bir şey için kullanıyor mu ?

Bu açık bir şekilde sahnelenmiş bir soru-cevap, ancak bu insanları sık sık şaşırtmaya meyillidir ve konuyu kapsayan kanonik bir soru bulamıyorum.

dig +tracemükemmel bir tanı aracıdır, ancak tasarımının bir yönü yaygın olarak yanlış anlaşılmıştır: sorgulanacak her sunucunun IP'si, çözümleyici kütüphanenizden elde edilir . Bu kolayca göz ardı edilir ve genellikle yalnızca yerel önbelleğinizin önbelleğe alınmış bir ad sunucusu için yanlış yanıtı olduğunda bir sorun haline gelir .

Detaylı analiz

Bu, çıktının bir örneğiyle parçalanması daha kolaydır; İlk NS delegasyonundan sonraki her şeyi atlayacağım.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• . IN NS(Root nameservers) için ilk sorgu , bu durumda Comcast olan yerel çözümleyiciye isabet eder. ( 75.75.75.75) Bu noktaya kolay.
• Bir sonraki sorgu içindir serverfault.com. IN Ave karşı çalışır e.root-servers.net., rastgele biz sadece var kök isim sunucularının listesinden seçilen. IP adresi 192.203.230.10var ve +additionaletkinleştirdiğimizden beri yapıştırıcıdan geliyor gibi görünüyor .
• Serverfault.com için yetkili olmadığından, bu işlem com.TLD ad sunucularına verilir.
• Buradaki çıktıdan açık olmayan digşey, IP adresini e.root-servers.net.yapıştırıcıdan türetmemiş olmasıdır.

Arka planda, gerçekte olan bu:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+traceyapıştırıcıya danışmak yerine bir sonraki sekme ad sunucusunun IP adresini almak için yerel çözümleyiciyi aldattı ve danışın. Sinsi!

Bu genellikle "yeterince iyi" dir ve çoğu insan için bir soruna neden olmaz. Ne yazık ki, kenar davaları var. Sebebi ne olursa olsun, upstream DNS önbellek ad sunucusu için yanlış cevap veriyorsa, bu model tamamen bozuluyor.

Gerçek dünya örneği:

• etki alanı sona eriyor
• tutkal kayıt memuruna yeniden yönlendirildi
• sahte IP'ler ns1 ve ns2 için önbelleğe alınır.
• etki alanı geri yüklenen tutkalla yenilendi
• sahte ad sunucusu IP'lerine sahip tüm önbellek, insanları alanın satılık olduğunu söyleyen bir web sitesine göndermeye devam eder

Yukarıdaki durumda, +traceetki alanı sahibinin kendi ad sunucularının sorunun kaynağı olduğunu ve müşteriye sunucularının yanlış yapılandırıldığını yanlış söylemekten bir aramanız olduğunu söyleyeceksiniz. Bunun hakkında bir şeyler yapabileceğiniz (veya yapmaya istekli olduğunuz) bir şey olup olmadığı başka bir hikaye, ancak doğru bilgiye sahip olmak önemlidir.

dig +trace harika bir araçtır, ancak herhangi bir araç gibi, ne yaptığını ve ne yapmadığını ve yetersiz olduğunu kanıtladığında sorunun nasıl giderileceğini bilmeniz gerekir.

Düzenle:

Ayrıca , takma adlara işaret dig +traceeden NSkayıtlar hakkında sizi uyarmayacağına da dikkat edilmelidir CNAME. Bu, ISC BIND'in (ve muhtemelen başkalarının) düzeltmeye çalışmadığı bir RFC ihlalidir. Yerel olarak yapılandırılmış ad sunucunuzdan aldığı kaydı +tracekabul etmekten tamamen mutlu olacaktır; Aoysa BIND tam tekrarlama yapıyorsa tüm bölgeyi bir SERVFAIL ile reddeder.

Yapıştırıcı varsa sorun gidermek zor olabilir; NS kayıtları yenilenene kadar bu gayet güzel çalışacak , sonra aniden kırılacak. Tutkalsız delegasyonlar, bir kayıt diğer adı işaret ettiğinde BIND'in özyinelemesini daima kıracak NS.

Kök ad sunucularını bulmak dışında herhangi bir şey için yerel çözümleyiciyi kullanmadan DNS çözümlemesini izlemenin başka bir yolu, dnsgraph'ı kullanmaktır (Tam açıklama: Bunu yazdım). Bir komut satırı aracı ve http://ip.seveas.net/dnsgraph/ adresinde bir örnek bulabileceğiniz bir web sürümüne sahiptir

Şu anda aslında bir DNS sorunu olan serverfault.com örneği:

Bu konuya çok geç kaldım, ancak bir dig + trace'ın neden yerel çözümleyicilere özyinelemeli sorgular kullandığı sorusunun bir kısmının doğrudan açıklanmadığını düşünüyorum ve bu açıklama dig + trace'ın sonuçlarının doğruluğu ile ilgilidir.

Kök bölgesinin NS kayıtları için ilk özyinelemeli sorgudan sonra, dig, aşağıdaki koşullar altında yerel çözümleyicilere daha sonra sorgular verebilir:

1. Bir sonraki yinelemeli sorgu için yanıtın boyutu 512 baytı geçen bir başvuru yanıtı kesiliyor

2. dig, EK bölümünde karşılık gelen A kaydının (tutkal) eksik olduğu yönlendirme yanıtının YETKİLİ bölümünden bir NS kaydı seçer.

Kazı, NS kaydında yalnızca bir etki alanı adına sahip olduğundan, kazı yerel DNS sunucusunu sorgulayarak bir IP adresine çözmelidir. Bu kök nedenidir (pun amaçlanan, üzgünüm).

AndrewB, daha önce tanımladığımla tamamen uyumlu olmayan bir örneğe sahipti; buradaki bölge NS kaydı seçildi:

. 121459 IN NS e.root-servers.net.

Karşılık gelen bir A kaydı var:

e.root-servers.net. 354907 IN A 192.203.230.10

Bununla birlikte, e-root için karşılık gelen bir AAAA kaydının olmadığını ve diğer bazı kök sunucular için AAAA kaydının olmadığını unutmayın.

Ayrıca, yanıtın boyutunu not edin:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 bayt, kesilmiş yanıtlar için ortak bir boyuttur (yani, bir sonraki yapıştırıcı kaydı,> 5 bayttan daha fazla olan, 16 bayt olacaktır). Başka bir deyişle, kökün NS kayıtları için bir sorguda, tam bir YETKİ ve tam bir EK (hem A hem de AAAA kayıtları) 512 bayttan fazla olacaktır; Yukarıdaki izlemenin gösterdiği gibi EK bölümünde bir yerde kesilmiş bir yanıt alın (sadece f, h, i, j ve k A ve AAAA yapıştırıcı kayıtlarına sahiptir).

E.root-servers.net için bir AAAA kaydının olmayışı ve "NS" e verilen yanıtın boyutu. Sorgu, bir sonraki özyinelemeli sorgunun iddia ettiğim sebepten dolayı yapıldığını şiddetle tavsiye eder. Belki de müşteri O / S, IPv6 yeteneğine sahiptir ve AAAA kayıtlarını veya başka bir nedeni tercih eder.

Ancak, her durumda, bu konuyu okuduktan sonra, root için ilkinden sonraki özyinelemeli sorguları yapan dig + trace olgusuna baktım. Karşılık gelen bir A / AAAA kaydı olmadan bir NS kaydı seçmek ve kazmak ve ardından bu kayıt için yerel DNS'ye bir özyinelemeli sorgu göndermek arasındaki yazışma benim deneyimime göre% 100'dür. Ve bunun tersi doğrudur - Yönlendirmeden seçilen NS kaydının karşılık gelen bir yapıştırıcı kaydına sahip olduğu zaman özyinelemeli sorgular görmedim.