Không nhận được thư từ một số người gửi do cấu hình DNS

Tôi đã nhận thấy một hành vi đặc biệt của miền ứng dụng google của tôi. Hầu hết các thư đi qua như bạn mong đợi, nhưng trong một khoảng thời gian tôi đã đi đến kết luận rằng các thư từ một số người gửi không đi qua. Sau khi xác định một người gửi như vậy, những người mà thư sẽ không gửi qua, tôi đã yêu cầu anh ta cố gắng gửi email cho tôi và chuyển tiếp "thất bại trong giao hàng" - phản hồi lại gmail thông thường của tôi.

Phản hồi thất bại giao hàng chứa đoạn mã sau:

----- Bảng điểm của phiên sau -----
<myusername@GHS.L.GOOGLE.COM>... Trì hoãn: Đã hết thời gian kết nối với ghs.l.google.com.

Điều này giúp tôi xác định vấn đề bằng cách thực hiện tìm kiếm nhanh dẫn tôi đến trang này trên Diễn đàn trợ giúp của Google Apps. Thật vậy, tôi đã kiểm tra bản ghi DNS cho tên miền của mình và @được đặt thành ghs.google.com. (CNAME), điều không nên. Thay đổi điều đó thành @ 74.125.93.121 (A)* giải quyết vấn đề.

Tôi hiểu rằng trong trường hợp thư không đi qua, tên miền của tôi đã được thay thế bằng tên chính tắc thông qua tra cứu CNAME, vì vậy thư được gửi đến myusername@ghs.l.google.comthay vì myusername@mydomain.com. Nhưng tại sao nó làm việc cho đại đa số người gửi? Có phải những người gửi thư không đi qua, sử dụng một số loại giao thức thư khác nhau, một số cài đặt DNS lạ hoặc có thể là gì?

Từ những gì tôi có thể thấy bằng cách nghiên cứu vấn đề trên google, đây dường như là một vấn đề phổ biến (rất nhiều người phàn nàn về email từ battle.net không thông qua, sẽ là một ví dụ phổ biến), chỉ có điều mọi người dường như không để biết rằng vấn đề nằm ở cài đặt DNS của riêng họ, thay vào đó là ở phía người gửi.

Vì vậy, làm thế nào điều này có thể được giải thích?

^{* Tôi đã sử dụng IP này vì những gì tôi đọc ở đây , nhưng tôi nghĩ rằng bất kỳ IP nào cũng sẽ làm điều đó. bất cứ ai có thể xác nhận điều này? Lưu ý rằng chỉ cần xóa @bản ghi không giải quyết được vấn đề, nó phải được thay đổi.}

Từ RFC 2821 "Giao thức chuyển thư đơn giản", phần 5 "Giải quyết địa chỉ và xử lý thư":

Việc tra cứu trước tiên cố gắng xác định vị trí bản ghi MX được liên kết với tên. Nếu một bản ghi CNAME được tìm thấy thay vào đó, tên kết quả được xử lý như thể đó là tên ban đầu.

Nói chung, đây là cách CNAME hoạt động. Chúng thường được sử dụng sai, hiểu sai và thực hiện sai. :-)

Nếu tên miền của bạn là example.com, bạn có thể có các bản ghi MX hiện tại trỏ đến máy chủ Google Apps thông thường.

example.com. MX 10 ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT1.ASPMX.L.GOOGLE.COM.
example.com. MX 20 ALT2.ASPMX.L.GOOGLE.COM.
example.com. MX 30 ASPMX2.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX3.GOOGLMAILE.COM.
example.com. MX 30 ASPMX4.GOOGLEMAIL.COM.
example.com. MX 30 ASPMX5.GOOGLEMAIL.COM.

Có vẻ như bạn cũng có một mục như thế này:

example.com. CNAME ghs.l.google.com.

RFC 1034 "Các khái niệm và tiện ích tên miền" trong phần 3.6.2 "Bí danh và tên chính tắc" khuyến nghị đối với cấu hình này:

Nếu một CNAME RR có mặt tại một nút, thì không có dữ liệu nào khác; điều này đảm bảo rằng dữ liệu cho một tên chính tắc và bí danh của nó không thể khác nhau.

Trong trường hợp lỗi bạn đã dán, máy chủ thư và / hoặc máy chủ DNS ở đầu gửi đã cố gắng tra cứu (các) bản ghi MX cho tên miền của bạn, example.com và tìm thấy một CNAME trỏ đến ghs.l.google. com. Sau đó, nó đã cố gắng tra cứu (các) bản ghi MX cho ghs.l.google.com. Tên miền đó hiện không có bất kỳ bản ghi MX nào, vì vậy máy chủ thư sẽ rơi vào bản ghi A cho ghs.l.google.com. Địa chỉ IP đó không nghe trên cổng SMTP, do đó, kết quả là lỗi "Đã hết thời gian kết nối với ghs.l.google.com."

Bằng cách xóa bản ghi CNAME, bạn đã khắc phục sự cố thư của mình. Bạn có thể gặp phải sự cố nếu địa chỉ IP bạn đã xác định ở vị trí của nó bị thay đổi vào cuối Google.

Thay vào đó, bạn có thể xác định tên cho www.example.com:

www.example.com. CNAME ghs.l.google.com.

Và chạy một máy chủ web nhỏ trên bất kỳ IP nào bạn trỏ example.com, đơn giản là chuyển hướng HTTP đến http://www.example.com/

Nó hơi ngạc nhiên khi nó hoạt động tốt như nó đã làm. Luật của Postel nhận được một số tín dụng ở đó, tôi tin. :-)

Quay lại RFC 1034 2.6.2:

CNAME RRs gây ra hành động đặc biệt trong phần mềm DNS. Khi một máy chủ tên không tìm thấy RR mong muốn trong bộ tài nguyên được liên kết với tên miền, nó sẽ kiểm tra xem liệu bộ tài nguyên có chứa bản ghi CNAME với một lớp phù hợp hay không. Nếu vậy, máy chủ tên bao gồm bản ghi CNAME trong phản hồi và khởi động lại truy vấn tại tên miền được chỉ định trong trường dữ liệu của bản ghi CNAME. Một ngoại lệ cho quy tắc này là các truy vấn phù hợp với loại CNAME không được khởi động lại.

Vì vậy, trong trường hợp này, có thể lập luận rằng máy chủ DNS sẽ / không nên theo dõi CNAME trên tra cứu MX trừ khi không tìm thấy bản ghi MX nào.

Khi gửi thư, Sendmail và qmail (và có thể là những người khác) theo mặc định sẽ cố gắng viết lại bất kỳ CNAME nào được sử dụng ở phía bên phải của một địa chỉ email thành tên chính tắc.

Thật vậy, một số trang web dựa trên hành vi này. djb đi vào một số chi tiết về lý do tại sao anh ấy nghĩ mọi người nên ngừng dựa vào nó trong tài liệu "hồ sơ CNAME trong thư" của mình .

Các @biểu tượng trong một bản ghi BIND chỉ là một cách viết tắt của văn bản tên miền. Nếu bạn đang tạo một bản ghi cho example.com, thì đó @chỉ là bí danh cho example.com. Nói rằng @bản ghi phải là một IP là một tuyên bố thiếu thông tin quan trọng - bạn đã không cho chúng tôi biết đó là loại bản ghi nào.

Từ báo cáo gửi, có vẻ như bạn có thể đã làm gì đó với DNS của mình để khiến máy chủ thư từ xa viết lại tên miền của bạn thành ghs.l.google.com - rất lạ (PS, bản ghi A phải là IP, bản ghi CNAME phải không phải là một IP hoặc bản ghi CNAME khác).

Tại sao máy chủ thư của người đó viết lại địa chỉ của bạn là lạ - không nên trừ khi người đó đã làm gì đó để nói rõ ràng để viết lại địa chỉ đó. Bạn cũng không nên quan tâm đến IP của miền của bạn là gì trừ khi không thể tìm thấy bất kỳ bản ghi MX nào, vì các bản ghi MX là cách các máy chủ thư tìm ra thư đi đâu.

Tôi nghe có vẻ như, với rất ít thông tin được cung cấp, rằng bạn đã không làm theo hướng dẫn của google về cách định cấu hình đúng DNS của bạn cho email. Bạn thậm chí có thể có một số lỗi trong tệp vùng của bạn - hãy kiểm tra chúng bởi quản trị viên vùng có thẩm quyền.