RFC yêu cầu máy chủ DNS đáp ứng các yêu cầu miền không xác định

Công ty đăng ký tên miền và DNS của tôi hiện đang bỏ qua các yêu cầu DNS đến các miền không xác định. Bằng cách bỏ qua, tôi có nghĩa là các lỗ đen và không bao giờ trả lời, điều đó khiến các máy khách DNS và thư viện trình phân giải của tôi thử lại, tắt và cuối cùng là hết thời gian.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Khi khảo sát các dịch vụ tên miền phổ biến khác, tôi thấy rằng hành vi này khá độc đáo vì các nhà cung cấp khác trả lại RCODE là 5 (REFUSED):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Tất cả trả lại một cái gì đó như sau:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

hoặc là

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Trả lại REFUSEDhoặc NXDOMAINngay lập tức là IMHO thích hợp thay vì chỉ bỏ yêu cầu trên sàn phòng máy chủ.

Khi tôi phàn nàn với nhà cung cấp của mình về việc máy chủ của họ không phản hồi, họ yêu cầu tôi trích dẫn RFC rằng máy chủ của họ đang vi phạm. Tôi biết thật lạ khi họ yêu cầu tôi chứng minh rằng máy chủ của họ sẽ đáp ứng tất cả các yêu cầu nhưng cũng vậy.

Câu hỏi :

• Theo quy định của tôi, trừ khi có id yêu cầu trùng lặp hoặc một số loại phản hồi DOS, máy chủ phải luôn đáp ứng yêu cầu. Điều này có đúng không?
• RFC và phần cụ thể nào tôi nên trích dẫn để hỗ trợ quy định của tôi?

Đối với tôi, thật tệ khi không trả lời truy vấn DNS. Hầu hết các máy khách sẽ sao lưu và sau đó gửi lại cùng một truy vấn đến cùng một máy chủ DNS hoặc máy chủ khác. Họ không chỉ làm chậm máy khách mà còn khiến truy vấn tương tự được thực hiện lại bởi chính máy chủ của họ hoặc các máy chủ khác tùy thuộc vào máy chủ tên có thẩm quyền và các mục nhập NS.

Trong RFC 1536 và 2308 tôi thấy rất nhiều thông tin về bộ nhớ đệm tiêu cực vì lý do hiệu năng và để dừng truyền lại cùng một truy vấn. Vào năm 4074, tôi thấy thông tin về việc trả về câu trả lời trống với RCODE bằng 0 để khách hàng biết rằng không có thông tin ipv6 nào sẽ khiến khách hàng hỏi về RR, một ví dụ khác về phản hồi trống.

Nhưng tôi không thể tìm thấy một RFC nói rằng máy chủ DNS sẽ đáp ứng yêu cầu, có thể là do nó được ngụ ý.

Vấn đề cụ thể xảy ra khi tôi di chuyển tên miền của mình (và các bản ghi DNS được liên kết) sang máy chủ của họ hoặc X phút đầu tiên sau khi tôi đăng ký tên miền mới với dịch vụ của họ. Có một độ trễ giữa thời gian các máy chủ tên có thẩm quyền thay đổi (khá nhanh trong những ngày này) và máy chủ của họ bắt đầu phục vụ các bản ghi DNS của tôi. Trong thời gian trễ này, các máy khách DNS nghĩ rằng máy chủ của họ có thẩm quyền nhưng họ không bao giờ trả lời yêu cầu - ngay cả với a REFUSED. Tôi hiểu độ trễ là tốt nhưng tôi không đồng ý với quyết định không trả lời các yêu cầu DNS. Đối với bản ghi, tôi hiểu cách khắc phục những hạn chế này trong hệ thống của họ nhưng tôi vẫn làm việc với họ để cải thiện dịch vụ của họ để phù hợp hơn với giao thức DNS.

Cảm ơn đã giúp đỡ.

Biên tập:

Trong vài tháng sau khi đăng bài này và theo dõi với nhà cung cấp của tôi, họ đã thay đổi máy chủ của họ để trả lại NXDOMAINcho các tên miền không xác định.

Lời khuyên của Shane là chính xác. Thất bại trong việc di chuyển dữ liệu từ một máy chủ có thẩm quyền sang một máy chủ khác trước khi bắt đầu cắt bỏ là một lời mời cho ngừng hoạt động. Bất kể những gì xảy ra từ thời điểm đó trở đi, đây là một lần mất điện do người đã vung hồ sơ NS khởi xướng. Điều này giải thích tại sao nhiều người không khiếu nại với nhà cung cấp của bạn.

Điều đó nói rằng, đây vẫn là một câu hỏi thú vị để trả lời vì vậy tôi sẽ giải quyết vấn đề này.

Chức năng cơ bản của máy chủ DNS được bao phủ bởi các tài liệu RFC 1034 và RFC 1035 , được gọi chung là STD 13 . Câu trả lời phải đến từ hai RFC này, hoặc được làm rõ bởi một RFC sau này cập nhật nó.

Trước khi chúng tôi tiếp tục, có một cạm bẫy lớn ở đây ngoài phạm vi DNS cần được gọi ra: cả hai RFC này đều có trước BCP 14 (1997), tài liệu làm rõ ngôn ngữ của MAY, PHẢI, NÊN, v.v.

• Các tiêu chuẩn được soạn thảo trước khi ngôn ngữ này được chính thức hóa CÓ THỂ đã sử dụng ngôn ngữ rõ ràng, nhưng trong một số trường hợp thì không. Điều này dẫn đến việc triển khai phần mềm khác nhau, nhầm lẫn hàng loạt, v.v.
• STD 13 không may là có tội trong việc diễn giải trong một số lĩnh vực. Nếu ngôn ngữ không ổn định trên một lĩnh vực hoạt động, thường thì cần phải tìm RFC làm rõ.

Ngoài ra, hãy bắt đầu với những gì RFC 1034 §4.3.1 nói:

• Chế độ đơn giản nhất cho máy chủ là không đệ quy, vì nó có thể trả lời các truy vấn chỉ sử dụng thông tin cục bộ: phản hồi chứa lỗi, câu trả lời hoặc giới thiệu đến một số máy chủ khác "gần hơn" với câu trả lời. Tất cả các máy chủ tên phải thực hiện các truy vấn không đệ quy.

...

Nếu dịch vụ đệ quy không được yêu cầu hoặc không có sẵn, phản hồi không đệ quy sẽ là một trong những điều sau đây:

• Một lỗi tên có thẩm quyền chỉ ra rằng tên đó không tồn tại.

• Một dấu hiệu lỗi tạm thời.

• Một số kết hợp của:

  RR trả lời câu hỏi, cùng với một dấu hiệu cho biết dữ liệu đến từ một vùng hay được lưu trữ.

  Một giới thiệu đến các máy chủ tên có các khu vực gần với tổ tiên hơn tên máy chủ gửi trả lời.

• RR mà máy chủ tên cho rằng sẽ hữu ích cho người yêu cầu.

Ngôn ngữ ở đây là hợp lý vững chắc. Không có "nên", nhưng "sẽ là". Điều này có nghĩa là kết quả cuối cùng phải là 1) được xác định trong danh sách trên hoặc 2) được cho phép bởi một tài liệu sau này trên Theo dõi Tiêu chuẩn sửa đổi chức năng. Tôi không biết về bất kỳ thông báo nào như vậy tồn tại vì đã bỏ qua yêu cầu và tôi sẽ nói rằng trách nhiệm thuộc về nhà phát triển để tìm ngôn ngữ từ chối nghiên cứu.

Do vai trò thường xuyên của DNS trong các tình huống lạm dụng mạng, không thể nói rằng phần mềm máy chủ DNS không cung cấp các nút để giảm lưu lượng có chọn lọc trên sàn, về mặt kỹ thuật sẽ vi phạm điều này. Điều đó nói rằng, đây không phải là hành vi mặc định hoặc với mặc định rất bảo thủ; ví dụ về cả hai sẽ là người dùng yêu cầu phần mềm bỏ một tên cụ thể ( rpz-drop.) hoặc các ngưỡng số nhất định đang bị vượt quá (BIND's max-clients-per-query). Theo kinh nghiệm của tôi, phần mềm gần như chưa từng thay đổi hành vi mặc định cho tất cả các gói theo cách vi phạm tiêu chuẩn, trừ khi tùy chọn này là một tùy chọn tăng khả năng chịu đựng cho các sản phẩm cũ vi phạm tiêu chuẩn. Đó không phải là trường hợp tại đây.

Nói tóm lại, RFC này có thể và bị vi phạm theo quyết định của các nhà khai thác, nhưng thông thường điều này được thực hiện với một số cách chính xác. Việc bỏ qua hoàn toàn các phần của tiêu chuẩn là rất thuận tiện, đặc biệt là khi sự đồng thuận chuyên môn (ví dụ: BCP 16 §3.3 ) không có lợi cho việc tạo ra tải không cần thiết cho toàn bộ hệ thống DNS. Thử lại không cần thiết từ bỏ tất cả các yêu cầu mà không có dữ liệu có thẩm quyền hiện diện ít hơn mong muốn với điều này trong tâm trí.

Cập nhật:

Về việc không thể bỏ qua các truy vấn trên sàn là điều tất nhiên, @Alnitak đã chia sẻ với chúng tôi rằng hiện tại có Dự thảo BCP bao gồm chủ đề này một cách chi tiết. Có một chút sớm để sử dụng điều này như một trích dẫn, nhưng nó giúp củng cố sự đồng thuận của cộng đồng phù hợp với những gì được thể hiện ở đây. Đặc biệt:

Trừ khi một máy chủ tên đang bị tấn công, nó sẽ trả lời tất cả các truy vấn hướng đến nó như là kết quả của các ủy nhiệm sau. Ngoài ra, mã không nên cho rằng không có ủy quyền cho máy chủ ngay cả khi nó không được cấu hình để phục vụ vùng. Các ủy nhiệm bị hỏng là một sự xuất hiện phổ biến trong DNS và việc nhận các truy vấn cho các vùng mà máy chủ không được định cấu hình không nhất thiết là một dấu hiệu cho thấy máy chủ đang bị tấn công. Các nhà điều hành khu vực phụ huynh phải thường xuyên kiểm tra xem các bản ghi NS ủy nhiệm có phù hợp với các bản ghi của khu vực được ủy quyền hay không và sửa chúng khi chúng không phải là [RFC1034]. Nếu điều này được thực hiện thường xuyên, các trường hợp của các đoàn bị hỏng sẽ thấp hơn nhiều.

Câu trả lời này sẽ được cập nhật khi trạng thái của tài liệu này thay đổi.

Khi bạn chuyển DNS có thẩm quyền cho một tên miền sang nhà cung cấp mới, bạn phải luôn luôn (luôn luôn!) Kiểm tra rõ ràng với nhà cung cấp mới (và đảm bảo họ đang gửi các bản ghi chính xác, được định cấu hình) trước khi bạn thay đổi thông tin đăng ký tên miền (whois) để trỏ đến các máy chủ DNS có thẩm quyền mới.

Một cách thô bạo, các bước bạn sẽ thực hiện:

1. Thiết lập mọi thứ trên nhà cung cấp DNS mới. Bạn nên tạo và điền vào tất cả các khu vực.

2. Hãy chắc chắn rằng các máy chủ có thẩm quyền mới hoạt động chính xác. Truy vấn chúng một cách rõ ràng:

   dig @new-ns.example.com mydomain.com
   

   Những gì nghe có vẻ như, từ câu hỏi của bạn, là họ không trả lời các truy vấn này? Nhưng, bạn đã nói "các miền không xác định" không nên ở thời điểm này, nó phải được cấu hình đầy đủ trong hệ thống của họ (và phản hồi với các bản ghi bạn đã định cấu hình).

   Nhưng, nếu bạn đã đã được cấu hình tên miền trong hệ thống của họ, nó phải được đáp ứng với các hồ sơ chính xác tại thời điểm này. Nếu không thì họ sẽ không lưu trữ đúng khu vực và bạn nên la mắng họ; nó có đáp ứng với một miền mà nó không được cấu hình hay không sẽ không quan trọng. (Nếu tôi vẫn còn thiếu những gì bạn đang nói, xin vui lòng cho tôi biết).

3. Chuyển đổi máy chủ tên có thẩm quyền với công ty đăng ký tên miền của bạn (whois), để nhà cung cấp DNS cũ hoạt động và chạy cho đến khi lưu lượng truy cập không còn truy cập được nữa (cung cấp ít nhất 24 giờ).

Nếu nhà cung cấp mới hoàn toàn không thể có các bản ghi được điền trước khi bạn thực hiện chuyển đổi, thì cách họ phản hồi thực sự không thành vấn đề - việc chỉ người dùng đến một thẩm quyền từ chối truy vấn hoàn toàn sẽ gây ra thời gian chết cho tên miền của bạn giống như khi bạn không nhận được phản hồi nào cả