Điểm:0

Tại sao AWS Route 53 / Bộ cân bằng tải ứng dụng phân giải một miền phụ đa cấp

lá cờ ru

Trong AWS, tôi chấm dứt TLS tại Bộ cân bằng tải ứng dụng. Tôi đã định cấu hình chứng chỉ TLS ký tự đại diện với Trình quản lý chứng chỉ (ACM) của AWS, ví dụ: *.example.com. Tôi đang giải quyết AWS Route 53 *.example.com, nhưng tôi không có gì cho *.*.example.com vì tôi không có nhu cầu này.

Tôi biết bạn không thể định cấu hình chứng chỉ ký tự đại diện cho các miền đa cấp, chẳng hạn như *.*.example.com.

https://x.example.com tất cả đều tốt và đáp ứng với một chứng chỉ hợp lệ. Tôi gặp lỗi chứng chỉ với https://y.x.example.com, điều đó có ý nghĩa. Tôi không có nhu cầu phục vụ các tên miền phụ đa cấp như *.*.example.com.

Tôi muốn có thể chặn tất cả các yêu cầu tên miền đa cấp, chẳng hạn như https://y.x.example.com hoặc chỉ là không giải quyết được Tuyến đường 53. Về cơ bản, tôi muốn một Quy tắc cho biết bất kỳ máy chủ nào dành cho https://*.*.example.com trả lại 404 hoặc cho Máy chủ không được giải quyết.

Trong bộ cân bằng tải ứng dụng, tôi có 2 cổng nghe 80 và cổng 443.

Tôi có thể định cấu hình quy tắc cho trình nghe cổng 80 hoạt động tốt cho http://x.y.example.com và tôi có thể trả về 404, khi tôi định cấu hình quy tắc tương tự cho cổng 443 thì nó không hoạt động. Tôi đoán điều này có ý nghĩa vì trình duyệt không thể hoàn tất quá trình bắt tay TLS.

Nếu tôi hoàn thành một nslookupx.example.comy.x.example.com Tôi nhận được cùng một Máy chủ định danh, tôi sẽ không mong đợi Tuyến đường 53 sẽ giải quyết y.x.example.com.

Vì vậy, tôi đang tìm kiếm câu trả lời cho một trong hai câu hỏi:

  1. Làm cách nào để định cấu hình Bộ cân bằng tải AWS để chặn tất cả các miền phụ đa cấp ký tự đại diện trên Cổng 443?
  2. Tại sao Route 53 được giải quyết y.x.example.com/ làm thế nào để dừng Tuyến 53 giải quyết như vậy?
Điểm:0
lá cờ cn
  1. Nếu đây là về trường hợp HTTPS/TLS cụ thể, tôi không thấy điều này có thể xảy ra theo bất kỳ cách có ý nghĩa nào.
    Nếu bạn không có chứng chỉ hợp lệ cho tên mà ứng dụng khách đang cố kết nối, thì bạn không có phương tiện để gửi phản hồi hợp lệ (như phản hồi 404 được đề cập trong câu hỏi) ngay từ đầu, bất kể cấu hình ở phía máy chủ.
    Đối với trường hợp HTTP đơn giản, có thể thực hiện điều gì đó giống như những gì được yêu cầu dựa trên điều kiện máy chủ, nhưng tôi không chắc rằng thực sự có thể phân biệt trường hợp đơn cấp và đa cấp ở đó hay không. Tuy nhiên, tôi không chắc rằng trường hợp HTTP đơn giản ngày nay có thú vị hay không.

  2. Đây là cách các ký tự đại diện hoạt động trong DNS. Tra cứu tên DNS không phải là một phần của nhánh hiện có của cây (bất kể có thiếu một hoặc nhiều nhãn hay không) sẽ khớp với bản ghi ký tự đại diện phía trên nó.
    Cũng cần lưu ý rằng * chỉ hoạt động như một ký tự đại diện khi nó là nhãn ngoài cùng bên trái. *.example.com hoạt động như một ký tự đại diện, *.foo.example.com hoạt động như một ký tự đại diện, nhưng foo.*.example.com, foo*.example.com hoặc * foo.example.com không phải là ký tự đại diện trong DNS.
    Tôi không tin rằng bạn có một cách thực tế để sử dụng ký tự đại diện trong khi nhận được chức năng "chỉ một cấp" mà bạn đang yêu cầu (với ký tự đại diện DNS nói chung hoặc cụ thể là Route53). Thay vào đó, hãy cân nhắc việc thêm các tên cụ thể mà bạn thực sự cần (tự động nếu cần) hoặc sống với hành vi ký tự đại diện thông thường.

Nhìn chung, tôi nghi ngờ rằng tùy chọn tốt nhất là không sử dụng ký tự đại diện trong DNS và khi đó sẽ không gặp sự cố máy khách kết nối với ELB bằng các tên không mong muốn này.

Patrick Mevzek avatar
lá cờ cn
+1 trên "tùy chọn tốt nhất là không sử dụng ký tự đại diện trong DNS". Họ thường tạo ra nhiều vấn đề hơn là giải pháp. Chúng được tạo vào thời điểm mà DNS chỉ là các tệp văn bản mà không có bất kỳ loại công cụ cung cấp hoặc tự động hóa nào. Ngày nay, có nhiều khả năng khác để định cấu hình máy chủ tên "động" mà không cần phải dựa vào ký tự đại diện. Ký tự đại diện có thể được sử dụng, nếu hiểu đúng, tất nhiên, chúng được mô tả đầy đủ. Tuy nhiên, họ làm cho mọi thứ trở nên phức tạp hơn, bắt đầu với DNSSEC.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.