Sau hai năm phát triển, tập đoàn ISC đã phát hành bản phát hành ổn định đầu tiên của nhánh mới quan trọng của máy chủ DNS BIND 9.18. Hỗ trợ cho nhánh 9.18 sẽ được cung cấp trong ba năm cho đến quý 2 năm 2025 như một phần của chu kỳ hỗ trợ mở rộng. Hỗ trợ cho nhánh 9.11 sẽ kết thúc vào tháng 9.16 và hỗ trợ cho nhánh 2023 vào giữa năm 9.19.0. Để phát triển chức năng của phiên bản ổn định tiếp theo của BIND, nhánh thử nghiệm BIND XNUMX đã được hình thành.
Việc phát hành BIND 9.18.0 đáng chú ý là việc triển khai hỗ trợ DNS qua HTTPS (DoH, DNS qua HTTPS) và DNS qua TLS (DoT, DNS qua TLS), cũng như cơ chế XoT (XFR-over-TLS) để truyền an toàn các vùng nội dung DNS giữa các máy chủ (cả vùng gửi và nhận qua XoT đều được hỗ trợ). Với các cài đặt thích hợp, một quy trình được đặt tên giờ đây không chỉ có thể phục vụ các truy vấn DNS truyền thống mà còn cả các truy vấn được gửi bằng DNS-over-HTTPS và DNS-over-TLS. Hỗ trợ máy khách cho DNS-over-TLS được tích hợp vào tiện ích dig, tiện ích này có thể được sử dụng để gửi yêu cầu qua TLS khi cờ "+tls" được chỉ định.
Việc triển khai giao thức HTTP/2 được sử dụng trong DoH dựa trên việc sử dụng thư viện nghttp2, được bao gồm dưới dạng phụ thuộc hợp ngữ tùy chọn. Chứng chỉ cho DoH và DoT có thể được người dùng cung cấp hoặc được tạo tự động khi khởi động.
Việc xử lý yêu cầu bằng DoH và DoT được bật bằng cách thêm tùy chọn "http" và "tls" vào lệnh lắng nghe. Để hỗ trợ DNS-over-HTTP không được mã hóa, bạn nên chỉ định “tls none” trong cài đặt. Các khóa được xác định trong phần "tls". Các cổng mạng mặc định 853 cho DoT, 443 cho DoH và 80 cho DNS-over-HTTP có thể bị ghi đè thông qua các tham số tls-port, https-port và http-port. Ví dụ:
tls local-tls { key-file "/path/to/priv_key.pem"; tệp chứng chỉ "/path/to/cert_chain.pem"; }; http local-http-server { điểm cuối { "/dns-query"; }; }; tùy chọn {https-port 443; cổng nghe 443 tls local-tls http myserver {any;}; }
Một trong những tính năng của việc triển khai DoH trong BIND là khả năng di chuyển các hoạt động mã hóa cho TLS sang một máy chủ khác, điều này có thể cần thiết trong điều kiện chứng chỉ TLS được lưu trữ trên một hệ thống khác (ví dụ: trong cơ sở hạ tầng có máy chủ web) và được duy trì. bởi nhân sự khác. Hỗ trợ DNS-over-HTTP không được mã hóa được triển khai để đơn giản hóa việc gỡ lỗi và như một lớp để chuyển tiếp đến một máy chủ khác trên mạng nội bộ (để chuyển mã hóa sang một máy chủ riêng). Trên máy chủ từ xa, nginx có thể được sử dụng để tạo lưu lượng TLS, tương tự như cách tổ chức liên kết HTTPS cho các trang web.
Một tính năng khác là tích hợp DoH như một phương tiện truyền tải chung có thể được sử dụng không chỉ để xử lý các yêu cầu của máy khách tới trình phân giải mà còn khi liên lạc giữa các máy chủ, khi chuyển vùng bằng máy chủ DNS có thẩm quyền và khi xử lý bất kỳ truy vấn nào được hỗ trợ bởi DNS khác. vận chuyển.
Trong số những thiếu sót có thể được bù đắp bằng cách vô hiệu hóa bản dựng bằng DoH/DoT hoặc di chuyển mã hóa sang máy chủ khác, sự phức tạp chung của cơ sở mã nổi bật - một máy chủ HTTP và thư viện TLS tích hợp được thêm vào, có khả năng chứa các lỗ hổng và hoạt động như các vectơ bổ sung cho các cuộc tấn công. Ngoài ra, khi sử dụng DoH, lưu lượng truy cập sẽ tăng lên.
Chúng ta hãy nhớ lại rằng DNS-over-HTTPS có thể hữu ích trong việc ngăn chặn rò rỉ thông tin về tên máy chủ được yêu cầu thông qua máy chủ DNS của nhà cung cấp, chống lại các cuộc tấn công MITM và giả mạo lưu lượng DNS (ví dụ: khi kết nối với Wi-Fi công cộng), chống lại chặn ở cấp độ DNS (DNS-over-HTTPS không thể thay thế VPN trong việc bỏ qua tính năng chặn được triển khai ở cấp độ dpi) hoặc để tổ chức công việc khi không thể truy cập trực tiếp vào máy chủ DNS (ví dụ: khi làm việc thông qua proxy). Nếu trong tình huống bình thường, các yêu cầu DNS được gửi trực tiếp đến các máy chủ DNS được xác định trong cấu hình hệ thống thì trong trường hợp DNS-over-HTTPS, yêu cầu xác định địa chỉ IP máy chủ sẽ được gói gọn trong lưu lượng HTTPS và được gửi đến máy chủ HTTP, trong đó trình phân giải xử lý các yêu cầu thông qua API Web.
“DNS over TLS” khác với “DNS over HTTPS” ở việc sử dụng giao thức DNS tiêu chuẩn (cổng mạng 853 thường được sử dụng), được bao bọc trong một kênh liên lạc được mã hóa được tổ chức bằng giao thức TLS với tính năng kiểm tra tính hợp lệ của máy chủ thông qua chứng chỉ TLS/SSL được chứng nhận bởi cơ quan chứng nhận. Tiêu chuẩn DNSSEC hiện tại chỉ sử dụng mã hóa để xác thực máy khách và máy chủ nhưng không bảo vệ lưu lượng truy cập khỏi bị chặn và không đảm bảo tính bảo mật của các yêu cầu.
Một số cải tiến khác:
- Đã thêm cài đặt tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer và udp-send-buffer để đặt kích thước của bộ đệm được sử dụng khi gửi và nhận yêu cầu qua TCP và UDP. Trên các máy chủ bận rộn, việc tăng bộ đệm đến sẽ giúp tránh các gói bị rớt trong thời gian lưu lượng truy cập cao điểm và việc giảm chúng sẽ giúp loại bỏ tình trạng tắc nghẽn bộ nhớ do các yêu cầu cũ.
- Một danh mục nhật ký mới “rpz-passthru” đã được thêm vào, cho phép bạn ghi nhật ký riêng các hành động chuyển tiếp RPZ (Vùng chính sách phản hồi).
- Trong phần chính sách phản hồi, tùy chọn “nsdname-wait-recurse” đã được thêm vào, khi được đặt thành “không”, quy tắc RPZ NSDNAME chỉ được áp dụng nếu tìm thấy máy chủ tên có thẩm quyền có trong bộ đệm cho yêu cầu, nếu không thì Quy tắc RPZ NSDNAME bị bỏ qua nhưng thông tin được truy xuất ở chế độ nền và áp dụng cho các yêu cầu tiếp theo.
- Đối với các bản ghi có loại HTTPS và SVCB, việc xử lý phần “THÊM” đã được triển khai.
- Đã thêm các loại quy tắc chính sách cập nhật tùy chỉnh - krb5-subdomain-self-rhs và ms-subdomain-self-rhs, cho phép bạn giới hạn cập nhật bản ghi SRV và PTR. Các khối chính sách cập nhật cũng bổ sung thêm khả năng đặt giới hạn về số lượng bản ghi, riêng lẻ cho từng loại.
- Đã thêm thông tin về tiền tố giao thức truyền tải (UDP, TCP, TLS, HTTPS) và DNS64 vào đầu ra của tiện ích đào. Với mục đích gỡ lỗi, dig đã thêm khả năng chỉ định một mã định danh yêu cầu cụ thể (dig +qid= ).
- Đã thêm hỗ trợ cho thư viện OpenSSL 3.0.
- Để giải quyết các vấn đề về phân mảnh IP khi xử lý các thông báo DNS lớn được xác định bởi Ngày gắn cờ DNS 2020, mã điều chỉnh kích thước bộ đệm EDNS khi không có phản hồi cho yêu cầu đã bị xóa khỏi trình phân giải. Kích thước bộ đệm EDNS hiện được đặt thành không đổi (edns-udp-size) cho tất cả các yêu cầu gửi đi.
- Hệ thống xây dựng đã được chuyển sang sử dụng kết hợp autoconf, automake và libtool.
- Hỗ trợ cho các tệp vùng ở định dạng “bản đồ” (bản đồ định dạng masterfile) đã bị ngừng. Người dùng định dạng này được khuyến nghị chuyển đổi vùng sang định dạng thô bằng cách sử dụng tiện ích có tên-compilezone.
- Hỗ trợ cho trình điều khiển DLZ (Vùng có thể tải động) cũ hơn đã bị ngừng, được thay thế bằng các mô-đun DLZ.
- Hỗ trợ xây dựng và chạy cho nền tảng Windows đã bị ngừng. Nhánh cuối cùng có thể cài đặt trên Windows là BIND 9.16.
Nguồn: opennet.ru