Sáng kiến ​​Ngày cờ DNS 2020 nhằm giải quyết các vấn đề phân mảnh và hỗ trợ TCP

Hôm nay, một số nhà sản xuất dịch vụ DNS và máy chủ DNS lớn sẽ tổ chức một sự kiện chung Ngày cờ DNS 2020được thiết kế để tập trung sự chú ý vào quyết định vấn đề bị phân mảnh IP khi xử lý các tin nhắn DNS lớn. Đây là sự kiện thứ hai như vậy, vào năm ngoái “Ngày cờ DNS” đã được tập trung về việc xử lý chính xác các yêu cầu EDNS.

Những người tham gia sáng kiến ​​Ngày cờ DNS năm 2020 đang kêu gọi cố định kích thước bộ đệm được đề xuất cho EDNS ở mức 1232 byte (kích thước MTU 1280 trừ đi 48 byte cho tiêu đề), cũng như dịch xử lý yêu cầu qua TCP là một tính năng bắt buộc phải có trên máy chủ. TRONG RFC 1035 Chỉ hỗ trợ xử lý yêu cầu qua UDP được đánh dấu là bắt buộc và TCP được liệt kê là mong muốn nhưng không bắt buộc để hoạt động. Mới RFC 7766 и RFC 5966 liệt kê rõ ràng TCP là khả năng cần thiết để DNS hoạt động chính xác. Sáng kiến ​​này đề xuất buộc chuyển đổi từ gửi yêu cầu qua UDP sang sử dụng TCP trong trường hợp kích thước bộ đệm EDNS đã thiết lập không đủ.

Những thay đổi được đề xuất sẽ loại bỏ sự nhầm lẫn khi chọn kích thước bộ đệm EDNS và giải quyết vấn đề phân mảnh các tin nhắn UDP lớn, việc xử lý chúng thường dẫn đến mất gói và hết thời gian chờ ở phía máy khách. Về phía máy khách, kích thước bộ đệm EDNS sẽ không đổi và các phản hồi lớn sẽ được gửi ngay lập tức đến máy khách qua TCP. Việc tránh gửi các tin nhắn lớn qua UDP cũng sẽ giải quyết được vấn đề với các gói tin lớn bị loại bỏ trên một số tường lửa và cho phép chặn các cuộc tấn công để đầu độc bộ đệm DNS, dựa trên thao tác của các gói UDP bị phân mảnh (khi chia thành các đoạn, đoạn thứ hai không bao gồm tiêu đề có mã định danh, do đó nó có thể bị giả mạo, chỉ cần tổng kiểm tra khớp là đủ) .

Bắt đầu từ hôm nay, các nhà cung cấp DNS tham gia bao gồm CloudFlare, Quad 9, Cisco (OpenDNS) và Google, sẽ dần thay đổi Kích thước bộ đệm EDNS từ 4096 đến 1232 byte trên các máy chủ DNS của nó (sự thay đổi EDNS sẽ diễn ra trong vòng 4-6 tuần và sẽ đáp ứng số lượng yêu cầu ngày càng tăng theo thời gian). Phản hồi đối với các yêu cầu UDP không phù hợp với giới hạn mới sẽ được gửi qua TCP. Các nhà cung cấp máy chủ DNS bao gồm BIND, Unbound, Knot, NSD và PowerDNS sẽ phát hành bản cập nhật để thay đổi kích thước bộ đệm EDNS mặc định từ 4096 byte thành 1232 byte.

Cuối cùng, những thay đổi này có thể dẫn đến sự cố về độ phân giải khi truy cập máy chủ DNS có phản hồi DNS UDP vượt quá 1232 byte và không thể gửi phản hồi TCP. Một thử nghiệm được thực hiện tại Google cho thấy việc thay đổi kích thước bộ đệm EDNS hầu như không ảnh hưởng đến tỷ lệ thất bại - với bộ đệm 4096 byte, số yêu cầu UDP bị cắt bớt là 0.345% và số lần thử lại không thể truy cập qua TCP là 0.115%. Với bộ đệm 1232 byte, các con số này là 0.367% và 0.116%. Việc hỗ trợ TCP trở thành một tính năng DNS bắt buộc sẽ gây ra sự cố với khoảng 0.1% máy chủ DNS. Cần lưu ý rằng trong điều kiện hiện đại, không có TCP thì hoạt động của các máy chủ này đã không ổn định.

Quản trị viên của máy chủ DNS có thẩm quyền phải đảm bảo rằng máy chủ của họ phản hồi qua TCP trên cổng mạng 53 và cổng TCP này không bị tường lửa chặn. Máy chủ DNS có uy tín cũng không nên gửi phản hồi UDP lớn hơn
kích thước bộ đệm EDNS được yêu cầu. Trên chính máy chủ, kích thước bộ đệm EDNS phải được đặt thành 1232 byte. Bộ giải quyết có các yêu cầu gần giống nhau - khả năng bắt buộc phải phản hồi qua TCP, hỗ trợ bắt buộc để gửi các yêu cầu lặp lại qua TCP khi nhận được phản hồi UDP bị cắt ngắn và đặt bộ đệm EDNS thành 1232 byte.

Các tham số sau chịu trách nhiệm thiết lập kích thước bộ đệm EDNS trong các máy chủ DNS khác nhau:

  • TRÓI BUỘC

    tùy chọn {
    edns-udp-size 1232;
    kích thước tối đa udp 1232;
    };

  • Nút thắt DNS

    tải trọng tối đa: 1232

  • Trình giải quyết nút thắt

    net.bufsize(1232)

  • PowerDNS có thẩm quyền

    udp-cắt-ngưỡng=1232

  • Bộ đệ quy PowerDNS

    edns-outending-bufsize=1232
    udp-cắt-ngưỡng=1232

  • cởi ra

    edns-kích thước bộ đệm: 1232

  • NSD

    kích thước ipv4-edns: 1232
    kích thước ipv6-edns: 1232

    Nguồn: opennet.ru

  • Thêm một lời nhận xét