Các tiêu chuẩn internet có yêu cầu DNS ngược cho mọi thiết bị không?

Các yêu cầu xung quanh DNS ngược là khó hiểu! Mọi người thường nói về mọi thứ bị phá vỡ nếu DNS ngược không xuất hiện và điều đó nghe có vẻ đáng sợ. Ngay cả trong trường hợp các ứng dụng không yêu cầu DNS ngược, RFC vẫn thường được trích dẫn để hỗ trợ cho việc tạo bản ghi PTR bắt buộc.

Một số RFC này bao gồm:

RFC1912 : Lỗi cấu hình và vận hành DNS phổ biến

Mỗi máy chủ truy cập Internet nên có một tên. ... Hãy chắc chắn rằng hồ sơ PTR và A của bạn khớp. Đối với mỗi địa chỉ IP, cần có một bản ghi PTR phù hợp trong miền in-addr.arpa. Nếu một máy chủ lưu trữ nhiều homed, (nhiều hơn một địa chỉ IP), hãy đảm bảo rằng tất cả các địa chỉ IP có bản ghi PTR tương ứng (không chỉ địa chỉ đầu tiên). Việc không có các bản ghi PTR và A phù hợp có thể gây mất dịch vụ Internet tương tự như không được đăng ký trong DNS.

RFC1033 : HƯỚNG DẪN HOẠT ĐỘNG CỦA QUẢN LÝ TÊN MIỀN

Thêm một máy chủ.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

Bất chấp tất cả những điều đó, một số người vẫn khăng khăng nói rằng việc tạo bản ghi PTR không bắt buộc bởi các tiêu chuẩn quản lý DNS. Các yêu cầu thực tế là gì?

Câu trả lời ngắn

Các tiêu chuẩn quản lý hoạt động DNS có yêu cầu tất cả các thiết bị có bản ghi PTR phù hợp không? Không.

Các tiêu chuẩn cho các giao thức nhất định yêu cầu PTRcác hồ sơ đồng ý với các hồ sơ tương ứng Ahoặc AAAAhồ sơ? Vâng.

Do một số ứng dụng không được quản lý bởi RFC có cùng yêu cầu không? Vâng.

Có thể ghi điểm PTR tại CNAME không? Có, nhưng mục tiêu CNAME phải là tên duy nhất của thiết bị được đề cập (và không phải là một CNAME khác). ( RFC 2181 §10.2 , RFC1034 §3.6.2 )

Là bắt buộc tạo hồ sơ PTR là một thực hành tốt nhất? Thường tin như vậy, nhưng nó có vấn đề riêng của nó.

Câu trả lời dài

Câu hỏi và trả lời này được cung cấp với mục đích giúp đưa ra một sự hiểu lầm phổ biến.

Một phần được đánh giá thấp của RFC1796 áp dụng ở đây:

Đó là một quan niệm sai lầm đáng tiếc lan truyền tốt rằng xuất bản như một RFC cung cấp một số mức độ công nhận. Nó không, hoặc ít nhất là không nhiều hơn các ấn phẩm trong một tạp chí thông thường. Trên thực tế, mỗi RFC có một trạng thái, liên quan đến mối quan hệ của nó với quy trình chuẩn hóa Internet: Theo dõi thông tin, thử nghiệm hoặc tiêu chuẩn (Tiêu chuẩn đề xuất, Tiêu chuẩn dự thảo, Tiêu chuẩn Internet) hoặc Lịch sử.

RFC1912 là thông tin. RFC1033 không được dán nhãn rõ ràng và có một chỉ định chính thức của UNKNOWN , điều đó có nghĩa là nó quá cũ đến nỗi nó không nên được coi là tài liệu tham khảo cho bất cứ điều gì . Họ không định nghĩa Tiêu chuẩn, cũng không thể sử dụng chúng để chính thức gia tăng một tiêu chuẩn. Họ không bao giờ nên được trích dẫn trong bối cảnh ngụ ý rằng họ đang xác định một tiêu chuẩn.

Hãy nghĩ về các đề xuất RFC thông tin là lời khuyên tốt và thường được chấp nhận thực hành tốt nhất. Các đề xuất DNS ngược có ý nghĩa trong nháy mắt: làm theo các hướng dẫn này sẽ giảm nguy cơ bị đặt vào tình huống ứng dụng không hoạt động vì DNS ngược là cần thiết và không được lên kế hoạch. Bạn chắc chắn không thể mong muốn một quản trị viên DNS biết mọi ứng dụng / giao thức yêu cầu nó, và thật đáng buồn là điều tương tự cũng đúng với các chủ sở hữu dịch vụ yêu cầu các hồ sơ đó.

Điều đó nói rằng, bên ngoài tự động hóa rất tốt , các chính sách tạo hồ sơ PTR bắt buộc cũng tạo ra ô nhiễm.

• Điều cực kỳ phổ biến là các PTRbản ghi không được giữ đồng bộ với các bản ghi A/ tương ứng của chúng AAAAkhi các thiết bị ngừng hoạt động, dẫn đến một khối PTRdữ liệu không có thật theo thời gian. Dữ liệu này chỉ phục vụ để đánh lừa những người cố gắng coi thông tin đó là đáng tin cậy. Một số chủ sở hữu ứng dụng rất muốn nhảy vào nó khi họ đang tìm kiếm nguyên nhân của một vấn đề ảo. Vấn đề sẽ chỉ tiếp tục trở nên tồi tệ hơn khi việc áp dụng IPv6 trở nên phổ biến hơn, đặc biệt đối với các quản trị viên DNS chịu trách nhiệm về không gian IP có kích thước của nhà mạng.
• Có nhiều bản ghi PTR cho cùng một địa chỉ IP là khá vô ích và việc tuân thủ lời khuyên của RFC thông tin chắc chắn sẽ dẫn đến điều này. Xem: Tại sao nhiều bản ghi PTR trong DNS không được khuyến nghị?

Điều gì tệ hơn: không có bản ghi PTR, hoặc bản ghi PTR không chính xác? Nếu một giao thức bị phá vỡ vì tiêu chuẩn của nó yêu cầu DNS hợp lệ, cả hai đều xấu và cái sau thực sự có thể tồi tệ hơn . Bên ngoài đó, mọi người đều có ý kiến ​​khác nhau về vấn đề này. Điều đó tốt: bạn có thể tự do kết hợp các chính sách và công cụ phù hợp nhất với nhóm và công ty của bạn. Chỉ cần đảm bảo rằng họ chia tỷ lệ và mang lại kết quả nhất quán và hãy nhớ rằng DNS ngược sẽ chỉ chính xác như thời gian và kỷ luật mà các thành viên trong nhóm của bạn phải cung cấp.

Nhưng hồ sơ PTR bị thiếu khiến sshd bị treo!

Cũng không đúng. Mọi người thường nhầm lẫn giữa dòng không có bản ghi PTR (NXDOMAIN) và DNS ngược bị hỏng .

Trả lời NXDOMAINsẽ chỉ gây ra sự cố nếu bạn đang liên lạc với một dịch vụ yêu cầu DNS ngược được xác nhận chuyển tiếp (FCrDNS). Máy chủ thư, Kerberos, Oracle quét VIP, v.v.

DNS ngược bị hỏng là khi bạn không thể nhận được NXDOMAINphản hồi kịp thời. Nhiều ứng dụng (nổi tiếng nhất sshd) sẽ chặn tra cứu DNS ngược nếu có vấn đề nhận được phản hồi từ các nguồn ngược dòng một cách kịp thời, gây ra sự chậm trễ trong ứng dụng.