DNS A ระเบียนที่มี https: // ในป้ายกำกับ

ฉันเพิ่งพบเป็นครั้งแรกที่บันทึกของแบบฟอร์ม A:

https://www.example.com.    <TTL>   IN  A   <IP address>

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

domain-name-system a-record

— บิงกี้
แหล่งที่มา

ที่อยู่ IP นั้นแตกต่างจากที่อยู่ตรงกับ www.example.com หรือไม่ อะไรทำให้คุณคิดว่าสิ่งนี้เป็นความตั้งใจและไม่ผิดพลาด?

— jcaron

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

— Binky

หากใครมีบัญชี Farsight DNSDB หรือบริการที่คล้ายกันและต้องการสอบถามพื้นที่ DNS แบบเต็มสำหรับระเบียน A อื่น ๆ ที่มี "https: //" นั่นจะเจ๋งจริงๆ :)

— บิงกี้

การทำแผนที่ที่อยู่ IP ของการบันทึกสำหรับการhttps://www.example.comจะแตกต่างจากการทำแผนที่ที่อยู่ IP www.example.comสำหรับ แผนที่ก่อนหน้านี้ไปยังที่อยู่ (หลายระเบียน A) ใน / 16 netblock ที่เป็นเจ้าของโดย "example.com" ต่อ ARIN whois แมปหลังไปที่ CNAME ในโดเมนของผู้ให้บริการ CDN รายใหญ่ ในที่สุดเครือข่าย CNAME จะจับคู่กับที่อยู่ IP ในเครือข่ายของผู้ให้บริการ CDN ในที่สุด

— Binky

@ บิกินี่: นั่นไม่ใช่เหตุผลที่ดีที่จะสงสัยว่าไม่ได้ตั้งค่าผิด การไร้ความสามารถใน บริษัท ใหญ่ ๆ นั้นเป็นเรื่องธรรมดามาก

— ..

คำตอบ:

คำอธิบายที่เป็นไปได้มากที่สุดคือผู้ใช้ที่ไม่คุ้นเคยกับ DNS พยายามกำหนดค่าระเบียน DNS และทำผิดพลาดที่เห็นได้ชัดสำหรับทุกคนที่คุ้นเคยกับ DNS แต่ไม่ใช่สำหรับคนที่ไม่ใช่

ในขณะที่ป้ายกำกับ DNS สามารถเป็นข้อมูลไบนารีใด ๆ โดยทั่วไปคุณควรอ่านส่วนที่เหลือของส่วนที่ 11 โดยเฉพาะ:

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

เหนือสิ่งอื่นใดซึ่งหมายความว่าไวยากรณ์ฉลากอาจมีข้อ จำกัด ขึ้นอยู่กับประเภท RR ตามที่ระบุใน RFC 1123 ส่วน 2.1 และ RFC 952 ชื่อโฮสต์อินเทอร์เน็ตมีไวยากรณ์ที่ จำกัด เช่นนี้ซึ่งโคลอนและสแลชไม่ถูกต้อง

— Michael Hampton
แหล่งที่มา

มันผิดสำหรับที่อยู่มาตรฐาน แต่อาจเป็นคนที่ใช้ DNS เป็นอุปกรณ์สื่อสารนอกวง

ไม่ใช่เรื่องยากที่จะจินตนาการว่าจะต้องส่งผ่านข้อมูลผ่าน DNS แทนที่จะเป็นช่องทาง "ปกติ"

— djsmiley2k - วัว
แหล่งที่มา

คุณช่วยจินตนาการให้พวกเราฟังหน่อยได้ไหม? มันเป็นคำตอบนี้ไม่ได้บอกว่าเกิดอะไรขึ้นจริง ๆ - เพียงว่าผู้ตอบคิดว่ามันเป็นตรรกะ

— Saiboogu

อาจเป็นคนที่ใช้ DNS เป็นอุปกรณ์สื่อสารนอกแบนด์ @ djsmiley2k ฉันไม่ได้พูดถึงความเป็นไปได้นี้ในโพสต์ดั้งเดิมของฉันเพราะองค์กรที่ควบคุมระเบียน A เหล่านี้เป็น บริษัท ที่มีข้อกำหนดด้านความปลอดภัย / การปฏิบัติตามข้อกำหนด สำหรับบันทึกเหล่านี้จะเป็นกลไกการเข้าถึงนอกวงจะไม่น่าเป็นไปได้สูงและหากบันทึกเป็นแฮ็ค OOB แล้วผลกระทบจะเป็น ... น่ากลัว

— Binky

@Blinky ยุติธรรมพอมันไม่น่าเป็นไปได้ในกรณีนี้ แต่มันเป็นไปได้ที่คนอื่น ๆ

— djsmiley2k - CoW

นี่เป็นสิ่งที่เป็นไปได้อย่างแน่นอน แต่ช่องทางด้าน DNS โดยทั่วไปแล้วจะทำกับข้อความในระเบียน TXT ไม่ใช่ในชื่อโฮสต์ นอกจากนี้ "https: //" ดูเหมือนว่ามีข้อผิดพลาดไม่ใช่ข้อความที่พิมพ์ออกมา

— Criggie