Các truy vấn DNS luôn đi qua UDP?

Tôi đã dành một chút thời gian để nghiên cứu chủ đề này và dường như không thể tìm thấy câu trả lời chính xác, vì vậy tôi khá tự tin rằng nó không phải là một bản sao và trong khi câu hỏi của tôi dựa trên nhu cầu bảo mật, tôi nghĩ nó vẫn an toàn để hỏi ở đây nhưng cho tôi biết nếu tôi cần di chuyển nó vào cộng đồng bảo mật.

Về cơ bản, các truy vấn DNS có bao giờ sử dụng TCP không (nếu vậy, kịch bản này có thể xảy ra)? Một lần nữa, tôi chỉ nói về các truy vấn. Có thể cho họ đi qua TCP? Nếu các tên miền chỉ có thể có độ dài tối đa là 253 byte và các gói UDP có thể lớn tới 512 byte, thì các truy vấn sẽ không đi ra ngoài như UDP? Tôi không nghĩ rằng một truy vấn có thể giải quyết có thể đủ lớn để yêu cầu sử dụng TCP. Nếu một máy chủ DNS từng có một yêu cầu cho một tên miền lớn hơn 253 byte, thì máy chủ đó có bỏ nó / không thử và giải quyết nó không? Tôi chắc chắn tôi đã đưa ra một số giả định sai ở đây.

Đối với một số bối cảnh, tôi đang làm việc với nhóm bảo mật để đưa các truy vấn DNS vào công cụ giám sát bảo mật của họ và vì nhiều lý do khác nhau, chúng tôi đã quyết định chúng tôi sẽ nắm bắt lưu lượng này thông qua việc bắt gói tin tiêu chuẩn trên máy chủ DNS và bộ điều khiển miền. Yêu cầu cốt lõi là nắm bắt tất cả các truy vấn DNS để họ có thể xác định ứng dụng khách nào đã cố gắng giải quyết bất kỳ miền nào. Dựa trên yêu cầu này, chúng tôi không quan tâm đến việc nắm bắt phản hồi DNS hoặc lưu lượng truy cập khác như chuyển vùng, điều này cũng được thúc đẩy bởi thực tế là chúng tôi cần hạn chế khối lượng nhật ký càng nhiều càng tốt. Do đó, chúng tôi dự định chỉ thu thập các truy vấn DNS dành cho máy chủ DNS và được gửi qua UDP. Để biết thêm ngữ cảnh (loại phạm vi câu hỏi leo ở đây), giờ đây chúng ta có thể cần phải mở rộng bảo mật ' Khả năng hiển thị để họ có thể theo dõi hoạt động như các kênh bí mật chạy trên DNS (điều này cũng sẽ cần phải nắm bắt các phản hồi DNS và sau đó là lưu lượng TCP). Nhưng ngay cả trong loại kịch bản đó, tôi đã nghĩ rằng bất kỳ lưu lượng DNS bên ngoài nào sẽ ở dạng tra cứu / truy vấn và chúng sẽ luôn vượt qua UDP, ngay cả khi từ một nguồn độc hại (vì lý do của tôi trong đoạn đầu tiên). Vì vậy, điều này đưa ra một số câu hỏi bổ sung:

• Tối thiểu chúng ta có thể nắm bắt được một nửa cuộc trò chuyện với cách tiếp cận tôi đã vạch ra không? Hoặc khách hàng có bao giờ gửi lưu lượng DNS không ở dạng truy vấn không? (có thể giống như một số loại trả lời cho phản hồi của máy chủ DNS và có thể kết thúc bằng TCP)

• Các truy vấn DNS có thể được sửa đổi để sử dụng TCP không? Máy chủ DNS có chấp nhận và trả lời truy vấn DNS qua TCP không?

Không chắc nó có liên quan hay không, nhưng chúng tôi giới hạn các yêu cầu DNS đối với các máy chủ DNS được ủy quyền và chặn tất cả lưu lượng truy cập khác ra ngoài cổng 53. Tôi chắc chắn là một tân binh, vì vậy tôi xin lỗi nếu câu hỏi của tôi không tuân thủ và cho tôi biết Làm thế nào tôi nên sửa đổi.

Các truy vấn DNS thông thường sử dụng cổng UDP 53, nhưng các truy vấn dài hơn (> 512 octet) sẽ nhận được câu trả lời 'cắt ngắn', dẫn đến một cuộc trò chuyện TCP 53 để tạo điều kiện gửi / nhận toàn bộ truy vấn. Ngoài ra, máy chủ DNS liên kết với cổng 53, nhưng bản thân truy vấn bắt nguồn từ một cổng được đánh số cao ngẫu nhiên (49152 trở lên) được gửi đến cổng 53. Phản hồi sẽ được trả về cùng cổng này từ cổng 53.

Cổng mạng được sử dụng bởi DNS | Tài liệu Microsoft

Vì vậy, nếu bạn dự định thực hiện một số bảo mật rình mò các truy vấn DNS từ mạng của mình, bạn sẽ cần tính đến những điều trên.

Đối với lưu lượng truy cập không tra cứu, hãy xem xét rằng DNS cũng sử dụng chuyển vùng (loại truy vấn AXFR) để cập nhật các máy chủ DNS khác với các bản ghi mới. Một người đàn ông trong cuộc tấn công ở giữa có thể bắt đầu bằng một lần chuyển như vậy, DDOS là một máy chủ tên Chính để quá bận rộn để trả lời Phụ yêu cầu hồ sơ cập nhật. Sau đó, tin tặc giả mạo chính đó để cung cấp các bản ghi 'bị đầu độc' cho Trung học, chuyển hướng các tên miền DNS phổ biến đến các máy chủ bị xâm nhập.

Vì vậy, kiểm toán bảo mật của bạn nên chú ý đến loại truy vấn AXFR và hệ thống DNS của bạn chỉ nên chấp nhận trao đổi AXFR từ các địa chỉ IP cụ thể.

Học viện Sans Phòng đọc sách | sans.org

Điều này bắt đầu như một bình luận cho câu trả lời của George, nhưng nó đã dài. Bức tranh lớn hơn có phần phức tạp, vì nó đòi hỏi phải hiểu một số lịch sử.

• RFC 1035 ban đầu yêu cầu giới hạn 512 byte để tránh phân mảnh UDP. Các datagram UDP bị phân mảnh và TCP được chọn làm tùy chọn của phương sách cuối cùng để giảm thiểu chi phí hoạt động của các giao dịch DNS. Chuyển vùng luôn sử dụng TCP, do chuyển vùng chiếm tới> 512 byte theo bản chất của chúng. (sẽ rất lãng phí băng thông khi bắt đầu với UDP)

• TCP thử lại khi cắt ngắn được hỗ trợ rộng rãi vì nó đã được chỉ định trong RFC 1123 kể từ năm 1989.

• EDNS (0) được xác định bởi RFC 6891 (2013) và trước đó tồn tại dưới dạng Tiêu chuẩn đề xuất có từ năm 1999 . Nó xác định một cơ chế trong đó máy khách và máy chủ có thể thương lượng kích thước UDP lớn hơn 512. Do tính mới của EDNS (0), nhiều thiết bị phần cứng đưa ra các giả định về cấu trúc của các gói DNS khiến các gói tuân thủ bị loại bỏ. Lý do thường gặp nhất là một giả định rằng các thông điệp DNS trên 512 byte là không hợp lệ, nhưng đây là một trong số đó.

Nếu chúng ta phá vỡ điều đó thành các hành vi được quan sát:

1. Truy vấn DNS thường bắt đầu dưới dạng UDP, trừ khi được biết trước rằng câu trả lời sẽ quá lớn để bắt đầu. (chuyển vùng)
2. Trả lời có thể kích hoạt thử lại TCP trong máy khách nếu thấy câu trả lời bị cắt ngắn. Điều này được hỗ trợ khá tốt.
3. Có thể thấy phản hồi UDP lớn hơn 512 byte nếu máy khách sử dụng EDNS (0) để quảng cáo tải trọng lớn hơn và máy chủ nhận hỗ trợ. Điều này sẽ chỉ xảy ra nếu phần cứng ngồi giữa cả hai không can thiệp và dẫn đến một gói bị rơi hoặc bị xáo trộn.
4. Khách hàng có thể chọn thử lại một truy vấn EDNS (0) với tải trọng được quảng cáo nhỏ hơn nếu không thấy câu trả lời, nhưng chi tiết cụ thể sẽ khác nhau giữa các lần triển khai.
   • Điều quan trọng cần lưu ý là câu trả lời cuối cùng có thể quá lớn để phù hợp với kích thước được yêu cầu, dẫn đến hành vi # 2 ở trên. (bạn đã thử lại TCP)
   • Phía khách hàng có thể chọn ghi nhớ kích thước cuối cùng dẫn đến thành công. Điều này cho phép nó tránh lãng phí các truy vấn không cần thiết thăm dò lại. Để làm khác sẽ khá lãng phí, đặc biệt nếu kết quả cuối cùng yêu cầu dự phòng TCP.

Bạn cũng nên nhớ rằng RFC 7766 cho phép tái sử dụng kết nối qua TCP và có thể gặp phải đường ống truy vấn trên TCP trong tự nhiên. Một số công cụ không phát hiện các truy vấn DNS ngoài lần đầu tiên nhìn thấy trong phiên TCP, dnscap là một ví dụ về điều đó.

Có là RFC 7766, Giao thông vận tải DNS trên TCP - Yêu cầu thực hiện .

1. Giới thiệu

Hầu hết các giao dịch DNS [ RFC1034 ] diễn ra trên UDP [ RFC768 ]. TCP [ RFC793 ] luôn được sử dụng để chuyển toàn bộ khu vực (sử dụng AXFR) và thường được sử dụng cho các thư có kích thước vượt quá giới hạn 512 byte ban đầu của giao thức DNS. Việc triển khai ngày càng tăng của Bảo mật DNS (DNSSEC) và IPv6 đã tăng kích thước phản hồi và do đó sử dụng TCP. Nhu cầu sử dụng TCP tăng lên cũng được thúc đẩy bởi sự bảo vệ mà nó cung cấp chống lại việc giả mạo địa chỉ và do đó khai thác DNS trong các cuộc tấn công phản xạ / khuếch đại. Hiện tại nó được sử dụng rộng rãi trong Giới hạn tỷ lệ phản hồi [ RRL1 ] [ RRL2 ]. Ngoài ra, công việc gần đây về các giải pháp bảo mật DNS, chẳng hạn như [ DNS-over-TLS] là một động lực khác để xem xét lại các yêu cầu DNS-over-TCP.

Mục 6.1.3.2 của [RFC1123] nêu:

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

Tuy nhiên, một số người triển khai đã lấy văn bản được trích dẫn ở trên để có nghĩa là hỗ trợ TCP là một tính năng tùy chọn của giao thức DNS.

Phần lớn các nhà khai thác máy chủ DNS đã hỗ trợ TCP và cấu hình mặc định cho hầu hết các cài đặt phần mềm là hỗ trợ TCP. Đối tượng chính của tài liệu này là những người triển khai có hỗ trợ hạn chế cho TCP hạn chế khả năng tương tác và cản trở việc triển khai các tính năng DNS mới.

Do đó, tài liệu này cập nhật các thông số kỹ thuật giao thức DNS cốt lõi để hỗ trợ cho TCP từ đó trở thành một phần BẮT BUỘC của việc thực hiện giao thức DNS đầy đủ.

Có một số ưu điểm và nhược điểm đối với việc tăng cường sử dụng TCP (xem Phụ lục A ) cũng như các chi tiết triển khai cần được xem xét. Tài liệu này giải quyết các vấn đề này và trình bày TCP như một phương án vận chuyển hợp lệ cho DNS. Nó mở rộng nội dung của [ RFC5966 ], với những cân nhắc và bài học kinh nghiệm bổ sung từ nghiên cứu, phát triển và triển khai TCP trong DNS và trong các giao thức Internet khác.

Mặc dù tài liệu này không đáp ứng các yêu cầu cụ thể cho các nhà khai thác máy chủ DNS, nhưng nó đưa ra một số gợi ý cho các nhà khai thác để giúp đảm bảo rằng hỗ trợ TCP trên máy chủ và mạng của họ là tối ưu. Cần lưu ý rằng việc không hỗ trợ TCP (hoặc chặn DNS qua TCP ở lớp mạng) có thể dẫn đến lỗi độ phân giải và / hoặc hết thời gian chờ ở cấp ứng dụng.

Bạn không nên lọc TCP / 53 theo bất kỳ hướng nào. Ví dụ: nsupdatecác truy vấn có thể sử dụng TCP ngay khi yêu cầu quá lớn (có thể xảy ra nhanh). Vì vậy, bạn nên để UDP và TCP cho cổng 53 (trong IPv4 & V6!) Lưu chuyển theo mọi hướng.

Ngoài ra, ngày càng có nhiều công việc hơn đối với DNS qua TLS, do đó TCP sẽ cần thiết theo cả hai hướng. Xem RFC7858.