มาตรฐานอินเทอร์เน็ตต้องการ reverse DNS สำหรับทุกอุปกรณ์หรือไม่

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

บางส่วนของ RFC เหล่านี้รวมถึง:

RFC1912 : ข้อผิดพลาดในการดำเนินงาน DNS ทั่วไปและการกำหนดค่า

โฮสต์ที่เข้าถึงได้ทางอินเทอร์เน็ตทุกคนควรมีชื่อ ... ตรวจสอบให้แน่ใจว่าบันทึก PTR และ A ของคุณตรงกัน สำหรับที่อยู่ IP ทุกแห่งควรมีระเบียน PTR ที่ตรงกันในโดเมน in-addr.arpa หากโฮสต์มีหลาย homed (มากกว่าหนึ่งที่อยู่ IP) ตรวจสอบให้แน่ใจว่าที่อยู่ IP ทั้งหมดมีระเบียน PTR ที่สอดคล้องกัน (ไม่ใช่แค่ที่อยู่แรก) ความล้มเหลวในการมีการจับคู่ PTR และระเบียน A อาจทำให้สูญเสียบริการอินเทอร์เน็ตที่คล้ายกับไม่ได้ลงทะเบียนใน DNS เลย

RFC1033 : แนวทางการดำเนินงานของผู้ดูแลระบบโดเมน

การเพิ่มโฮสต์

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

แม้จะมีทั้งหมดนั้นบางคนยังคงยืนยันว่าการสร้างเรคคอร์ด PTR นั้นไม่ได้ถูกกำหนดโดยมาตรฐานที่ควบคุมดูแล DNS ข้อกำหนดที่แท้จริงคืออะไร?

คำตอบสั้น ๆ

มาตรฐานที่ควบคุมการทำงานของ DNS ต้องการให้อุปกรณ์ทั้งหมดมีระเบียน PTR ที่ตรงกันหรือไม่ เลขที่

มาตรฐานสำหรับโปรโตคอลบางอย่างจำเป็นต้องมีPTRบันทึกที่สอดคล้องกับบันทึกที่เกี่ยวข้องAหรือAAAAไม่? ใช่.

แอปพลิเคชั่นบางตัวที่ไม่ได้ควบคุมโดย RFC มีข้อกำหนดเหมือนกันหรือไม่? ใช่.

PTR สามารถบันทึกที่ CNAME ได้หรือไม่? ใช่ แต่เป้าหมาย CNAME ต้องเป็นชื่อที่ไม่ซ้ำของอุปกรณ์ดังกล่าว (ไม่ใช่ CNAME อื่น) ( RFC 2181§10.2 , RFC1034 §3.6.2 )

การสร้างเรคคอร์ด PTR ที่บังคับใช้เป็นแนวปฏิบัติที่ดีที่สุดหรือไม่? เชื่อกันโดยทั่วไป แต่ก็มีปัญหาของตัวเอง

คำตอบยาว ๆ

คำถามและคำตอบนี้จัดทำขึ้นโดยมีจุดประสงค์เพื่อช่วยให้เกิดความเข้าใจผิดร่วมกัน

ส่วน underquoted อนาถของRFC1796ใช้ที่นี่:

มันเป็นความเข้าใจผิดอย่างน่าเสียดายที่การตีพิมพ์ในฐานะ RFC ให้การยอมรับในระดับหนึ่ง มันไม่ได้หรืออย่างน้อยที่สุดไม่เกินสิ่งพิมพ์ในวารสารปกติ ในความเป็นจริง RFC แต่ละอันมีสถานะเกี่ยวข้องกับความสัมพันธ์กับกระบวนการมาตรฐานอินเทอร์เน็ต: การให้ข้อมูลการทดลองหรือการติดตามมาตรฐาน (มาตรฐานที่เสนอมาตรฐานร่างมาตรฐานอินเทอร์เน็ตมาตรฐาน) หรือประวัติศาสตร์

RFC1912 เป็นข้อมูล RFC1033 ไม่ได้ระบุไว้อย่างชัดเจนและมีการแต่งตั้งอย่างเป็นทางการของUNKNOWNซึ่งหมายความว่ามันเก่าเพื่อที่ว่ามันไม่ควรจะถือเป็นข้อมูลอ้างอิงสำหรับอะไร พวกเขาไม่ได้กำหนดมาตรฐานและไม่สามารถใช้เพื่อเพิ่มมาตรฐานอย่างเป็นทางการ พวกเขาไม่ควรอ้างถึงในบริบทที่บอกเป็นนัยว่าพวกเขากำลังกำหนดมาตรฐาน

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

ที่กล่าวว่านอกเหนือจากระบบอัตโนมัติที่ดีมากนโยบายการสร้างบันทึก PTR บังคับยังสร้างมลพิษ

• มันเป็นเรื่องธรรมดามากสำหรับPTRระเบียนที่จะไม่ถูกซิงค์กับข้อมูลA/ AAAAระเบียนที่เกี่ยวข้องเนื่องจากอุปกรณ์ถูกเลิกใช้งานซึ่งส่งผลให้PTRข้อมูลปลอมเพิ่มขึ้นตลอดเวลา ข้อมูลนี้มีไว้เพื่อหลอกลวงผู้ที่พยายามปฏิบัติต่อข้อมูลนั้นอย่างน่าเชื่อถือเท่านั้น เจ้าของแอปพลิเคชั่นบางคนกระตือรือร้นที่จะข้ามมันไปเมื่อพวกเขากำลังค้นหาสาเหตุของปัญหาภาพหลอน ปัญหาจะยังคงแย่ลงเรื่อย ๆ เมื่อการยอมรับ IPv6 กลายเป็นเรื่องธรรมดามากขึ้นโดยเฉพาะอย่างยิ่งสำหรับผู้ดูแลระบบ DNS ที่รับผิดชอบพื้นที่ IP ของผู้ให้บริการ
• การมีบันทึก PTR หลายรายการสำหรับที่อยู่ IP เดียวกันนั้นค่อนข้างไร้ประโยชน์และการปฏิบัติตามคำแนะนำของ RFC ที่ให้ข้อมูลย่อมส่งผลให้เกิดสิ่งนี้ ดู: ทำไมไม่แนะนำให้ใช้เรคคอร์ด PTR หลายรายการใน DNS

อะไรคือสิ่งที่แย่กว่านั้น: ไม่มีบันทึก PTR หรือบันทึก PTR ที่ไม่ถูกต้อง หากแบ่งโปรโตคอลมาตรฐานเพราะต้องใช้ DNS ที่ถูกต้องทั้งที่ไม่ดีและหลังจริงอาจจะเลวร้ายยิ่ง นอกเหนือจากนั้นทุกคนมีความเห็นแตกต่างกันในเรื่องนี้ ไม่เป็นไร: คุณมีอิสระในการรวบรวมนโยบายและเครื่องมือที่ทำงานได้ดีที่สุดสำหรับทีมและ บริษัท ของคุณ เพียงตรวจสอบให้แน่ใจว่าพวกเขาปรับขนาดและให้ผลลัพธ์ที่สอดคล้องกันและจำไว้ว่า DNS แบบย้อนกลับจะมีความแม่นยำเท่ากับเวลาและวินัยของสมาชิกในทีมของคุณที่จะต้องให้

แต่บันทึก PTR ที่หายไปทำให้ sshd หยุด!

ยังไม่เป็นความจริง คนมักจะสับสนเส้นแบ่งระหว่างกรณีที่ไม่มีการบันทึก PTR (NXDOMAIN) และเสีย DNS ย้อนกลับ

การตอบกลับของNXDOMAINจะทำให้เกิดปัญหาหากคุณกำลังสื่อสารกับบริการที่ต้องใช้ DNS ย้อนกลับที่ยืนยันแล้ว (FCrDNS) เมลเซิร์ฟเวอร์, Kerberos, Oracle สแกน VIPs, ฯลฯ

DNS ที่ใช้งานไม่ได้คือเมื่อคุณไม่สามารถรับการNXDOMAINตอบสนองได้ทันเวลา แอปพลิเคชันจำนวนมาก (มีชื่อเสียงมากที่สุดsshd) จะบล็อกการค้นหา DNS ย้อนกลับหากมีปัญหาในการรับการตอบสนองจากแหล่งข้อมูลต้นน้ำในเวลาที่เหมาะสมทำให้เกิดความล่าช้าภายในแอปพลิเคชัน