ขุด + ติดตามถูกต้องเสมอ?


30

เมื่อคำถามเกี่ยวกับความถูกต้องของแคช DNS dig +traceมีแนวโน้มที่จะเป็นวิธีที่แนะนำในการพิจารณาคำตอบที่เชื่อถือได้สำหรับอินเทอร์เน็ตที่มีระเบียน DNS สิ่งนี้ดูเหมือนว่าจะเป็นประโยชน์อย่างยิ่งเมื่อจับคู่กับ+additionalซึ่งยังแสดงบันทึกกาว

บางครั้งดูเหมือนว่าจะมีความขัดแย้งในบางจุด - บางคนบอกว่ามันขึ้นอยู่กับตัวแก้ไขในท้องถิ่นเพื่อค้นหาที่อยู่ IP ของเซิร์ฟเวอร์ชื่อกลาง แต่ผลลัพธ์ของคำสั่งไม่ได้บ่งชี้ว่าสิ่งนี้เกิดขึ้นนอกเหนือจากรายการเริ่มต้นของราก เซิร์ฟเวอร์ ดูเหมือนว่ามีเหตุผลที่จะสมมติว่าสิ่งนี้จะไม่เกิดขึ้นหากจุดประสงค์ของ+traceการเริ่มต้นที่เซิร์ฟเวอร์รากและติดตามวิธีการของคุณลง (อย่างน้อยถ้าคุณมีรายชื่อเซิร์ฟเวอร์ที่ถูกต้อง)

ไม่dig +traceจริงๆใช้จำแนกท้องถิ่นสำหรับสิ่งที่ผ่านมาเซิร์ฟเวอร์ราก?

คำตอบ:


26

เห็นได้ชัดว่านี่เป็นคำถามและคำตอบที่ชัดเจน แต่มีแนวโน้มที่จะสร้างความสับสนให้กับผู้คนบ่อยครั้งและฉันไม่สามารถหาคำถามมาตรฐานที่ครอบคลุมหัวข้อ

dig +traceเป็นเครื่องมือวินิจฉัยที่ดี แต่แง่มุมหนึ่งของการออกแบบที่จะเข้าใจผิดกันอย่างแพร่หลาย: IP ของเซิร์ฟเวอร์ที่จะสอบถามจะได้รับจากห้องสมุดจำแนกของคุณทุกคน สิ่งนี้ถูกมองข้ามได้ง่ายมากและมักจะกลายเป็นปัญหาเมื่อแคชในเครื่องของคุณมีคำตอบที่ไม่ถูกต้องสำหรับแคชของเนมเซิร์ฟเวอร์


การวิเคราะห์รายละเอียด

นี่เป็นตัวอย่างที่ง่ายกว่าสำหรับการแยกเอาท์พุท; ฉันจะละเว้นทุกอย่างผ่านการมอบหมาย NS แรก

; <<>> 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(เนมเซิร์ฟเวอร์รูท) จะเข้าสู่ตัวแก้ไขเฉพาะจุด ( 75.75.75.75) จุดนี้ง่ายต่อการมองเห็น
  • เคียวรีถัดไปใช้สำหรับserverfault.com. IN Aและรันe.root-servers.net.สุ่มเลือกจากรายการของเนมเซิร์ฟเวอร์รากที่เราเพิ่งได้รับ มันมีที่อยู่ IP ของ192.203.230.10และเมื่อเรา+additionalเปิดใช้งานดูเหมือนว่าจะมาจากกาว
  • เนื่องจากไม่ได้รับสิทธิ์สำหรับ serverfault.com สิ่งนี้จึงได้รับมอบสิทธิ์ให้กับเนมcom.เซิร์ฟเวอร์ TLD
  • สิ่งที่ไม่ชัดเจนจากผลลัพธ์ที่นี่คือที่digไม่ได้รับที่อยู่ IP ของe.root-servers.net.จากกาว

ในพื้นหลังนี่คือสิ่งที่เกิดขึ้นจริง:

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)

+traceโกงและปรึกษาตัวแก้ไขในพื้นที่เพื่อรับที่อยู่ IP ของเซิร์ฟเวอร์ชื่อ hop ถัดไปแทนที่จะปรึกษากาว ส่อเสียด!

ซึ่งมักจะ "ดีพอ" และจะไม่ทำให้เกิดปัญหากับคนส่วนใหญ่ แต่น่าเสียดายที่มีกรณีขอบ ถ้าด้วยเหตุผลใดก็ตามแคช DNS ต้นน้ำของคุณกำลังให้คำตอบที่ผิดสำหรับเนมเซิร์ฟเวอร์รุ่นนี้จะพังทลายลงทั้งหมด

ตัวอย่างโลกแห่งความจริง:

  • โดเมนหมดอายุ
  • กาวได้รับการบรรจุใหม่ที่เซิร์ฟเวอร์การเปลี่ยนเส้นทางของผู้รับจดทะเบียน
  • IP ปลอมเป็นการแคชสำหรับ ns1 และ ns2.yourdomain.com
  • โดเมนจะต่ออายุด้วยกาวเรียกคืน
  • แคชใด ๆ ที่มี IP เนมเซิร์ฟเวอร์ปลอมจะยังคงส่งคนไปยังเว็บไซต์ที่ระบุว่าโดเมนนั้นมีไว้สำหรับขาย

ในกรณีดังกล่าวข้างต้น+traceจะแนะนำว่าเซิร์ฟเวอร์ชื่อของเจ้าของโดเมนเป็นสาเหตุของปัญหาและคุณโทรออกไปหนึ่งครั้งเพื่อบอกลูกค้าว่าเซิร์ฟเวอร์ของพวกเขาผิดพลาด ไม่ว่าจะเป็นสิ่งที่คุณสามารถ (หรือเต็มใจ) ทำบางสิ่งเกี่ยวกับเป็นอีกเรื่องหนึ่ง แต่สิ่งสำคัญคือต้องมีข้อมูลที่ถูกต้อง

dig +trace เป็นเครื่องมือที่ยอดเยี่ยม แต่เช่นเดียวกับเครื่องมือใด ๆ คุณจำเป็นต้องรู้ว่ามันทำอะไรและไม่ทำอะไรและวิธีแก้ไขปัญหาด้วยตนเองเมื่อมันพิสูจน์ว่าไม่เพียงพอ


แก้ไข:

ควรสังเกตว่าdig +traceจะไม่เตือนคุณเกี่ยวกับNSระเบียนที่ชี้ไปที่CNAMEนามแฝง นี่คือการละเมิด RFC ที่ ISC BIND (และอาจเป็นไปได้อื่น ๆ ) จะไม่พยายามแก้ไข +traceจะมีความสุขอย่างสมบูรณ์ที่จะยอมรับAบันทึกที่ได้รับจากเนมเซิร์ฟเวอร์ที่กำหนดค่าในพื้นที่ของคุณในขณะที่ถ้า BIND กำลังดำเนินการเรียกซ้ำแบบเต็มจะเป็นการปฏิเสธทั้งโซนด้วย SERVFAIL

นี่อาจเป็นเรื่องยุ่งยากในการแก้ไขปัญหาหากมีกาวอยู่ สิ่งนี้จะใช้ได้ดีจนกระทั่งระเบียน NS ถูกรีเฟรชจากนั้นก็แตก การมอบหมาย Glueless จะทำลายการเรียกซ้ำของ BIND เสมอเมื่อมีการNSบันทึกคะแนนในนามแฝง


เกี่ยวกับ+nssearchอะไร
vonbrand

@vonbrand +nssearchทำการNSค้นหาเรคคอร์ดกับตัวแก้ไขโลคัลของคุณสำหรับเร็กคอร์ดที่ร้องขอตามด้วยชุดA/ AAAAlookups เทียบกับตัวแก้ไขโลคัลสำหรับเนมเซิร์ฟเวอร์ที่ส่งคืนแต่ละรายการ นอกจากนี้ยังมีความอ่อนไหวต่อข้อมูลเนมเซิร์ฟเวอร์ปลอมในแคช
Andrew B

1
ดังนั้นทางออกคืออะไร? ใช้ "dig ... @server" และติดตามการมอบหมายด้วยตนเองหรือไม่
รามัน

@Raman ใช่มันเป็นอย่างนั้นหรือคุณต้องล้างแคชของเซิร์ฟเวอร์วนซ้ำที่คุณมีประโยชน์ทำแบบสอบถามและทิ้งแคช (ซึ่งเอาชนะความคิดของไคลเอนต์ที่มีน้ำหนักเบา) ขุดกำลังทำเช่นนี้เพื่อลดจำนวนของแบบสอบถามที่ต้องการ
Andrew B

11

อีกวิธีในการติดตามการแก้ไข DNS โดยไม่ใช้ Local Resolver สำหรับสิ่งใดนอกจากการค้นหาเนมเซิร์ฟเวอร์รูทคือการใช้dnsgraph (การเปิดเผยแบบเต็ม: ฉันเขียนสิ่งนี้) มันมีเครื่องมือบรรทัดคำสั่งและรุ่นของเว็บซึ่งคุณสามารถค้นหาตัวอย่างได้ที่http://ip.seveas.net/dnsgraph/

ตัวอย่างสำหรับ serverfault.com ซึ่งจริงๆแล้วมีปัญหา DNS ตอนนี้:

ป้อนคำอธิบายรูปภาพที่นี่


4
อวดรู้ในตัวฉันอยากจะบอกว่านี่ไม่ใช่คำตอบทางเทคนิค ผู้ดูแลระบบ DNS ในตัวฉันคิดว่ามันยอดเยี่ยมและไม่สนใจเลย
Andrew B

ฉันจะโพสต์เป็นความคิดเห็น แต่ต้องการรวมภาพ อย่าลังเลที่จะรวมมันเข้ากับคำตอบของคุณถ้าคุณคิดว่ามันดีกว่า
Dennis Kaarsemaker

1
ฉันสบายดีกับสิ่งต่างๆ ถ้า mod รู้สึกอย่างอื่นฉันจะรวมเอาไว้แน่นอน
แอนดรู B

0

ดึกมากถึงเธรดนี้ แต่ฉันคิดว่าส่วนหนึ่งของคำถามว่าทำไม dig + trace ใช้เคียวรีแบบเรียกซ้ำเพื่อตัวแก้ไขแบบโลคัลยังไม่ได้อธิบายโดยตรงและคำอธิบายนี้เกี่ยวข้องกับความถูกต้องของผลลัพธ์ dig + trace

หลังจากเคียวรีแบบเรียกซ้ำเริ่มต้นสำหรับเร็กคอร์ด NS ของรูทโซนแล้วขุดอาจออกเคียวรีที่ตามมาไปยังตัวแก้ไขโลคัลภายใต้เงื่อนไขต่อไปนี้:

  1. การตอบกลับการอ้างอิงถูกตัดทอนเนื่องจากขนาดของการตอบสนองเกิน 512 ไบต์สำหรับการค้นหาซ้ำครั้งถัดไป

  2. ขุดเลือกระเบียน NS จากส่วน AUTHORITY ของการตอบสนองการอ้างอิงซึ่งบันทึก A (กาว) ที่สอดคล้องกันนั้นหายไปในส่วนเพิ่มเติม

เนื่องจาก dig มีชื่อโดเมนจากระเบียน NS เท่านั้น dig ต้องแก้ไขชื่อให้เป็นที่อยู่ IP ด้วยการสอบถามเซิร์ฟเวอร์ DNS ในเครื่อง นี่คือสาเหตุที่แท้จริง (ใช้ตั้งใจขอโทษด้วย)

AndrewB มีตัวอย่างที่ไม่สอดคล้องอย่างสมบูรณ์กับสิ่งที่ฉันเพิ่งอธิบายในที่รูทระเบียน NS โซนที่เลือก:

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

มีบันทึก A ที่สอดคล้องกัน:

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

อย่างไรก็ตามโปรดทราบว่าไม่มีเรคคอร์ด AAAA ที่สอดคล้องกันสำหรับ e-root รวมถึงไม่มีเรคคอร์ด AAAA สำหรับเซิร์ฟเวอร์รูทอื่น ๆ

นอกจากนี้โปรดสังเกตขนาดของการตอบกลับ:

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

496 ไบต์เป็นขนาดทั่วไปสำหรับการตอบกลับที่ถูกตัดทอน (เช่นเรคคอร์ดกาวถัดไปจะมีค่า> 16 ไบต์ทำให้การตอบสนองมากกว่า 512 ไบต์) กล่าวอีกนัยหนึ่งในการค้นหาสำหรับระเบียน NS ของรูท AUTHORITY ที่สมบูรณ์และส่วนเพิ่มเติมที่สมบูรณ์ (ทั้งระเบียน A และ AAAA) จะเกิน 512 ไบต์ดังนั้นแบบสอบถามที่ใช้ UDP ซึ่งไม่ได้ระบุขนาดแบบสอบถามที่ใหญ่ขึ้นผ่านตัวเลือก EDNS0 รับการตอบสนองที่ถูกตัดออกบางส่วนในส่วนเพิ่มเติมตามที่แสดงด้านบน (เฉพาะ f, h, i, j และ k เท่านั้นที่มีเรกคอร์ด A และ AAAA)

การขาดระเบียน AAAA สำหรับ e.root-servers.net และขนาดของการตอบสนองต่อ "NS" ข้อความค้นหาขอแนะนำอย่างยิ่งให้ดำเนินการค้นหาแบบเรียกซ้ำครั้งถัดไปด้วยเหตุผลที่ฉันอ้างสิทธิ์ บางทีลูกค้า O / S สามารถใช้งาน IPv6 ได้และต้องการบันทึก AAAA - หรือด้วยเหตุผลอื่น

แต่ในกรณีใด ๆ หลังจากอ่านกระทู้นี้ฉันมองเข้าไปในปรากฏการณ์ของการขุด + ติดตามการดำเนินการสืบค้นแบบเรียกซ้ำหลังจากที่เริ่มต้นสำหรับราก ความสอดคล้องระหว่างการเลือกระเบียน NS ที่ไม่มีเร็กคอร์ด A / AAAA กาวและขุดที่สอดคล้องกันจากนั้นส่งแบบสอบถามแบบเรียกซ้ำสำหรับระเบียนนั้นไปยัง DNS ท้องถิ่น 100% ในประสบการณ์ของฉัน และสิ่งที่ตรงกันข้ามนั้นเป็นจริง - ฉันไม่เห็นข้อความค้นหาแบบเรียกซ้ำเมื่อระเบียน NS ที่เลือกจากผู้อ้างอิงมีระเบียนกาวที่เกี่ยวข้อง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.