RFC 6186: Bản ghi SRV cho Tự động khám phá Dịch vụ Email
Tại Sao Tính Năng Này Tồn Tại
Cấu hình máy khách email yêu cầu biết nhiều tên máy chủ, cổng và cài đặt bảo mật: máy chủ IMAP hoặc POP3 để đọc thư, và máy chủ submission để gửi. Hầu hết người dùng không thể cung cấp thông tin này. Trước khi có bản ghi SRV, máy khách email dựa vào:
- Đoán tên máy chủ thông thường như
mail.example.comhoặcimap.example.com - Các giao thức tự động khám phá độc quyền (Microsoft Autodiscover, Mozilla ISPDB)
- Hướng dẫn cấu hình thủ công
RFC 6186 cung cấp một cơ chế dựa trên DNS tiêu chuẩn hoạt động cho bất kỳ tên miền nào. Quản trị viên tên miền công bố các bản ghi SRV, và bất kỳ máy khách email nào tuân thủ tiêu chuẩn có thể tự động khám phá máy chủ chính xác.
Cách Hoạt Động
Máy khách email trích xuất tên miền từ địa chỉ email của người dùng, sau đó truy vấn DNS để tìm bản ghi SRV theo tên dịch vụ cụ thể.
Định Dạng Bản Ghi SRV
Tên: _service._proto.domain Kiểu: SRV Nội dung: priority weight port target
Bản Ghi DNS Cần Thiết
Đối với tên miền example.com với email được lưu trữ trên mail.provider.net:
; Nhận thư (IMAP qua TLS) _imaps._tcp.example.com. IN SRV 0 1 993 mail.provider.net. ; Nhận thư (IMAP với STARTTLS) _imap._tcp.example.com. IN SRV 0 1 143 mail.provider.net. ; Nhận thư (POP3 qua TLS) _pop3s._tcp.example.com. IN SRV 0 1 995 mail.provider.net. ; Gửi thư (Submission qua TLS) _submissions._tcp.example.com. IN SRV 0 1 465 mail.provider.net. ; Gửi thư (Submission với STARTTLS) _submission._tcp.example.com. IN SRV 0 1 587 mail.provider.net.
Vô Hiệu Hóa Dịch Vụ
Để chỉ ra rằng một dịch vụ không có sẵn, công bố bản ghi SRV với mục tiêu là . (một dấu chấm):
; Chúng tôi không cung cấp POP3
_pop3._tcp.example.com. IN SRV 0 0 0 .
_pop3s._tcp.example.com. IN SRV 0 0 0 .
Chi Tiết Kỹ Thuật Chính
Tên Dịch Vụ Được Xác Định Bởi RFC 6186
| Tên SRV | Giao Thức | Cổng Mặc Định | Bảo Mật |
|---|---|---|---|
_imaps._tcp |
IMAP | 993 | TLS Ngầm (ưa thích) |
_imap._tcp |
IMAP | 143 | STARTTLS |
_pop3s._tcp |
POP3 | 995 | TLS Ngầm |
_pop3._tcp |
POP3 | 110 | STARTTLS |
_submissions._tcp |
Submission | 465 | TLS Ngầm (ưa thích) |
_submission._tcp |
Submission | 587 | STARTTLS |
Ưu Tiên Khám Phá Máy Khách
- Truy vấn
_imaps._tcptrước tiên (TLS ngầm được ưa thích hơn STARTTLS theo RFC 8314). - Nếu không có bản ghi
_imaps, quay lại_imap._tcpvới STARTTLS bắt buộc. - Đối với submission, ưa thích
_submissions._tcp(cổng 465) hơn_submission._tcp(cổng 587). - Sử dụng các trường ưu tiên và trọng số SRV để cân bằng tải và chuyển đổi dự phòng trên nhiều máy chủ.
Xác Minh Chứng Chỉ TLS
Theo RFC 7817, máy khách phải xác minh chứng chỉ TLS của máy chủ so với tên máy chủ mục tiêu SRV (ví dụ: mail.provider.net), không phải tên miền email của người dùng. Điều này cho phép các nhà cung cấp lưu trữ phục vụ nhiều tên miền bằng một chứng chỉ.
Lỗi Phổ Biến
- Không công bố bản ghi SRV. Nhiều tên miền dựa vào khám phá tự động độc quyền hoặc giả định người dùng sẽ cấu hình thủ công. Công bố bản ghi SRV chỉ mất vài phút và giúp mọi máy khách email tuân thủ tiêu chuẩn.
-
Chỉ công bố các biến thể STARTTLS. RFC 8314 khuyến nghị TLS ngầm. Công bố cả bản ghi
_imapsvà_submissions(TLS ngầm) làm tùy chọn chính, với các biến thể STARTTLS làm phương án dự phòng. - Mục tiêu SRV trỏ đến CNAME. Mục tiêu SRV phải là bản ghi A hoặc AAAA, không phải CNAME. Đây là yêu cầu của giao thức DNS (RFC 2782). Trỏ SRV đến CNAME có thể gây lỗi phân giải.
- Quên vô hiệu hóa các dịch vụ chưa sử dụng. Nếu bạn không hỗ trợ POP3, hãy công bố bản ghi SRV "chấm" để cho máy khách biết rõ ràng. Nếu không, họ có thể dành thời gian để thăm dò các cổng sẽ không bao giờ phản hồi.
-
Không khớp chứng chỉ với mục tiêu SRV. Nếu bản ghi SRV của bạn nhắm đến
mail.provider.net, chứng chỉ TLS trên máy chủ đó phải bao gồmmail.provider.nettrong SAN của nó. Những điểm không khớp gây lỗi kết nối ở các máy khách xác minh chứng chỉ.
Tác Động Đến Khả Năng Gửi
- Giảm cấu hình sai của người dùng. Khám phá tự động có nghĩa là ít người dùng nhập cài đặt sai hơn, dẫn đến ít vé hỗ trợ "không thể gửi" và ít tin nhắn bị mắc kẹt trong hộp thư đi.
- Thực thi TLS ngay từ đầu. Bằng cách chỉ quảng cáo các dịch vụ hỗ trợ TLS qua SRV, bạn đảm bảo máy khách kết nối an toàn theo mặc định thay vì bắt đầu không được mã hóa.
- Cho phép di chuyển lưu trữ mượt mà. Khi chuyển email sang nhà cung cấp mới, cập nhật bản ghi SRV và máy khách sẽ tự động tìm thấy máy chủ mới mà không cần cấu hình lại thủ công.
-
Bổ sung các thực tiễn tốt nhất submission. Bản ghi SRV cho
_submissionshướng máy khách đến cổng submission được xác thực chính xác (RFC 6409), giữ lưu lượng submission được phân tách đúng cách khỏi lưu lượng relay MX.