Tại sao RFC 7505 (Null MX) cần thiết?


18

IETF RFC 7505 mô tả các bản ghi MX cho một tên miền / máy chủ lưu trữ rõ ràng không nên nhận email. Điều này được thực hiện bằng cách trỏ MX vào gốc Hệ thống tên miền. Ví dụ,

nomail.example.com. 86400 IN MX 0 "."

Tại sao điều này là cần thiết? Theo hiểu biết của tôi, từ chối rõ ràng có sẵn bằng cách sử dụng các tên miền theo TLD invalid. Ví dụ,

nomail.example.com. 86400 IN MX 0 "spam.invalid."
nomail.example.com. 86400 IN MX 10 "null.invalid."

Tôi thấy RFC 2782, DNS SRV, tương tự xác định rằng "Mục tiêu của '.' có nghĩa là dịch vụ được quyết định là không có sẵn tại miền này. " Vì vậy, tôi cho rằng câu hỏi của tôi là:

Tại sao chúng ta nên sử dụng gốc DNS có nghĩa là "không khả dụng" khi invalidđã phục vụ chức năng này?


2
Đó không phải là một lời bác bỏ rõ ràng! Đó chỉ là dữ liệu không hợp lệ.
Michael Hampton

Câu trả lời:


21

Bởi vì đó không phải là những gì bạn cần phải được sử dụng .invalidcho. Giống như .examplenó có nghĩa là để thử nghiệm địa phương và tài liệu.

Ngoài ra, việc sử dụng .invalidvẫn khiến những điều bổ sung xảy ra - tra cứu DNS bổ sung và xếp hàng trên máy chủ thư để thử lại một lần trên đỉnh đầu tôi.

Sử dụng "."định dạng được cho là gây ra một thất bại ngay lập tức. Làm cho MTA ngay lập tức ngừng cố gắng giao hàng. Ít nhất đó là cách giới thiệu của RFC đọc.


2
Cảm ơn. Nhưng BCP: 32 / RFC 2606 Phần 2 đọc "'.invalid' được sử dụng để xây dựng trực tuyến các tên miền chắc chắn không hợp lệ và rõ ràng là không hợp lệ." 2606 nói không có gì để chỉ ra rằng ".invalid" chỉ dành cho thử nghiệm cục bộ. Nó dành cho bất kỳ tên miền nào phải, tốt, không hợp lệ
Alpha Whiskey

Ok tôi có thể thấy lý do tại sao một cái gì đó trông giống như tên của máy chủ sẽ bất lợi so với ".".
Alpha Whiskey

1
@AlphaWhiskey Đó là con người có thể "liếc" vào thứ gì đó và đưa ra kết luận. Máy tính cần hướng dẫn rõ ràng.
Michael Hampton

3
công bằng mà nói, không khó để cung cấp cho máy tính hướng dẫn rõ ràng trong trường hợp cụ thể này.
muhmuhten

@res Thậm chí còn dễ dàng hơn khi không cung cấp cho máy tính hướng dẫn rõ ràng.
musiKk

9

Câu hỏi nói chung liên quan đến một vài khía cạnh khác nhau mà tất cả cần phải được xem xét để trả lời tại sao RFC7505 thêm một cái gì đó hữu ích.


Trước hết, định nghĩa trước RFC7505 về cách thực hiện gửi thư không có cách nào để chỉ rõ rằng không nên thực hiện các nỗ lực gửi thư cho tên có hồ sơ địa chỉ.

Từ RFC7505 phần 1 :

Các máy khách SMTP có một chuỗi quy định để xác định một máy chủ chấp nhận email cho một tên miền. Mục 5 của [RFC5321] bao gồm chi tiết này; về bản chất, máy khách SMTP trước tiên tìm kiếm DNS MX RR và nếu không tìm thấy, nó sẽ quay lại tìm kiếm DNS A hoặc AAAA RR. Do đó, điều này làm quá tải bản ghi DNS (có nhiệm vụ chính khác) với ngữ nghĩa dịch vụ email.

Nếu tên miền không có bản ghi MX, người gửi sẽ cố gắng gửi thư đến máy chủ tại các địa chỉ trong bản ghi A hoặc AAAA của tên miền. Nếu không có người nghe SMTP tại địa chỉ A / AAAA, việc gửi tin nhắn sẽ được thử liên tục trong một thời gian dài, thường là một tuần, trước khi Đại lý chuyển thư (MTA) gửi từ bỏ. Điều này sẽ trì hoãn thông báo cho người gửi trong trường hợp thư bị chuyển hướng sai và sẽ tiêu tốn tài nguyên tại người gửi.

Tài liệu này định nghĩa một MX null sẽ khiến tất cả các lần gửi thư đến một tên miền bị lỗi ngay lập tức, mà không yêu cầu các miền tạo trình nghe SMTP dành riêng để ngăn chặn các nỗ lực gửi.


Sau đó, có vấn đề về cách RFC7505 thực hiện điều này ( IN MX 0 .).

Từ RFC7505 phần 3 :

  1. Bản ghi tài nguyên MX Chỉ định Null MX

    Để chỉ ra rằng một tên miền không chấp nhận email, nó quảng cáo một MX RR duy nhất (xem Phần 3.3.9 của [RFC1035]) với phần RDATA bao gồm số ưu tiên 0 và nhãn có độ dài bằng không, được viết trong các tệp chính là ". ", Là miền trao đổi, để biểu thị rằng không tồn tại trao đổi thư cho một miền. Từ "." không phải là tên máy chủ hợp lệ, bản ghi MX null có thể bị nhầm lẫn với bản ghi MX thông thường. Việc sử dụng "." như một tên máy chủ giả có nghĩa là không có dịch vụ nào được mô hình hóa trên SRV RR [ RFC2782 ] trong đó nó có ý nghĩa tương tự.

    Tên miền quảng cáo MX null KHÔNG PHẢI quảng cáo bất kỳ MX RR nào khác.

(nhấn mạnh thêm)

Như đã lưu ý ở đây, các chi tiết triển khai cho "null MX" dựa trên một mẫu đã được thiết lập từ SRVloại RR. Thật hợp lý khi bắt chước điều này vì SRVloại RR ít nhiều là phiên bản tổng quát của MXloại RR.

Vì vậy, quyết định về cơ bản đã được đưa ra khi xác định SRVloại RR .


Vì vậy, tại sao không sử dụng .invalid?

Từ RFC2606 phần2 :

".Invalid" được thiết kế để sử dụng trong việc xây dựng tên miền trực tuyến chắc chắn là không hợp lệ và rõ ràng trong nháy mắt là không hợp lệ.

Như có thể thấy ở đây, TLD dành riêng này là dành cho tiêu dùng của con người. Không có tiền lệ xác định xử lý đặc biệt này trong phần mềm.

Chắc chắn nó có thể được thực hiện theo một số cách khác nhau nhưng họ đã chọn sử dụng phương pháp tối thiểu để sử dụng ., đây không phải là tên máy chủ hợp lệ và do đó không can thiệp vào việc sử dụng thông thường.


Theo như tôi có thể nói, không có lý do kỹ thuật nào .không thể được sử dụng làm bản ghi MX nếu bản ghi A hoặc AAAA đã được xuất bản ở gốc. Khi tôi gõ telnet . 25nó chắc chắn sẽ tìm bản ghi A và AAAA ở gốc.
kasperd

1
@kasperd Mặc dù giao thức DNS chắc chắn có thể đại diện cho nó, tôi không tin rằng có các bản ghi địa chỉ tại .hoặc (trước RFC7505) chỉ định .EXCHANGEgiá trị cho một MXbản ghi sẽ thực sự hợp lệ. (Đây không phải là tên máy chủ hợp lệ.)
Håkan Lindqvist

Hợp lệ hay không - Tôi có thể dễ dàng tưởng tượng các triển khai mà khi đối mặt với bản ghi MX trỏ đến tên miền không có bản ghi A sẽ thử lại phân phối trong nhiều ngày trước khi từ bỏ.
kasperd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.