โดยหลักการแล้วการจำแนกชื่อ DNS ทำงานอย่างไร

ตอนนี้ฉันกำลังเรียนหลักสูตรออนไลน์สำหรับ Linux ดูแลระบบและฉันถูกถามคำถามที่ฉันไม่เข้าใจ ฉันรู้วิธีค้นหาเซิร์ฟเวอร์ชื่อถ้าฉันถูกต้องอย่างน้อยก็ใช้คำสั่ง dig เพื่อค้นหาที่อยู่ในคำสั่งส่วนเพิ่มเติม แต่ฉันก็หายไปเล็กน้อยเมื่อถูกถามคำถามต่อไปนี้

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

ฉันไม่ต้องการคำตอบฉันแค่อยากรู้ว่าฉันถูกขอให้ทำอะไร

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

เรามาเลือกอันนี้กัน

"การสันนิษฐานว่าเนมเซิร์ฟเวอร์ที่คุณกำหนดไม่มีผลการแคชใด ๆ " - ก่อนถ้าหากไม่มีข้อมูลแคชเลยก็ไม่สามารถแก้ไขอะไรได้ ในการที่จะแคชแคชของตัวแก้ไขเฉพาะคุณต้องมีระเบียน NS และที่อยู่ (A, AAAA) สำหรับ.โซน (AKA root) นั่นคือเซิร์ฟเวอร์รูทชื่อซึ่งอยู่ในroot-servers.net.โซน ไม่มีอะไรน่าอัศจรรย์เกี่ยวกับโซนนั้นหรือเซิร์ฟเวอร์ DNS เหล่านั้น อย่างไรก็ตามข้อมูลนี้มักจะมอบ "ตัวนอกแบนด์" ให้กับตัวแก้ไข DNS เพื่อระบุแคชของตัวแก้ไข เซิร์ฟเวอร์ชื่อแบบใช้สิทธิ์เท่านั้นไม่ต้องการข้อมูลนี้ แต่การแก้ไขปัญหาชื่อเซิร์ฟเวอร์ทำได้

นอกจากนี้ "แก้ไข" เพื่ออะไร RRtype ในชื่อนั้น? อันARR หรืออย่างอื่น? คลาสใด ( CH/ Chaosnet, IN/ Internet, ... )? กระบวนการที่แน่นอนจะแตกต่างกัน แต่ความคิดทั่วไปยังคงเหมือนเดิม

หากเราสามารถสันนิษฐานได้ว่าเรารู้วิธีค้นหาเซิร์ฟเวอร์ชื่อรูท แต่ไม่มีอะไรเพิ่มเติมและโดย "แก้ไข" เราหมายถึงการได้รับเนื้อหาของIN ARR ใด ๆ ที่เกี่ยวข้องกับชื่อนั้นจะได้รับประโยชน์มากกว่า

ในการแก้ไขชื่อ DNS คุณจะต้องแบ่งชื่อออกเป็นป้ายกำกับจากนั้นดำเนินการตามวิธีจากขวาไปซ้าย อย่าลืม.ตอนจบ; คุณต้องการจริงๆจะแก้ไขปัญหามากกว่าmaps.google.com. maps.google.comสิ่งนี้ทำให้เราไม่จำเป็นต้องแก้ไข (เรารู้สิ่งนี้ แต่การใช้งานตัวแก้ไข DNS อาจไม่เกิดขึ้น):

• .
• com.
• google.com.
• maps.google.com.

เริ่มต้นด้วยการหาว่าจะถามเนื้อหาของ.ที่ไหน ง่ายมาก เรามีอยู่แล้วข้อมูลว่าเซิร์ฟเวอร์ชื่อรากชื่อและที่อยู่ IP ดังนั้นเรามีเซิร์ฟเวอร์ชื่อรูท สมมติว่าเราตัดสินใจใช้ 198.41.0.4 ( a.root-servers.netหรือ 2001: 503: ba3e :: 2: 30) เพื่อดำเนินการแก้ไขชื่อต่อไป ในทางปฏิบัติหนึ่งในสิ่งแรกที่ทำโดยตัวแก้ไขอาจใช้ข้อมูลเซิร์ฟเวอร์รูทที่จัดไว้ให้ถามหนึ่งในเซิร์ฟเวอร์รูทโซนสำหรับรายการที่ถูกต้องของเซิร์ฟเวอร์ชื่อสำหรับโซนรูทดังนั้นจึงมั่นใจได้ว่าหาก ชื่อและที่อยู่ IP นั้นถูกต้องและสามารถเข้าถึงได้มันจะมีชุดข้อมูลที่สมบูรณ์และครบถ้วนสำหรับรูทโซนเมื่อการแก้ปัญหาเริ่มต้นขึ้น

ยิงออกแบบสอบถาม DNS สำหรับmaps.google.com. IN Aถึง 198.41.0.4 มันจะบอกคุณในการตอบสนอง "ไม่ไม่ทำ แต่นี่คือคนที่อาจรู้"; นั่นคือการอ้างอิง มันมีNSเร็กคอร์ดสำหรับโซนที่ใกล้เคียงที่สุดที่เซิร์ฟเวอร์ที่สงสัยทราบพร้อมกับเร็กคอร์ดการติดกาวที่เซิร์ฟเวอร์พร้อมใช้งาน หากไม่มีข้อมูลกาวคุณต้องแก้ไขโฮสต์นั้นที่มีชื่อในระเบียน NS ที่คุณเลือกดังนั้นจึงทำการแยกการจำแนกชื่อเพื่อรับที่อยู่ IP หากมีข้อมูลกาวคุณจะมีที่อยู่ IP ของเนมเซิร์ฟเวอร์ที่อย่างน้อย "ใกล้ชิด" กับคำตอบ ในกรณีนี้นั่นจะเป็นชุดของเซิร์ฟเวอร์สำหรับcom.โซนและข้อมูลกาวก็มีให้เช่นกัน

ทำซ้ำกระบวนการโดยถามหนึ่งในcom.เซิร์ฟเวอร์ชื่อคำถามเดียวกัน พวกเขาไม่รู้เช่นกัน แต่จะแนะนำคุณไปยังเซิร์ฟเวอร์ชื่อที่เชื่อถือได้ของ Google ณ จุดนี้ในกรณีทั่วไปมันจะถูกตีหรือพลาดว่ามีข้อมูลกาวหรือไม่ ตัวอย่างเช่นไม่มีสิ่งใดที่ทำให้comโดเมนมีเนมเซิร์ฟเวอร์ได้เฉพาะในnlกรณีที่ข้อมูลกาวไม่น่าจะพร้อมใช้งานจากเซิร์ฟเวอร์ gTLD ข้อมูลกาวที่ให้มาอาจไม่สมบูรณ์หรือถ้าคุณโชคไม่ดีจริง ๆ ก็อาจจะไม่ถูกต้อง! คุณต้องเสมอได้เตรียมที่จะวางไข่ออกว่าการแก้ปัญหาชื่อแยกต่างหากผมกล่าวข้างต้น

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

ทางเลือกในการขอ RRname แบบเต็มจากแต่ละเซิร์ฟเวอร์ (ซึ่งอาจพิจารณาว่าเป็นวิธีปฏิบัติที่ไม่ดี) คือการใช้รายการแยกฉลากของป้ายกำกับที่เรากำหนดไว้ก่อนหน้านี้ให้ถามชื่อเซิร์ฟเวอร์ที่เซิร์ฟเวอร์กำหนดต่อไปสู่รูทIN NSและIN A/ IN AAAARR สำหรับป้ายกำกับนั้นและใช้สิ่งเหล่านี้เพื่อดำเนินการแก้ไขปัญหาชื่อเพิ่มเติม นั่นแตกต่างกันเล็กน้อยในทางปฏิบัติและกระบวนการเดียวกันยังคงใช้

คุณสามารถจำลองกระบวนการทั้งหมดนี้โดยใช้+traceตัวเลือกให้กับdigยูทิลิตี้ที่มาเป็นส่วนหนึ่งของห่วงหรือในset debugnslookup

นอกจากนี้ยังเป็นมูลค่าการจดจำว่าบาง RRtypes (สะดุดตาNS, MXและอื่น ๆ น้อย; ยังA6ได้รับดีพอสมควรใช้ในขณะที่ แต่ได้เลิกใช้) และสามารถทำอ้างอิง RRs อื่น ๆ ในกรณีนี้คุณอาจต้องวางไข่อีกกระบวนการแก้ปัญหาชื่ออื่นเพื่อให้การตอบกลับที่สมบูรณ์และมีประโยชน์ต่อลูกค้าของคุณ

มีdnstracerคำสั่ง (คุณอาจต้องติดตั้งอย่างน้อยก็ใน Debian นั่นก็คือชื่อแพ็คเกจ) ซึ่งจะติดตามการจำแนกชื่อ คุณยังสามารถใช้ (ตามที่ Koveras ชี้ให้เห็นในความคิดเห็น) digได้เช่นกัน

นี่คือกับ dnstracer -s .หมายถึงการเริ่มต้นด้วยราก -4หมายถึงการใช้ IPv4 (v6 เสียที่นี่ ... ); -oหมายถึงการแสดงที่อยู่ IP ที่ได้รับการแก้ไขแล้วจริงในตอนท้าย (ฉันไม่ได้ระบุส่วนหนึ่งของผลลัพธ์ที่มีจำนวนมาก)

anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ m.gtld-servers.net [com] (192.55.83.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer 
⋮

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

ดังนั้นคุณสามารถดูได้ว่ามีการใช้แบบสอบถามหนึ่งรายการไปยังเซิร์ฟเวอร์ชื่อรูทจากนั้นหนึ่งรายการไปยังเซิร์ฟเวอร์ gtld (เซิร์ฟเวอร์สำหรับโซน com) ซึ่งเป็นเซิร์ฟเวอร์สุดท้ายสำหรับเซิร์ฟเวอร์ชื่อของ Google

ด้วยdigผลลัพธ์จะมากขึ้น verbose (ดังนั้นฉันจะทำมากตัด):

dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
.                       425379  IN      NS      b.root-servers.net.
⋮
com.                    172800  IN      NS      f.gtld-servers.net.
⋮
google.com.             172800  IN      NS      ns2.google.com.
⋮
maps.google.com.        300     IN      A       74.125.228.70
⋮

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

wiresharkคุณสามารถของหลักสูตรยังดูคำสั่งที่เกิดขึ้นจริงบนลวดที่มีเช่น