Tôi hiểu rằng bạn không nên trỏ trực tiếp bản ghi MX vào địa chỉ IP, mà thay vào đó , nên trỏ nó vào một Abản ghi, lần lượt, trỏ đến địa chỉ IP của máy chủ thư của bạn.

Nhưng, về nguyên tắc, tại sao điều này là bắt buộc?

Toàn bộ ý tưởng đằng sau bản ghi MX là chỉ định máy chủ hoặc máy chủ có thể chấp nhận thư cho một tên miền. Như được chỉ định trong RFC 1035 , bản ghi MX chứa một tên miền. Do đó, nó phải trỏ đến một máy chủ có thể được giải quyết trong DNS. Một địa chỉ IP không thể được sử dụng vì nó sẽ được hiểu là một tên miền không đủ tiêu chuẩn, không thể giải quyết được.

Những lý do cho điều này vào những năm 1980, khi thông số kỹ thuật ban đầu được viết, gần giống như lý do cho ngày hôm nay: Một máy chủ có thể được kết nối với nhiều mạng và sử dụng nhiều giao thức.

Trở lại những năm 80, không có gì lạ khi có các cổng thư kết nối cả Internet (tương đối mới) sử dụng TCP / IP và với các mạng kế thừa khác, thường sử dụng các giao thức khác. Chỉ định MX theo cách này cho phép các bản ghi DNS có thể xác định cách truy cập máy chủ như vậy trên mạng không phải là Internet, chẳng hạn như Chaosnet . Trong thực tế, mặc dù, điều này gần như không bao giờ xảy ra; thay vào đó, hầu như mọi người đều thiết kế lại mạng của mình để trở thành một phần của Internet.

Ngày nay, tình huống là một máy chủ có thể được tiếp cận bởi nhiều giao thức (IPv4 và IPv6) và bởi nhiều địa chỉ IP trong mỗi giao thức. Một bản ghi MX không thể liệt kê nhiều hơn một địa chỉ, do đó, tùy chọn duy nhất là trỏ đến một máy chủ lưu trữ, nơi tất cả các địa chỉ của máy chủ đó có thể được tra cứu. (Để tối ưu hóa hiệu suất, máy chủ DNS sẽ gửi cùng các bản ghi địa chỉ cho máy chủ trong phần bổ sung phản hồi nếu nó có các bản ghi có thẩm quyền cho chúng, tiết kiệm một chuyến đi khứ hồi.)

Cũng có tình huống phát sinh khi bộ trao đổi thư của bạn được cung cấp bởi bên thứ ba (ví dụ: Google Apps hoặc Office 365). Bạn trỏ các bản ghi MX của bạn đến tên máy chủ của chúng, nhưng có thể xảy ra rằng nhà cung cấp dịch vụ cần thay đổi địa chỉ IP của máy chủ thư. Vì bạn đã chỉ đến một máy chủ lưu trữ, nhà cung cấp dịch vụ có thể thực hiện việc này một cách minh bạch và bạn không phải thực hiện bất kỳ thay đổi nào đối với hồ sơ của mình.

DNS là một giao thức có một số loại giá trị khác nhau, chúng không thể thay thế cho nhau.

Điều quan trọng cần lưu ý là DNS là một giao thức nhị phân với ánh xạ nghiêm ngặt giữa loại bản ghi và loại dữ liệu mà bản ghi đó lưu giữ.

Ví dụ:
Một Abản ghi chứa một địa chỉ IPv4 (4 byte dữ liệu, độ dài cố định).
Một AAAAbản ghi chứa một địa chỉ IPv6 (16 byte dữ liệu, độ dài cố định).

Một MXbản ghi, mặt khác, giữ một tên (một chuỗi các nhãn trên định dạng <int number of bytes> <label> <int number of bytes> <label> <int 0>, độ dài thay đổi).

Không thể để MXbản ghi có địa chỉ IP làm dữ liệu.

Tôi sẽ ném nó ra như một phỏng đoán. Tất nhiên, tôi ở nhà bị cúm nên có lẽ tôi bị bệnh hoạn.

RFC 974 tuyên bố:

Bước đầu tiên cho người gửi thư tại LOCAL là đưa ra một truy vấn cho MX RR cho XÓA. Chúng tôi rất khuyến khích rằng bước này được thực hiện mỗi khi người gửi thư cố gắng gửi thư. Hy vọng là những thay đổi trong cơ sở dữ liệu miền sẽ nhanh chóng được sử dụng bởi các bưu phẩm và do đó, các quản trị viên tên miền sẽ có thể định tuyến lại các tin nhắn chuyển tiếp cho các máy chủ bị lỗi bằng cách thay đổi cơ sở dữ liệu miền của họ.

Bằng cách yêu cầu một tên thay vì IP, nó khuyến khích mạnh mẽ thực hành này. Tên có thể giữ nguyên và trong trường hợp cân bằng tải hoặc DR, bạn sẽ không phải lo lắng về việc thay đổi bản ghi MX và chờ lan truyền DNS.

Một số máy chủ email (như exim) đặc biệt không cho phép gửi tới các bản ghi MX trỏ đến một địa chỉ IP thuần túy, do đó bạn bắt buộc phải sử dụng FQDN cho nó để tuân thủ. Điều này là do hầu hết các máy chủ đều mong muốn bản ghi MX chứa tên máy chủ chứ không phải IP (đó là bản ghi A dành cho).

Chỉnh sửa: Để giải thích, trong DNS, mỗi bản ghi có các yêu cầu nghiêm ngặt về loại dữ liệu mà mỗi bản ghi có thể giữ. Trong trường hợp của các bản ghi MX, đó là một hostname chỉ .

Các bản ghi IN RFC 1025 MX chỉ trỏ đến RR (bản ghi tài nguyên) của Bản ghi A hoặc CNAME.

Vì vậy, máy chủ thư gửi thư yêu cầu RR của bản ghi MX, bản ghi mx liệt kê A bản ghi của máy chủ, máy chủ thư thực hiện tra cứu để nhận bản ghi A và sau đó chuyển thư qua smtp đến máy chủ dịch vụ được liệt kê dưới dạng một máy chủ thư 'sẵn sàng' nhận thư cho tên miền đó.

Câu hỏi của bạn - Tại sao Thư không thể được gửi đến địa chỉ IP

Phản hồi - Vì tin tưởng

Nhiều quy tắc tại chỗ liên quan đến thư đã phát triển để duy trì sự tin tưởng giữa các tên miền mà các thư được gửi qua lại thực sự hợp lệ. Tất cả điều này là để cuối cùng giảm SPAM.

• Tra cứu IP đảo ngược
• Tra cứu tên chuyển tiếp cho vấn đề đó

Tất cả các thành phần thiết yếu này cho một nền tảng để xây dựng một máy chủ thư có ít nhất một số thành phần nhỏ được thành lập để tạo ra các giao tiếp đáng tin cậy và giảm giao tiếp không đáng tin cậy.

Tham khảo - RFC 1035 và 974

https://www.ietf.org/rfc/rfc1035.txt35

https://www.ietf.org/rfc/rfc974.txt

Mục đích của MXhồ sơ là một ứng dụng (chuyển thư) có thể tìm hiểu về máy chủ sẽ được sử dụng. Ở cấp độ ứng dụng, tên máy chủ là thứ phù hợp để sử dụng (không phải địa chỉ IP).

Ngoài ra, việc thêm bản ghi của loại bản ghi biến thể vào DNS sẽ tạo ra một sự phức tạp và do đó là điểm khởi đầu cho các vấn đề, rủi ro khi thực hiện, các thách thức bảo mật. Ví dụ: 1.2.3.4.example.com.là tên máy chủ hợp lệ (vâng, ngay cả trong ánh sáng của RFC1034, 3.5). Chỉ định máy chủ này như MXtrong tệp cấu hình liên kết cho example.com có ​​thể trông giống như

.  MX 10  1.2.3.4

và có lẽ đó chính xác là cùng một bản ghi MX với IP sẽ như thế nào. Và thậm chí để chuyển thông tin trong một datagram DNS đòi hỏi một số additoin kỳ quặc; cách đơn giản nhất là giới thiệu một loại bản ghi tài nguyên mới , MXAgiả sử, cho sự định hướng. Nhưng sau đó, một lần nữa, tại sao lại giới thiệu một loại hồ sơ mới như vậy khi

. MXA 10 5.6.7.8

luôn luôn có thể được thay thế bằng

. MX 10 dummy
dummy A 5.6.7.8

(và cũng sẽ được hỗ trợ bởi các khách hàng DNS không biết về MXAhồ sơ)?