Score:0

เหตุใด AWS Route 53 / Application Load Balancer จึงแก้ไขโดเมนย่อยหลายระดับ

ธง ru

ภายใน AWS ฉันยกเลิก TLS ที่ Application Load Balancer ฉันได้กำหนดค่าใบรับรอง TLS แบบไวด์การ์ดด้วย AWS' Certificate Manager (ACM) เช่น *.example.com. ฉันมีการแก้ไข AWS Route 53 *.example.comแต่ฉันไม่มีอะไรให้ *.*.example.com เพราะฉันไม่ต้องการสิ่งนี้

ฉันรู้ว่าคุณไม่สามารถกำหนดค่าใบรับรองตัวแทนสำหรับโดเมนหลายระดับ เช่น *.*.example.com.

https://x.example.com ทุกอย่างดีและตอบกลับพร้อมใบรับรองที่ถูกต้อง ฉันได้รับข้อผิดพลาดใบรับรองด้วย https://y.x.example.comซึ่งสมเหตุสมผล ฉันไม่จำเป็นต้องให้บริการโดเมนย่อยหลายระดับเช่น *.*.example.com.

ฉันต้องการบล็อกคำขอโดเมนหลายระดับทั้งหมด เช่น https://y.x.example.com หรือไม่มีการแก้ไขเส้นทาง 53 โดยทั่วไปฉันต้องการกฎที่ระบุว่าโฮสต์ใด ๆ สำหรับ https://*.*.example.com ส่งคืน 404 หรือสำหรับโฮสต์ที่จะไม่ได้รับการแก้ไข

ในโหลดบาลานเซอร์ของแอปพลิเคชัน ฉันมีตัวฟัง 2 ตัวพอร์ต 80 และพอร์ต 443

ฉันสามารถกำหนดค่ากฎสำหรับผู้ฟังพอร์ต 80 ซึ่งทำงานได้ดี http://x.y.example.com และฉันสามารถส่งคืน 404 ได้ เมื่อฉันกำหนดค่ากฎเดียวกันสำหรับพอร์ต 443 มันใช้งานไม่ได้ ซึ่งฉันคิดว่าเหมาะสมเพราะเบราว์เซอร์ไม่สามารถจับมือ TLS ได้

ถ้าฉันกรอก nslookup สำหรับ x.example.com และ y.x.example.com ฉันได้รับ NameServers เดียวกัน ฉันไม่คิดว่า Route 53 จะแก้ปัญหาได้ y.x.example.com.

ดังนั้น ฉันกำลังมองหาคำตอบสำหรับหนึ่งในสองคำถาม:

  1. จะกำหนดค่า AWS Load Balancer ให้บล็อกโดเมนย่อยหลายระดับไวด์การ์ดทั้งหมดบนพอร์ต 443 ได้อย่างไร
  2. เหตุใดเส้นทาง 53 จึงได้รับการแก้ไข y.x.example.com/ จะหยุดเส้นทาง 53 ที่แก้ไขเหมือนเดิมได้อย่างไร
Score:0
ธง cn
  1. หากสิ่งนี้เกี่ยวกับกรณี HTTPS/TLS โดยเฉพาะ ฉันไม่เห็นว่าสิ่งนี้เป็นไปได้ในทางที่มีความหมาย
    หากคุณไม่มีใบรับรองที่ถูกต้องสำหรับชื่อที่ไคลเอนต์พยายามเชื่อมต่อด้วย แสดงว่าคุณไม่มีทางส่งการตอบกลับที่ถูกต้อง (เช่น การตอบกลับ 404 ที่กล่าวถึงในคำถาม) ในตอนแรก โดยไม่คำนึงถึงการกำหนดค่า ทางฝั่งเซิร์ฟเวอร์
    สำหรับกรณี HTTP ธรรมดา อาจเป็นไปได้ที่จะทำสิ่งที่ต้องการตาม สภาพโฮสต์แต่ฉันไม่แน่ใจว่าจริง ๆ แล้วสามารถแยกความแตกต่างของกรณีระดับเดียวกับหลายระดับได้ ฉันไม่แน่ใจว่ากรณี HTTP ธรรมดานั้นน่าสนใจในทุกวันนี้

  2. นี่คือวิธีการทำงานของไวด์การ์ดใน DNS การค้นหาชื่อ DNS ที่ไม่ได้เป็นส่วนหนึ่งของสาขาที่มีอยู่ของต้นไม้ (ไม่ว่าจะมีป้ายชื่อใดหายไปหนึ่งป้ายหรือมากกว่านั้น) จะตรงกับระเบียนตัวแทนด้านบน
    นอกจากนี้ยังเป็นที่น่าสังเกตว่า * ทำงานเป็นสัญลักษณ์แทนเมื่อเป็นป้ายกำกับด้านซ้ายสุดเท่านั้น *.example.com ทำงานเป็นสัญลักษณ์แทน *.foo.example.com ทำงานเป็นสัญลักษณ์แทน แต่ ฟู.*.example.com, foo*.example.com หรือ *foo.example.com ไม่ใช่สัญลักษณ์แทนใน DNS
    ฉันไม่เชื่อว่าคุณมีวิธีใช้ไวด์การ์ดที่ใช้งานได้จริงในขณะที่รับฟังก์ชัน "เพียงระดับเดียว" ที่คุณต้องการ (โดยใช้ไวด์การ์ด DNS โดยทั่วไปหรือเฉพาะ Route53) ให้พิจารณาเพิ่มชื่อเฉพาะที่คุณต้องการจริงๆ แทน (ไดนามิกถ้าจำเป็น) หรือใช้ลักษณะการทำงานของสัญลักษณ์แทนตามปกติ

โดยรวมแล้ว ฉันสงสัยว่าตัวเลือกที่ดีที่สุดคือการไม่ใช้สัญลักษณ์แทนใน DNS และจากนั้นจะไม่มีปัญหาไคลเอ็นต์เชื่อมต่อกับ ELB โดยใช้ชื่อที่ไม่ต้องการเหล่านี้

Patrick Mevzek avatar
cn flag
+1 บน "ตัวเลือกที่ดีที่สุดคือการไม่ใช้สัญลักษณ์แทนใน DNS" พวกเขามักจะสร้างปัญหามากกว่าการแก้ปัญหา พวกเขาถูกสร้างขึ้นในช่วงเวลาที่ DNS เป็นเพียงไฟล์ข้อความโดยไม่มีระบบอัตโนมัติหรือเครื่องมือจัดเตรียมใดๆ ปัจจุบันมีความเป็นไปได้อื่น ๆ อีกมากมายในการกำหนดค่าเนมเซิร์ฟเวอร์ "ไดนามิก" โดยไม่ต้องพึ่งพาสัญลักษณ์แทน สามารถใช้สัญลักษณ์แทนได้หากเข้าใจถูกต้อง แน่นอนว่ามีการอธิบายไว้อย่างครบถ้วน แต่พวกเขาทำให้ทุกอย่างซับซ้อนขึ้น โดยเริ่มจาก DNSSEC

โพสต์คำตอบ

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