DANE — Xác thực dựa trên DNS cho SMTP TLS

Standards Track Transport Security Published March 2026

ELI5: Khi bạn truy cập một trang web, trình duyệt của bạn tin tưởng hàng trăm Cơ quan Cấp chứng chỉ để xác minh danh tính của trang web. DANE cho phép chủ sở hữu tên miền loại bỏ những kẻ trung gian: "Đây là chứng chỉ chính xác (hoặc CA) mà máy chủ thư của tôi sử dụng — tôi đã công bố nó trong DNS của mình, ký bằng DNSSEC, vì vậy bạn có thể tự xác minh nó." Không cần tin tưởng CA.

Tại Sao Tồn Tại Điều Này

SMTP với STARTTLS có hai vấn đề cơ bản:

Không xác thực. Máy chủ gửi không có cách nào đáng tin cậy để xác minh rằng chứng chỉ TLS của máy chủ nhận là hợp pháp. SMTP không sử dụng mô hình tin tưởng CA của web — theo lịch sử, hầu hết các máy chủ thư sử dụng chứng chỉ tự ký, vì vậy những người gửi đã học cách chấp nhận bất cứ điều gì.
Tấn công hạ cấp. Kẻ tấn công mạng hoạt động có thể loại bỏ quảng cáo STARTTLS khỏi phản hồi EHLO, buộc phải gửi ở dạng văn bản thuần túy.

MTA-STS (RFC 8461) giải quyết những vấn đề này bằng cách sử dụng HTTPS và Web PKI. DANE giải quyết chúng bằng cách sử dụng DNSSEC và bản ghi TLSA. Hai cách tiếp cận này bổ sung cho nhau: DANE mạnh hơn về mặt mã hóa (không cần tin tưởng CA), trong khi MTA-STS dễ triển khai hơn (không cần DNSSEC).

Cách Hoạt Động

DANE cho SMTP (được định nghĩa trong RFC 7672, dựa trên thông số kỹ thuật DANE cơ bản trong RFC 6698) hoạt động trong ba bước:

Bước 1: Vùng Được Ký DNSSEC

Vùng DNS của miền nhận — và vùng của mục tiêu MX — phải được ký bằng DNSSEC. Điều này không thể thương lượng. Nếu không có DNSSEC, kẻ tấn công có thể giả mạo bản ghi TLSA, khiến DANE trở nên tệ hơn là vô dụng.

Bước 2: Xuất Bản Bản Ghi TLSA

Miền xuất bản bản ghi TLSA cho từng cổng SMTP của máy chủ MX. Bản ghi TLSA liên kết chứng chỉ TLS (hoặc khóa công khai của nó, hoặc CA của nó) với một dịch vụ cụ thể.

; Định dạng bản ghi TLSA: _port._protocol.hostname TLSA usage selector matching-type data _25._tcp.mail.example.com. IN TLSA 3 1 1 a]b2c3d4e5f6...sha256hash...

Các Trường Bản Ghi TLSA

Trường	Giá Trị	Mô Tả
Usage	`0` — CA constraint (PKIX-TA) `1` — Certificate constraint (PKIX-EE) `2` — Trust anchor assertion (DANE-TA) `3` — Domain-issued certificate (DANE-EE)	Cách sử dụng dữ liệu chứng chỉ để xác thực.
Selector	`0` — Full certificate `1` — SubjectPublicKeyInfo	Phần nào của chứng chỉ để khớp.
Matching type	`0` — Exact match `1` — SHA-256 `2` — SHA-512	Cách biểu diễn dữ liệu.

Bước 3: Người Gửi Xác Thực

Khi máy chủ gửi hỗ trợ DANE gửi thư đến example.com:

Phân giải bản ghi MX cho example.com bằng xác thực DNSSEC.
Đối với từng máy chủ MX (ví dụ: mail.example.com), tìm kiếm _25._tcp.mail.example.com TLSA bằng xác thực DNSSEC.
Nếu bản ghi TLSA được xác thực DNSSEC tồn tại: kết nối, thực hiện STARTTLS, và xác thực chứng chỉ máy chủ so với dữ liệu TLSA.
Nếu xác thực không thành công: không gửi. Tin nhắn được xếp hàng để thử lại.
Nếu không có bản ghi TLSA (hoặc DNSSEC không được triển khai): quay lại TLS cơ hội như trước.

Chi Tiết Kỹ Thuật Chính

Cấu Hình TLSA Được Khuyến Nghị

Đối với máy chủ SMTP, RFC 7672 khuyến nghị DANE-EE(3) SPKI(1) SHA-256(1):

_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-public-key>

Đây là lựa chọn mạnh nhất vì:

Usage 3 (DANE-EE) bỏ qua xác thực CA hoàn toàn. Chứng chỉ không cần được ký bởi CA công khai — tự ký hoạt động tốt.
Selector 1 (SPKI) khớp khóa công khai, không phải chứng chỉ đầy đủ. Bạn có thể gia hạn chứng chỉ của mình (thay đổi số sê-ri, thời hạn) mà không cập nhật bản ghi TLSA, miễn là cặp khóa giữ nguyên.
Matching type 1 (SHA-256) lưu trữ hàm băm thay vì khóa đầy đủ, giữ bản ghi DNS nhỏ gọn.

Tạo Bản Ghi TLSA

# Trích xuất hàm băm SHA-256 của khóa công khai máy chủ
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# Bản ghi TLSA kết quả:
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE so với MTA-STS

	DANE	MTA-STS
Mô hình tin tưởng	DNSSEC (không cần CAs)	Web PKI (chứng chỉ do CA cấp)
Yêu cầu DNSSEC	Có (yêu cầu khó khăn)	Không
Chứng chỉ tự ký	Được hỗ trợ (usage 3)	Không được hỗ trợ
Bảo mật sử dụng đầu tiên	Bảo mật từ lần sử dụng đầu tiên	Tin tưởng khi sử dụng lần đầu (TOFU)
Rào cản triển khai	DNSSEC (đáng kể)	Hosting HTTPS (thấp)
Áp dụng	Mạnh ở NL, DE, CZ; hạn chế ở nơi khác	Được hỗ trợ rộng rãi

Những Lỗi Thường Gặp

Xuất bản TLSA mà không có DNSSEC. Nếu vùng của bạn không được ký DNSSEC, bản ghi TLSA sẽ bị bỏ qua. Tệ hơn, một số triển khai có thể coi TLSA không được ký là tín hiệu không yêu cầu TLS, làm giảm bảo mật.
Quên cập nhật TLSA khi xoay khóa. Nếu bạn sử dụng selector 0 (chứng chỉ đầy đủ) và gia hạn chứng chỉ của mình bằng khóa mới, bản ghi TLSA phải được cập nhật trước khi chứng chỉ mới hoạt động. Sử dụng selector 1 (SPKI) và giữ cặp khóa giống nhau trên các gia hạn để tránh điều này.
TLSA trên miền, không phải máy chủ MX. Bản ghi TLSA đi trên tên máy chủ mục tiêu MX (ví dụ: _25._tcp.mail.example.com), không phải trên chính miền. Nếu MX của bạn trỏ đến máy chủ của bên thứ ba, bản ghi TLSA phải nằm trong vùng của họ.
Quay vòng bản ghi TLSA không chính xác. Khi xoay khóa, xuất bản bản ghi TLSA cho cả khóa cũ và khóa mới cùng một lúc. Chỉ xóa bản ghi cũ sau khi chứng chỉ đã được xoay và bộ nhớ đệm DNS đã hết hạn.
Bỏ qua chuỗi tin tưởng DNSSEC. Mọi vùng trong chuỗi từ root đến bản ghi TLSA phải được ký DNSSEC. Sự gián đoạn ở bất kỳ đâu sẽ làm mất hiệu lực toàn bộ chuỗi.

Tác Động Khả Năng Gửi

Đảm bảo TLS mạnh nhất. DANE cung cấp bằng chứng mã hóa về danh tính của máy chủ từ DNS một mình. Không có sự xâm phạm CA, không có cửa sổ TOFU — bảo mật từ lần kết nối đầu tiên.
Được triển khai rộng rãi ở Châu Âu. Hà Lan, Đức và Cộng hòa Séc có áp dụng DANE cao cho thư chính phủ và tổ chức. Nếu bạn gửi đến các khu vực này, hỗ trợ DANE là một lợi thế đáng kể.
Hỗ trợ gốc Postfix. Postfix có hỗ trợ DANE tích hợp (smtp_tls_security_level = dane). Đối với những người gửi sử dụng Postfix, DANE "chỉ hoạt động" khi miền nhận có bản ghi TLSA.
Bổ sung với MTA-STS. Triển khai cả hai. Những người gửi hỗ trợ DANE sẽ sử dụng nó (đảm bảo mạnh hơn); những người gửi chỉ hỗ trợ MTA-STS sẽ sử dụng nó. Cả hai đều tốt hơn TLS cơ hội một mình.