TL; DR: ใช่โดเมนย่อยระดับกลางจำเป็นต้องมีอยู่อย่างน้อยเมื่อมีการสอบถามตามคำจำกัดความของ DNS; อาจไม่มีอยู่ใน zonefile
ความสับสนที่อาจเกิดขึ้นเพื่อกำจัดอันดับแรก คำจำกัดความของ "Empty Non-Terminal"
คุณอาจสับสนสองสิ่งเช่นเดียวกับคำตอบอื่น ๆ กล่าวคือจะเกิดอะไรขึ้นเมื่อทำการสอบถามชื่อกับวิธีที่คุณกำหนดค่าเนมเซิร์ฟเวอร์และเนื้อหาของ zonefile
DNS เป็นลำดับชั้น สำหรับโหนดใบไม้ใด ๆ ที่มีอยู่ส่วนประกอบทั้งหมดที่นำไปสู่มันจะต้องมีอยู่ในแง่ที่ว่าถ้าพวกเขาถูกสอบถาม, เนมเซิร์ฟเวอร์ที่มีสิทธิ์ที่รับผิดชอบควรตอบกลับโดยไม่มีข้อผิดพลาด
ตามที่อธิบายไว้ในRFC 8020 (ซึ่งเป็นเพียงการทำซ้ำของสิ่งที่เป็นกฎเสมอ แต่มีเพียงผู้ให้บริการ DNS บางรายที่ต้องการการแจ้งเตือน) หากมีข้อสงสัยใด ๆ ผู้ให้บริการเนมเซิร์ฟเวอร์ที่มีสิทธิ์ตอบ NXDOMAIN (นั่นคือ: หมายความว่าไม่มีป้ายกำกับ "ด้านล่าง" ทรัพยากรนี้อยู่
ในตัวอย่างของคุณถ้าแบบสอบถามสำหรับintermediate.example.comผลตอบแทนNXDOMAINแล้วใด ๆ nameserver recursive ที่เหมาะสมจะทันทีตอบNXDOMAINสำหรับleaf.intermediate.example.comเนื่องจากบันทึกนี้ไม่สามารถอยู่ได้ถ้าป้ายกำกับทั้งหมดในนั้นไม่ได้อยู่ในฐานะที่บันทึก
สิ่งนี้ได้ระบุไว้แล้วในอดีตในRFC 4592เกี่ยวกับสัญลักษณ์แทน (ซึ่งไม่เกี่ยวข้องที่นี่):
พื้นที่ชื่อโดเมนเป็นโครงสร้างแบบต้นไม้ โหนดในต้นไม้มี
RRSet อย่างน้อยหนึ่งตัวและ / หรือมีลูกหลานที่รวมกันเป็นเจ้าของ
อย่างน้อยหนึ่ง RRSet โหนดอาจมีอยู่โดยไม่มี RRSets ต่อเมื่อมี
ลูกหลานที่ทำเช่นนั้น โหนดนี้เป็นเทอร์มินัลที่ว่างเปล่า
โหนดที่ไม่มีการสืบทอดคือโหนดลีฟ โหนดใบที่ว่างเปล่าไม่มีอยู่
ตัวอย่างที่ใช้งานได้จริงกับ. us ชื่อโดเมน
ให้เรานำตัวอย่างการทำงานจาก TLD .USที่มีจำนวนมากของป้ายในอดีตที่เป็น หยิบตัวอย่างออนไลน์ใด ๆ www.teh.k12.ca.usให้เราใช้
แน่นอนถ้าคุณค้นหาชื่อนี้หรือแม้กระทั่งteh.k12.ca.usคุณสามารถเรียกคืนAระเบียนได้ ไม่มีข้อสรุปใด ๆ ที่นี่เพื่อจุดประสงค์ของเรา (แม้จะมี CNAME อยู่ตรงกลาง แต่เราไม่สนใจสิ่งนั้น):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
ให้เราสอบถามตอนนี้k12.ca.us(ฉันไม่ได้ค้นหาเนมเซิร์ฟเวอร์ที่เชื่อถือได้ของมัน แต่นั่นไม่ได้เปลี่ยนผลลัพธ์จริง):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
เราเรียนรู้อะไรจากคำตอบนี้
NOERRORครั้งแรกมันเป็นความสำเร็จเพราะสถานะเป็น ถ้ามันเป็นอย่างอื่นและโดยเฉพาะอย่างยิ่งNXDOMAINแล้วก็teh.k12.ca.usไม่www.teh.k12.ca.usสามารถอยู่ได้
ประการที่สองส่วนคำตอบว่างเปล่า ไม่มีมีประวัติA k12.ca.usนี่ไม่ใช่ข้อผิดพลาดประเภทนี้ ( A) ไม่มีอยู่สำหรับบันทึกนี้ แต่อาจมีประเภทระเบียนอื่น ๆ สำหรับบันทึกนี้หรือบันทึกนี้เป็น ENT หรือที่รู้จักในชื่อ "Empty Non Terminal": ว่างเปล่า แต่ไม่ใช่ใบไม้ มีสิ่งต่าง ๆ "ด้านล่าง" มัน (ดูคำจำกัดความในRFC 7719 ) ตามที่เรารู้อยู่แล้ว (แต่โดยปกติแล้วความละเอียดจะอยู่ด้านบนลงไปดังนั้นเราจะไปถึงขั้นตอนนี้ก่อนที่จะลงไปหนึ่งระดับด้านล่าง วัตถุประสงค์).
นี่คือเหตุผลที่จริงแล้วในฐานะทางลัดเราบอกว่ารหัสสถานะคือNODATA: นี่ไม่ใช่รหัสสถานะจริงมันแค่หมายถึงNOERROR+ ว่างคำตอบส่วนซึ่งหมายความว่าไม่มีข้อมูลสำหรับประเภทบันทึกเฉพาะนี้ แต่อาจมีสำหรับคนอื่น ๆ
คุณสามารถทำซ้ำการทดสอบเดียวกันผลเหมือนกันถ้าคุณสอบถามกับต่อไป "ขึ้น" ca.usป้ายชื่อที่เป็นชื่อ
ผลลัพธ์ของแบบสอบถามกับเนื้อหาของ zonefile
ตอนนี้ความสับสนมาจากไหน? ฉันเชื่อว่าอาจมาจากความคิดที่ผิด ๆ ว่าจุดใด ๆ ในชื่อ DNS หมายถึงมีการมอบหมาย นี่เป็นเท็จ กล่าวว่าแตกต่างกันexample.comไฟล์ zonefile ของคุณอาจเป็นเช่นนั้นและมันก็ใช้ได้จริงและทำงานได้:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
ด้วย zonefile เช่นนี้การสอบถาม nameserver นี้คุณจะได้รับพฤติกรรมที่สังเกตเห็นข้างต้น: แบบสอบถามintermediate.example.comจะกลับมาNOERRORพร้อมกับคำตอบที่ว่างเปล่า คุณไม่จำเป็นต้องสร้างเฉพาะในไฟล์โซน (หากคุณไม่ต้องการด้วยเหตุผลอื่น) เนมเซิร์ฟเวอร์ที่มีสิทธิ์จะดูแลการสังเคราะห์การตอบกลับ "ขั้นกลาง" เพราะเห็นว่ามันต้องการเทอร์มินัลที่ว่างเปล่านี้ คนอื่น ๆ "ในระหว่าง" ถ้ามีการค่ายอื่น ๆ ) leaf.intermediate.example.comตามที่เห็นชื่อใบ
โปรดทราบว่านี่เป็นกรณีที่เกิดขึ้นอย่างกว้างขวางในความเป็นจริงในบางพื้นที่ แต่คุณอาจไม่เห็นเพราะมีเป้าหมาย "บันทึก" โครงสร้างพื้นฐานเพิ่มเติมที่คนไม่ได้รับ:
- ในโซนย้อนกลับเช่น
in-addr.arpหรือip6.arpaและเฉพาะโซนสุดท้าย คุณจะมีบันทึกเช่น1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.และเห็นได้ชัดว่าไม่มีการมอบหมายในแต่ละจุดหรือบันทึกทรัพยากรที่แนบมาที่ป้ายแต่ละป้าย
- ใน
SRVระเบียนเช่น_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.โดเมนสามารถมีจำนวนมาก_proto._tcp.example.comและ_proto._udp.example.com SRVบันทึกได้เนื่องจากจากการออกแบบพวกเขาจะต้องมีแบบฟอร์มนี้ แต่ในเวลาเดียวกัน_tcp.example.comและ_udp.example.comจะยังคงว่างเปล่าไม่ใช่เทอร์มินัลเพราะไม่เคยใช้เป็นบันทึก
- ในความเป็นจริงคุณมีกรณีอื่น ๆ ของการสร้างชื่อเฉพาะโดยใช้ "ขีดล่างป้ายกำกับ" สำหรับโปรโตคอลต่าง ๆ เช่น DKIM DKIM สั่งให้คุณมีระเบียน DNS เช่น
whatever._domainkey.example.comนี้ แต่แน่นอนว่า_domainkey.example.comจะไม่ถูกใช้ด้วยตัวเองดังนั้นมันจะยังคงไม่ใช่เทอร์มินัลที่ว่างเปล่า นี้เป็นเหมือนกันสำหรับTLSAระเบียนใน DANE (เช่น_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==) หรือURIระเบียน (เช่น: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
พฤติกรรมของเนมเซิร์ฟเวอร์และการสร้างการตอบกลับระดับกลาง
ทำไม Nameserver จึงทำการสังเคราะห์คำตอบระหว่างกลางโดยอัตโนมัติ? อัลกอริทึมการแก้ปัญหาหลักสำหรับ DNS ดังที่อธิบายไว้ในRFC 1034 ตอนที่ 4.3.2เป็นสาเหตุให้เรานำไปใช้และสรุปในกรณีของเราเมื่อทำการสอบถามชื่อเซิร์ฟเวอร์ที่เชื่อถือได้เหนือชื่อintermediate.example.com(นี่คือQNAMEในโปรโตคอลด้านล่าง):
- ค้นหาโซนที่มีอยู่สำหรับโซนซึ่งเป็นบรรพบุรุษที่ใกล้ที่สุดกับ QNAME หากพบโซนดังกล่าวให้ไปที่ขั้นตอนที่ 3 มิฉะนั้นขั้นตอนที่ 4
เนมเซิร์ฟเวอร์พบว่าโซนexample.comเป็นบรรพบุรุษที่ใกล้ที่สุดของ QNAME ดังนั้นเราสามารถไปที่ขั้นตอนที่ 3
ตอนนี้เรามีสิ่งนี้:
- เริ่มการจับคู่ลงป้ายกำกับโดยป้ายชื่อในโซน [ .. ]
หากจับคู่ทั้งหมดของ QNAME เราพบโหนดแล้ว [ .. ]
ข หากการแข่งขันนำเราออกจากข้อมูลที่เชื่อถือได้เรามีผู้อ้างอิง สิ่งนี้จะเกิดขึ้นเมื่อเราพบโหนดที่มีการทำเครื่องหมาย NS RRs ตามด้านล่างของโซน [ .. ]
ค หากมีป้ายกำกับบางรายการการจับคู่เป็นไปไม่ได้ (เช่นไม่มีป้ายกำกับที่เกี่ยวข้อง) ให้ดูว่ามีป้ายกำกับ "*" อยู่หรือไม่ [ .. ]
เราสามารถกำจัดเคส b และ c เนื่องจาก zonefile ของเราไม่มีการมอบหมาย (ดังนั้นจะไม่มีการอ้างอิงถึงเนมเซิร์ฟเวอร์อื่น ๆ ไม่มีเคส b) หรือ wildcard (ดังนั้นจึงไม่มีกรณี c)
เราจะต้องจัดการกับกรณีนี้ที่นี่
เราเริ่มการจับคู่ลงป้ายกำกับโดยป้ายกำกับในโซน ดังนั้นแม้ว่าเราจะมีsub.sub.sub.sub.sub.sub.sub.sub.example.comชื่อยาวในบางครั้งเรามาถึงในกรณีที่: เราไม่พบผู้อ้างอิงหรือตัวแทน แต่เราลงเอยด้วยชื่อสุดท้ายที่เราต้องการผลลัพธ์
จากนั้นเราใช้เนื้อหาส่วนที่เหลือ a:
หากข้อมูลที่โหนดเป็น CNAME
ไม่ใช่กรณีของเราเราข้ามไป
มิฉะนั้นให้คัดลอก RR ทั้งหมดที่ตรงกับ QTYPE ลงในส่วนคำตอบแล้วไปที่ขั้นตอนที่ 6
สิ่งที่เราเลือก QTYPE ( A, AAAA, NSฯลฯ ) เราไม่มี RRs สำหรับintermediate.example.comในขณะที่มันไม่ปรากฏใน zonefile ดังนั้นสำเนาที่นี่จึงว่างเปล่า ตอนนี้เราเสร็จที่ขั้นตอนที่ 6:
ใช้ข้อมูลท้องถิ่นเท่านั้นพยายามเพิ่ม RR อื่น ๆ ซึ่งอาจเป็นประโยชน์กับส่วนเพิ่มเติมของแบบสอบถาม ทางออก
ไม่เกี่ยวข้องกับเราที่นี่ดังนั้นเราจึงประสบความสำเร็จ
สิ่งนี้จะอธิบายพฤติกรรมที่สังเกตได้อย่างแม่นยำ: ข้อความค้นหาดังกล่าวจะส่งคืนNOERRORแต่ไม่มีข้อมูล
ตอนนี้คุณอาจถามตัวเองว่า: "แต่ถ้าฉันใช้ชื่อใด ๆ เช่นanother.example.comนั้นด้วยอัลกอริทึมด้านบนฉันควรได้รับคำตอบเหมือนเดิม (ไม่มีข้อผิดพลาด)" แต่การสังเกตจะรายงานNXDOMAINในกรณีนั้นแทน
ทำไม?
เนื่องจากอัลกอริทึมทั้งหมดตามที่อธิบายไว้ให้เริ่มด้วย:
อัลกอริทึมต่อไปนี้อนุมานว่า RRs ถูกจัดระเบียบในโครงสร้างแบบต้นไม้หลายแบบหนึ่งแบบสำหรับแต่ละโซนและอีกแบบหนึ่งสำหรับแคช
ซึ่งหมายความว่า zonefile ข้างต้นถูกแปลงเป็นต้นไม้นี้:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
ดังนั้นเมื่อทำตามขั้นตอนจากด้านบนคุณแน่นอนสามารถหาเส้นทาง: com > example > intermediate(เพราะเส้นทางที่com > example > intermediate > leafมีอยู่) แต่สำหรับanother.example.comหลังจากที่ com > exampleคุณไม่พบป้ายชื่อในต้นไม้เป็นเด็กโหนดanother exampleดังนั้นเราจึงตกอยู่ในส่วนของตัวเลือก c จากด้านบน:
หากไม่มีป้ายกำกับ "*" ให้ตรวจสอบว่าชื่อที่เรากำลังค้นหาเป็น QNAME ดั้งเดิมในแบบสอบถามหรือชื่อที่เราติดตามเนื่องจาก CNAME หากชื่อเป็นต้นฉบับให้ตั้งค่าข้อผิดพลาดของชื่อที่เชื่อถือได้ในการตอบกลับและออก มิฉะนั้นเพียงแค่ออกจาก
ฉลาก*ไม่ได้อยู่และเราไม่ได้ทำตามCNAMEดังนั้นเราอยู่ในกรณี: อาคาset an authoritative name error in the response and exitNXDOMAIN
โปรดทราบว่าทั้งหมดข้างต้นสร้างความสับสนในอดีต สิ่งนี้ถูกรวบรวมใน RFC บางตัว ดูตัวอย่างสถานที่ที่ไม่คาดคิดนี้ (ความสุขของข้อกำหนด DNS ที่ไม่สามารถต้านทานได้) กำหนดสัญลักษณ์แทน: RFC 4592 "บทบาทของสัญลักษณ์ในระบบชื่อโดเมน"และโดดเด่นในส่วนที่ 2.2 "กฎการดำรงอยู่" ซึ่งอ้างถึงในตอนต้นของ คำตอบของฉัน แต่ที่นี่มันสมบูรณ์มากขึ้น:
ไม่มีเทอร์มินัลที่ว่างเปล่า [RFC2136, ส่วน 7.16] เป็นชื่อโดเมนที่ไม่มีบันทึกทรัพยากร แต่มีโดเมนย่อยที่ทำ ในส่วน 2.2.1
"_tcp.host1.example" เป็นตัวอย่างของชื่อที่ไม่ใช่เทอร์มินัลที่ว่างเปล่า
ข้อความนี้ไม่มีส่วนประกอบของเทอร์มินัลที่ว่างเปล่าในส่วน 3.1 ของ RFC 1034:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
เครื่องหมายวงเล็บ "ซึ่งอาจว่างเปล่า" ระบุว่าไม่มี
เทอร์มินัลที่ว่างเปล่าได้รับการยอมรับอย่างชัดเจนและที่ไม่ใช่เทอร์มินัลว่าง
"นั้นมีอยู่"
การอวดรู้ย่อหน้าข้างต้นอาจนำไปสู่การ
ตีความว่ามีโดเมนทั้งหมดที่เป็นไปได้ - มากถึง
ขีด จำกัด ที่แนะนำของ 255 octets สำหรับชื่อโดเมน [RFC1035] ตัวอย่างเช่น
www.example อาจมี A RR และเท่าที่
เกี่ยวข้องจริงเป็นใบไม้ของโดเมนต้นไม้ แต่สามารถนิยามความหมายได้
ว่าหมายถึง www.example ยังมีอยู่แม้ว่าจะไม่มีข้อมูล ตามส่วนขยายโดเมนที่เป็นไปได้ทั้งหมดจะมีอยู่ตั้งแต่รูทลง
เนื่องจาก RFC 1034 ได้กำหนด "ข้อผิดพลาดเกี่ยวกับชื่อที่เชื่อถือได้ซึ่งระบุว่าไม่มีชื่อ" ในหัวข้อ 4.3.1 ดังนั้นสิ่งนี้จึงไม่ใช่เจตนาของคำจำกัดความดั้งเดิมโดยอ้างถึงความจำเป็นในการปรับปรุงคำจำกัดความในหัวข้อถัดไป
และคำจำกัดความในส่วนถัดไปคือย่อหน้าที่ฉันยกมาตอนต้น
โปรดทราบว่า RFC 8020 (ในNXDOMAINความหมายจริงๆNXDOMAINนั่นคือถ้าคุณตอบNXDOMAINสำหรับintermediate.example.comแล้วleaf.intermediate.example.comไม่สามารถอยู่) คือการได้รับคำสั่งในส่วนหนึ่งเป็นเพราะผู้ให้บริการ DNS ต่างๆไม่ได้ทำตามความหมายนี้และความเสียหายที่สร้างขึ้นหรือพวกเขาเพียงแค่ข้อบกพร่องดูตัวอย่างนี้ ได้รับการแก้ไขในปี 2013 ในรหัสเนมเซิร์ฟเวอร์ที่เชื่อถือได้ของ opensource: https://github.com/PowerDNS/pdns/issues/127
ผู้คนจำเป็นต้องใช้มาตรการเคาน์เตอร์เฉพาะสำหรับพวกเขานั่นไม่ใช่การแคชอย่างจริงจังNXDOMAINเพราะสำหรับผู้ให้บริการเหล่านั้นถ้าคุณไปNXDOMAINถึงบางโหนดมันอาจหมายความว่าคุณได้รับสิ่งอื่นมากกว่าNXDOMAINโหนดอื่นที่อยู่ด้านล่าง
และนี่ทำให้การลด QNAME (RFC 7816) เป็นไปไม่ได้ที่จะได้รับ (ดูhttps://indico.dns-oarc.net/event/21/contribution/298/attachments/267/487/qname-min.pdfสำหรับรายละเอียดที่ยาวขึ้น) ในขณะที่มันต้องการที่จะเพิ่มความเป็นส่วนตัว การมีอยู่ของเทอร์มินัลที่ว่างเปล่าในกรณีของ DNSSEC ยังสร้างปัญหาในอดีตโดยรอบการจัดการกับการไม่มีอยู่ (ดูhttps://indico.dns-oarc.net/event/25/contribution/403/attachments/378/647 /AFNIC_OARC_Dallas.pdfหากสนใจ แต่คุณต้องมีความเข้าใจที่ดีเกี่ยวกับ DNSSEC มาก่อน)
ข้อความสองข้อความต่อไปนี้เป็นตัวอย่างของปัญหาที่ผู้ให้บริการรายหนึ่งต้องสามารถบังคับใช้กฎนี้ได้อย่างถูกต้องบนช่องว่างที่ไม่ใช่ช่องว่างมันให้มุมมองบางส่วนของปัญหาและสาเหตุที่เราอยู่ที่นั่น: