เหตุใดจึงไม่สามารถใช้ระเบียน CNAME ที่ apex (aka root) ของโดเมนได้

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับ CNAMEs ที่ apices (หรือ root) ของโซน

มันเป็นความรู้ทั่วไปที่CNAMEบันทึกไว้ที่ปลายสุดของโดเมนเป็นการฝึกฝนที่ต้องห้าม

ตัวอย่าง: example.com. IN CNAME ithurts.example.net.

ในซอฟต์แวร์เนมเซิร์ฟเวอร์สถานการณ์กรณีที่ดีที่สุดอาจปฏิเสธที่จะโหลดการกำหนดค่าและในกรณีที่แย่ที่สุดก็อาจยอมรับการกำหนดค่านี้และทำให้การกำหนดค่าสำหรับ example.com เป็นโมฆะ

เมื่อเร็ว ๆ นี้ฉันมี บริษัท เว็บโฮสติ้งส่งคำแนะนำไปยังหน่วยธุรกิจที่เราต้องการ CNAME ซึ่งเป็นจุดสูงสุดของโดเมนของเราไปยังระเบียนใหม่ เมื่อรู้ว่านี่จะเป็นการกำหนดค่าการฆ่าตัวตายเมื่อถูกส่งไปยัง BIND ฉันแนะนำพวกเขาว่าเราจะไม่สามารถปฏิบัติตามได้และนี่เป็นคำแนะนำสองชั้นโดยทั่วไป บริษัท เว็บโฮสติ้งมีจุดยืนว่าไม่ได้ห้ามโดยวิธีกำหนดมาตรฐาน RFC และซอฟต์แวร์ของพวกเขารองรับ หากเราไม่สามารถ CNAME เอเพ็กซ์คำแนะนำของพวกเขาคือไม่มีเร็กคอร์ดเอเพ็กซ์เลยและพวกเขาจะไม่ให้เว็บเซิร์ฟเวอร์ที่เปลี่ยนเส้นทาง ...อะไร?

พวกเราส่วนใหญ่รู้ว่าRFC1912ยืนยันว่าA CNAME record is not allowed to coexist with any other data.แต่ขอซื่อสัตย์กับตัวเราที่นี่ RFC นั้นเป็นข้อมูลเท่านั้น ฉันรู้ว่าจะใช้คำฟุ่มเฟือยที่ใกล้เคียงกับการฝึกฝนมาจากRFC1034 :

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

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

นี่นำเราไปสู่คำถามและคำตอบ สำหรับครั้งหนึ่งที่ฉันต้องการให้เราได้รับเทคนิคจริงๆเกี่ยวกับความบ้าของ apex CNAMEs และไม่ได้รอบปัญหาเช่นที่เรามักจะทำเมื่อมีคนโพสต์ในเรื่อง RFC1912ไม่ได้ จำกัด เช่นเดียวกับ RFC ที่ให้ข้อมูลอื่น ๆ ที่นี่ที่ฉันไม่ได้คิด มาปิดทารกนี่สิ

CNAMEบันทึกเริ่มต้นสร้างขึ้นเพื่ออนุญาตให้มีชื่อหลายชื่อที่ให้ชื่อเดียวกันกับทรัพยากรให้เป็นชื่อแทน "canonical name" เดียวสำหรับทรัพยากร ด้วยการถือกำเนิดของชื่อโฮสต์เสมือนตามมันได้กลายเป็นเรื่องธรรมดาที่จะใช้พวกเขาเป็นรูปแบบทั่วไปของนามแฝงที่อยู่ IP น่าเสียดายที่คนส่วนใหญ่ที่มาจากพื้นหลังเว็บโฮสติ้งคาดว่าCNAMEระเบียนจะแสดงถึงความเท่าเทียมกันใน DNSซึ่งไม่เคยมีเจตนา เอเพ็กซ์มีประเภทบันทึกที่ไม่ได้ใช้อย่างชัดเจนในการระบุทรัพยากรโฮสต์มาตรฐาน ( NS, SOA) ซึ่งไม่สามารถใช้นามแฝงได้โดยไม่ทำลายมาตรฐานในระดับพื้นฐาน (โดยเฉพาะอย่างยิ่งเกี่ยวกับการตัดโซน )

น่าเสียดายที่มาตรฐาน DNS ดั้งเดิมถูกเขียนขึ้นก่อนที่หน่วยงานกำกับดูแลจะตระหนักว่าการใช้คำฟุ่มเฟือยที่ชัดเจนนั้นจำเป็นต่อการกำหนดพฤติกรรมที่สอดคล้องกัน ( RFC 2119 ) จำเป็นต้องสร้างRFC 2181เพื่อชี้แจงกรณีมุมหลายอันเนื่องจากถ้อยคำที่คลุมเครือและการใช้คำฟุ่มเฟือยที่ปรับปรุงทำให้ชัดเจนว่าCNAME ไม่สามารถใช้เพื่อให้ได้นามแฝง apex โดยไม่ทำลายมาตรฐาน

6.1 เขตอำนาจ

เซิร์ฟเวอร์ที่มีสิทธิ์สำหรับโซนจะระบุในระเบียน NS สำหรับที่มาของโซนซึ่งรวมถึงระเบียน Start of Authority (SOA) เป็นระเบียนบังคับในทุกโซน เซิร์ฟเวอร์ดังกล่าวมีสิทธิ์สำหรับระเบียนทรัพยากรทั้งหมดในโซนที่ไม่ได้อยู่ในโซนอื่น ระเบียน NS ที่ระบุว่าการตัดโซนเป็นคุณสมบัติของโซนย่อยที่สร้างขึ้นเช่นเดียวกับระเบียนอื่น ๆ สำหรับแหล่งกำเนิดของโซนย่อยนั้นหรือโดเมนย่อยใด ๆ เซิร์ฟเวอร์สำหรับโซนไม่ควรส่งคืนคำตอบที่เชื่อถือได้สำหรับแบบสอบถามที่เกี่ยวข้องกับชื่อในโซนอื่นซึ่งรวมถึง NS และอาจจะ A ระเบียนที่โซนตัดเว้นแต่จะเกิดขึ้นเป็นเซิร์ฟเวอร์สำหรับโซนอื่น

สิ่งนี้สร้างSOAและNSบันทึกนั้นเป็นข้อบังคับ แต่มันไม่ได้บอกอะไรAหรือมีประเภทอื่นปรากฏอยู่ที่นี่ ดูเหมือนว่าไม่จำเป็นที่ฉันจะพูดถึงเรื่องนี้ แต่มันจะมีความเกี่ยวข้องมากขึ้นในอีกสักครู่

RFC 1034ค่อนข้างคลุมเครือเกี่ยวกับปัญหาที่อาจเกิดขึ้นเมื่อมีCNAMEอยู่พร้อมกับประเภทระเบียนอื่น ๆ RFC 2181ลบความกำกวมและระบุประเภทบันทึกที่ได้รับอนุญาตให้อยู่เคียงข้างพวกเขาอย่างชัดเจน:

10.1 ระเบียนทรัพยากร CNAME

มีระเบียน DNS CNAME ("ชื่อมาตรฐาน") เพื่อระบุชื่อมาตรฐานซึ่งเชื่อมโยงกับชื่อนามแฝง อาจมีชื่อบัญญัติเพียงชื่อเดียวเท่านั้นสำหรับนามแฝงใด ๆ โดยทั่วไปชื่อนั้นควรเป็นชื่อที่มีอยู่ที่อื่นใน DNS แม้ว่าจะมีบางแอปพลิเคชั่นที่หายากสำหรับชื่อแทนที่มีชื่อมาตรฐานที่ไม่ได้ระบุใน DNS ชื่อนามแฝง (ป้ายกำกับของระเบียน CNAME) อาจใช้ DNSSEC หากมี SIG, NXT และ KEY RRs แต่อาจไม่มีข้อมูลอื่น นั่นคือสำหรับป้ายกำกับใด ๆ ใน DNS (ชื่อโดเมนใด ๆ ) หนึ่งในรายการต่อไปนี้เป็นจริง:

• มีหนึ่งระเบียน CNAME พร้อมด้วย SIG, NXT และ KEY RR ซึ่งเป็นทางเลือก
• มีอย่างน้อยหนึ่งระเบียนอยู่ไม่มีระเบียน CNAME
• มีชื่ออยู่ แต่ไม่มี RR ที่เกี่ยวข้องทุกประเภท
• ไม่มีชื่อเลย

"ชื่อนามแฝง" ในบริบทนี้อ้างถึงทางด้านซ้ายมือของCNAMEบันทึก รายการสัญลักษณ์ทำให้มันชัดเจนที่ชัดเจนว่าSOA, NSและAบันทึกไม่สามารถมองเห็นได้ที่โหนดที่ที่CNAMEยังปรากฏอยู่ เมื่อเรารวมสิ่งนี้เข้ากับส่วนที่ 6.1 มันเป็นไปไม่ได้ที่ a CNAMEจะอยู่ที่จุดสูงสุดเนื่องจากมันจะต้องอยู่ข้างๆบังคับSOAและNSบันทึก

(ดูเหมือนว่าจะทำงานนี้ แต่ถ้ามีคนที่มีเส้นทางที่สั้นกว่าเพื่อพิสูจน์โปรดให้รอยแตกที่มัน)

ปรับปรุง:

ดูเหมือนว่าความสับสนที่เกิดขึ้นเมื่อเร็ว ๆ นี้มาจากการตัดสินใจล่าสุดของ Cloudflareเพื่ออนุญาตให้มีการกำหนดระเบียน CNAME ที่ผิดกฎหมายที่จุดสุดยอดของโดเมนซึ่งพวกเขาจะสังเคราะห์ระเบียน A "สอดคล้องกับ RFC" ตามที่อธิบายโดยบทความที่เชื่อมโยงอ้างถึงความจริงที่ว่าระเบียนที่สังเคราะห์โดย Cloudflare จะเล่นได้ดีกับ DNS นี่ไม่ได้เปลี่ยนความจริงที่ว่ามันเป็นพฤติกรรมที่กำหนดเองอย่างสมบูรณ์

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

เมื่อเร็ว ๆ นี้ Internet Systems Consortium ได้โพสต์บทความลงบนCNAME ที่จุดสุดยอดของโซนเหตุใดจึงมีข้อ จำกัด นี้และมีทางเลือกมากมาย สิ่งนี้ไม่น่าจะเปลี่ยนแปลงได้ทุกเวลาเร็ว ๆ นี้น่าเศร้า:

เราไม่สามารถเปลี่ยนวิธีการใช้ระเบียน CNAME แบบพิเศษได้โดยไม่ต้องเปลี่ยนการปรับใช้เซิร์ฟเวอร์ DNS ทั้งหมดในโลกในเวลาเดียวกัน นี่เป็นเพราะความหมายและการตีความของมันถูกกำหนดอย่างเคร่งครัดในโปรโตคอล DNS; การใช้งานไคลเอนต์ DNS และเซิร์ฟเวอร์ปัจจุบันทั้งหมดเป็นไปตามข้อกำหนดนี้ ความพยายามที่จะ 'ผ่อนคลาย' วิธีใช้ CNAME ในเซิร์ฟเวอร์ที่มีสิทธิ์โดยไม่เปลี่ยนแปลงตัวแก้ไข DNS ทั้งหมดที่ใช้งานอยู่ในขณะนี้จะทำให้การจำแนกชื่อหยุดชะงัก (และบริการเว็บและอีเมลจะไม่พร้อมใช้งานเป็นระยะ ๆ สำหรับองค์กรเหล่านั้น

แต่มีความหวัง:

โซลูชันที่เป็นไปได้อื่นที่กำลังมีการหารือกันจะเพิ่มประเภทระเบียนทรัพยากร dns ใหม่ที่เบราว์เซอร์จะค้นหาซึ่งอาจมีอยู่ที่ปลาย นี่จะเป็นชื่อโฮสต์เฉพาะแอปพลิเคชันสำหรับคำขอ HTTP (คล้ายกับวิธีการทำงานของ MX)

ข้อดี: สิ่งนี้สอดคล้องกับการออกแบบ DNS อย่างสมบูรณ์
ข้อด้อย: ยังไม่พร้อมใช้งานและจะต้องมีการอัปเดตไคลเอ็นต์ของเบราว์เซอร์

หากคุณเปลี่ยนเส้นทางทั้งโซนคุณควรใช้ DNAME ตามRFC 6672 ,

DNAME RR และ CNAME RR [RFC1034] ทำให้การค้นหา (อาจ) ส่งคืนข้อมูลที่สอดคล้องกับชื่อโดเมนที่แตกต่างจากชื่อโดเมนที่สอบถาม ความแตกต่างระหว่างระเบียนทรัพยากรสองรายการคือ CNAME RR นำการค้นหาข้อมูลไปยังเจ้าของชื่ออื่นขณะที่ DNAME RR นำการค้นหาข้อมูลไปที่ลูกหลานของชื่อเจ้าของไปยังชื่อที่สอดคล้องกันภายใต้โหนด (เดี่ยว) ที่แตกต่างกันของ ต้นไม้.

ตัวอย่างเช่นดูผ่านโซน (ดู RFC 1034 [RFC1034], ส่วน 4.3.2, ขั้นตอนที่ 3) สำหรับชื่อโดเมน "foo.example.com" และพบระเบียนทรัพยากร DNAME ที่ "example.com" การค้นหาทั้งหมดภายใต้ "example.com" จะถูกนำไปที่ "example.net" กระบวนการค้นหาจะกลับไปที่ขั้นตอนที่ 1 ด้วยชื่อแบบสอบถามใหม่ของ "foo.example.net" หากชื่อแบบสอบถามเป็น "www.foo.example.com" ชื่อแบบสอบถามใหม่จะเป็น "www.foo.example.net"