เผยแพร่บันทึก SRV ที่ชี้ไปที่ชื่อแทน CNAME ซึ่งละเมิด RFC 2782 หรือไม่

ในความรับผิดชอบในการทำงานบางอย่างฉันต้องทำตามบันทึก SRV และฉันพยายามที่จะกระทบยอดงบ Wikipedia กับสิ่งที่ฉันเห็นใน DNS digs

ตามรายการระเบียน SRV วิกิพีเดีย ,

เป้าหมายในระเบียน SRV จะต้องชี้ไปที่ชื่อโฮสต์พร้อมระเบียนที่อยู่ (ระเบียน A หรือ AAAA) การชี้ไปที่ชื่อโฮสต์ที่มีระเบียน CNAME ไม่ใช่การกำหนดค่าที่ถูกต้อง

แต่ฉันเห็นระเบียนที่digส่งกลับระเบียน SRV ที่ชี้ไปที่ชื่อซึ่งเป็นชื่อแทนในระเบียน CNAME

นั่นคือสิ่งนี้:

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

ดูเหมือนว่าระเบียน SRV จะได้รับการกำหนดค่าอย่างที่รายการ Wikipedia ไม่ได้รับอนุญาต ฉันเข้าใจผิดอะไร มันแสดงให้เห็นหรือไม่ว่าบันทึก SRV ชี้ไปที่ alias.domain.com ซึ่งมีระเบียน CNAME ไม่ใช่ระเบียนที่อยู่

domain-name-system cname-record srv-record

— สกอตต์
แหล่งที่มา

ใน บริษัท ของฉันเราใช้บันทึก SRV บ่อยครั้งและส่วนใหญ่ใช้ CNAME และทำงานได้ดีดังนั้นจึงขัดกับกฎหรือไม่มันทำงานได้ดี :)

— olivierg

คำตอบ:

บทความ Wikipedia ที่คุณอ้างถึงรายงานว่าRFC 2782 ที่เกี่ยวข้องกับบันทึก SRV เกี่ยวข้อง:

เป้า

ชื่อโดเมนของโฮสต์เป้าหมาย ต้องมีที่อยู่หนึ่งระเบียนหรือมากกว่าสำหรับชื่อนี้ชื่อต้องไม่เป็นชื่อแทน (ในความหมายของ RFC 1034 หรือ RFC 2181)

สิ่งที่คุณเห็นคือการละเมิดกฎอย่างชัดเจน อย่างไรก็ตามมันอาจใช้งานได้ (และโดยปกติแล้ว ) หากแอปพลิเคชันไคลเอนต์ใด ๆ ที่กำลังมองหาระเบียน SRV นั้นฉลาดพอที่จะจัดการระเบียน CNAME ได้อย่างถูกต้องแม้ว่ามันควรจะคาดหวังว่าระเบียน A ในการตอบสนองเท่านั้น

แต่มันอาจไม่ทำงานเลย: มันไม่ได้รับการสนับสนุนและขึ้นอยู่กับแอปพลิเคชันไคลเอนต์อย่างสมบูรณ์ ดังนั้นจึงควรหลีกเลี่ยงเพราะไม่ปฏิบัติตามกฎที่เหมาะสมและอาจนำไปสู่ผลลัพธ์ที่ผิดพลาดและ / หรือไม่แน่นอน

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

— มัสซิโม
แหล่งที่มา

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

— Andrew B

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

— Massimo

แอปพลิเคชั่นไม่ต้องการความฉลาดมากเพียงแค่ขอให้ระบบปฏิบัติการเชื่อมต่อกับ "alias.domain.com" บนพอร์ต 4443 และเก็บรายละเอียดทั้งหมดไว้

— Massimo

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

— Andrew B

เซิร์ฟเวอร์อีเมลบางแห่งเริ่มละเว้น MXes ไปยัง CNAME เช่น GMX medienconsulting.at/…

— Marcel Waldvogel

นั่นเป็นตัวอย่างของพฤติกรรมที่ถูก จำกัด ใช่ ข้อ จำกัด มาจากRFC 2781ในคำจำกัดความของ "เป้าหมาย":

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

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

เพียงเพราะมันสามารถพบได้ในป่าไม่ได้หมายความว่ามันเป็น "โอเค" และจะเกิดอะไรขึ้นเมื่อมาตรฐานถูกเพิกเฉยแตกต่างกันไปในแต่ละผลิตภัณฑ์ ฉันยังไม่ได้ทดสอบการโต้ตอบกับSRVระเบียน แต่การตัดสินใจออกแบบที่รู้จักกันดีโดย ISC BIND เกี่ยวกับNSระเบียนที่ชี้ไปที่นามแฝงคือการวางระเบียนทั้งหมดหากพบในระหว่างการเรียกซ้ำ หากNSบันทึกทั้งหมดได้ลดลงในลักษณะนี้ผลลัพธ์ของการสืบค้นทั้งหมดจะเป็นSERVFAILของโดเมนย่อยที่เป็นปัญหา

ในระยะสั้นติดมาตรฐาน มันเป็นสิ่งเดียวที่ปลอดภัยที่จะทำ

— แอนดรูข
แหล่งที่มา