[2026] TLSA Record là gì? | Hướng Dẫn Cách Tạo Bản Ghi TLSA Chuẩn Nhất

TLSA record là bản ghi DNS được sử dụng trong cơ chế DANE (DNS-based Authentication of Named Entities) nhằm liên kết thông tin chứng chỉ TLS với tên miền, giúp tăng cường khả năng xác thực và bảo vệ kết nối khỏi các cuộc tấn công giả mạo. Việc cấu hình đúng bản ghi này không chỉ nâng cao độ tin cậy cho dịch vụ mà còn hỗ trợ quản trị viên kiểm soát chứng chỉ hiệu quả hơn. Cùng Vinahost tìm hiểu TLSA hoạt động như thế nào, cấu trúc gồm những thành phần nào và cách tạo bản ghi TLSA chuẩn ra sao qua bài viết dưới đây.

1. TLSA Record là gì?

TLSA record (Transport Layer Security Authentication) là một loại bản ghi DNS đặc biệt, được sử dụng để liên kết chứng chỉ TLS/SSL hoặc khóa công khai của máy chủ với tên miền và cổng dịch vụ cụ thể. Một số đặc điểm chính gồm:

• Mục đích: Liên kết chứng chỉ TLS/SSL hoặc public key của máy chủ trực tiếp với tên miền và cổng dịch vụ, giúp tăng cường khả năng xác thực kết nối.
• Cơ chế hoạt động: Bản ghi này hoạt động dựa trên giao thức bảo mật DANE (DNS-Based Authentication of Named Entities). DANE cho phép bạn công bố thông tin “chứng chỉ hợp lệ” của dịch vụ ngay trong DNS để phía máy khách (client) có thể đối chiếu trực tiếp khi thiết lập kết nối.
• Tăng cường bảo mật: Client có thể kiểm tra chứng chỉ TLS mà máy chủ cung cấp dựa trên thông tin được công bố trong DNS, từ đó hạn chế nguy cơ sử dụng chứng chỉ không hợp lệ hoặc bị giả mạo.
• Điều kiện tiên quyết: Bản ghi TLSA chỉ hoạt động và thực sự đáng tin cậy khi tên miền của bạn đã được kích hoạt DNSSEC (mã hóa chữ ký số cho DNS). Nếu DNSSEC bị tắt, quá trình xác thực TLSA sẽ thất bại hoàn toàn).

2. Cấu trúc chi tiết của một bản ghi TLSA record

Bản ghi TLSA có cấu trúc gồm 4 trường dữ liệu chính, mỗi trường đảm nhận một vai trò riêng trong việc xác định và xác thực chứng chỉ TLS cho một dịch vụ cụ thể. Về tổng thể, một TLSA record được chia thành hai phần:

• Phần tên bản ghi: Gắn với cổng (port), giao thức (protocol) và tên máy chủ (host) mà dịch vụ TLS đang sử dụng.
• Phần dữ liệu TLSA: Gồm 4 trường quan trọng là Usage, Selector, Matching Type và Certificate Association Data, dùng để xác định cách thức và dữ liệu được sử dụng khi xác thực chứng chỉ.

Định dạng khai báo chuẩn của bản ghi TLSA trong hệ thống DNS được trình bày như sau:

_<port>._<protocol>.<host>. TTL IN TLSA <usage> <selector> <matching_type> <certificate_association_data>

2.1. Phần tên bản ghi (Owner name)

Phần Owner Name xác định dịch vụ cụ thể mà bản ghi TLSA áp dụng, được xây dựng dựa trên cổng (Port), giao thức (Protocol) và tên máy chủ (Host). Các thành phần gồm:

• Port (Cổng): Xác định số cổng mà máy chủ dịch vụ đang lắng nghe và cung cấp kết nối TLS. Một số cổng phổ biến như 443 cho HTTPS, 25 hoặc 587 cho SMTP.
• Protocol (Giao thức): Xác định giao thức truyền tải được sử dụng cho dịch vụ. Phổ biến nhất là _tcp đối với các dịch vụ TLS chạy trên TCP. Ngoài ra, TLSA cũng có thể sử dụng _udp hoặc _sctp tùy theo loại dịch vụ.
• Host (Tên máy chủ): Xác định máy chủ hoặc tên miền đang cung cấp dịch vụ cần cấu hình TLSA, chẳng hạn example.com hoặc mail.example.com.

Ví dụ, với dịch vụ HTTPS trên cổng 443 của example.com, phần Owner Name sẽ có dạng _443._tcp.example.com.

2.2. Phần dữ liệu của bản ghi (TLSA Data Fields)

Phần dữ liệu của TLSA record gồm 4 trường thông tin chính: Usage, Selector, Matching Type và Certificate Association Data. Các trường này phối hợp với nhau để xác định cách thức lựa chọn, đối chiếu và xác thực chứng chỉ TLS mà máy chủ cung cấp.

• Usage (Mục đích sử dụng): Xác định cách client sử dụng dữ liệu liên kết chứng chỉ trong quá trình xác thực TLS. Giá trị từ 0 đến 3, gồm:
  • 0 – CA Constraint: Chứng chỉ phải được xác thực bởi một Certificate Authority (CA) phù hợp trong chuỗi tin cậy.
  • 1 – Service Certificate Constraint: Chứng chỉ được cung cấp bởi dịch vụ phải khớp với chứng chỉ được chỉ định trong bản ghi TLSA.
  • 2 – Trust Anchor Assertion: Chỉ định chứng chỉ hoặc khóa công khai cụ thể làm điểm neo tin cậy (Trust Anchor) mà không phụ thuộc vào CA công cộng.
  • 3 – Domain-Issued Certificate: Cho phép sử dụng chứng chỉ hoặc khóa công khai được chính tên miền chỉ định, không yêu cầu chứng nhận bởi CA công cộng.
• Selector (Trình chọn): Xác định phần nào của chứng chỉ TLS được sử dụng để đối chiếu với dữ liệu liên kết. Giá trị từ 0 đến 1, gồm:
  • 0 – Full Certificate: Sử dụng toàn bộ chứng chỉ TLS để đối chiếu.
  • 1 – Subject Public Key Info (SPKI): Chỉ sử dụng phần thông tin khóa công khai (SPKI) của chứng chỉ.
• Matching Type (Loại khớp): Xác định cách dữ liệu chứng chỉ hoặc khóa công khai được biểu diễn trong bản ghi TLSA. Giá trị từ 0 đến 2, gồm:
  • 0 – Exact Match: So sánh nguyên bản chứng chỉ trực tiếp (không dùng mã hóa băm)
  • 1 – SHA-256: Sử dụng giá trị băm được tạo bằng thuật toán SHA-256 để so sánh.
  • 2 – SHA-512: Sử dụng giá trị băm được tạo bằng thuật toán SHA-512 để so sánh.
• Certificate Association Data (Dữ liệu liên kết chứng chỉ):  Chứa dữ liệu dùng để đối chiếu với chứng chỉ TLS của máy chủ. Tùy thuộc vào Selector và Matching Type, trường này có thể chứa dữ liệu chứng chỉ, khóa công khai hoặc giá trị băm (hash/fingerprint), thường được biểu diễn dưới dạng chuỗi Hex.

3. Tại sao cần cấu hình bản ghi TLSA?

Bản ghi TLSA hoạt động cùng cơ chế DANE và DNSSEC, cho phép chủ sở hữu tên miền công bố thông tin chứng chỉ hoặc khóa công khai của dịch vụ ngay trên DNS. Nhờ đó, client có thể truy vấn và đối chiếu thông tin này với chứng chỉ được máy chủ cung cấp trong quá trình thiết lập kết nối TLS. Việc cấu hình TLSA mang lại một số lợi ích đáng chú ý:

• Giảm phụ thuộc vào hệ thống CA truyền thống: TLSA bổ sung thêm một lớp xác thực độc lập tại tầng DNS, giúp chủ sở hữu tên miền chủ động xác định chứng chỉ hoặc khóa công khai hợp lệ cho từng dịch vụ.
• Hạn chế nguy cơ sử dụng chứng chỉ giả mạo: TLSA giúp client kiểm tra chứng chỉ dựa trên thông tin được công bố trong DNS. Hạn chế triệt để rủi ro hacker tấn công và chèn chứng chỉ giả mạo, ngay cả khi họ đã kiểm soát hoặc lợi dụng được một đơn vị chứng thực chứng chỉ (CA) uy tín.
• Tăng khả năng chống tấn công trung gian (MITM) & Downgrade: Khi kết hợp với DNSSEC và DANE, TLSA giúp tăng cường khả năng xác thực máy chủ và hạn chế nguy cơ kẻ tấn công chèn chứng chỉ giả mạo trong quá trình thiết lập kết nối. Đồng thời, với các dịch vụ có cơ chế nâng cấp kết nối lên TLS, việc triển khai DANE đúng cách có thể góp phần hạn chế nguy cơ bị ép sử dụng kết nối không mã hóa hoặc hạ cấp bảo mật.
• Hỗ trợ nhiều loại dịch vụ TLS: TLSA không chỉ được sử dụng cho HTTPS mà còn có thể áp dụng cho các dịch vụ như SMTP, SIP và nhiều giao thức khác sử dụng TLS. Điều này giúp quản trị viên kiểm soát chứng chỉ theo từng dịch vụ và cổng cụ thể.
• Tăng quyền kiểm soát chứng chỉ: Thay vì chỉ dựa vào danh sách CA được hệ thống tin cậy, quản trị viên có thể chủ động khai báo chứng chỉ hoặc public key hợp lệ thông qua DNS, giúp việc quản lý và xác thực dịch vụ TLS chặt chẽ hơn.

4. Hướng dẫn chi tiết cách tạo bản ghi TLSA bằng OpenSSL

OpenSSL cung cấp các công cụ cần thiết để lấy thông tin từ chứng chỉ TLS và tạo Certificate Association Data cho bản ghi TLSA. Tùy vào trường hợp cụ thể, bạn có thể sử dụng file chứng chỉ có sẵn hoặc lấy chứng chỉ trực tiếp từ dịch vụ đang chạy.

4.1. Phương pháp 1: Trích xuất từ file chứng chỉ sẵn có (server.crt)

Phương pháp này phù hợp khi bạn đã có file chứng chỉ TLS của máy chủ. Quy trình gồm hai bước chính: trích xuất Subject Public Key Info (SPKI) từ chứng chỉ và tạo giá trị hash SHA-256 để sử dụng trong TLSA record.

Bước 1: Trích xuất public key từ chứng chỉ

Sử dụng lệnh openssl x509 để lấy public key từ file server.crt:

openssl x509 -in server.crt -noout -pubkey > pubkey.pem

Bước 2: Chuyển SPKI sang DER và tạo hash SHA-256

Tiếp theo, sử dụng openssl pkey để đọc public key từ file pubkey.pem và chuyển đổi sang định dạng DER nhằm chuẩn bị dữ liệu cho bước tạo mã băm SHA-256.

openssl pkey -pubin -in pubkey.pem -outform DER | \
  openssl sha256 | awk '{print $2}'

Kết quả nhận được là một chuỗi Hex. Giá trị này được sử dụng làm Certificate Association Data trong bản ghi TLSA với selector = 1 và matching_type = 1.

4.2. Phương pháp 2: Lấy chứng chỉ trực tiếp từ dịch vụ đang chạy

Nếu không có sẵn file chứng chỉ, bạn có thể sử dụng openssl s_client để kết nối đến dịch vụ TLS và lấy chứng chỉ trực tiếp từ máy chủ.

Để lấy chứng chỉ TLS trực tiếp từ máy chủ, sử dụng openssl s_client để thiết lập kết nối đến dịch vụ trên cổng 443. Tham số -servername được dùng để chỉ định hostname cần truy vấn, sau đó openssl x509 chuyển chứng chỉ nhận được sang định dạng PEM và lưu vào file server.crt.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null\ | openssl x509 -outform PEM > server.crt

Lệnh trên lấy chứng chỉ mà máy chủ cung cấp và lưu dưới dạng file server.crt. Tham số -servername giúp gửi SNI (Server Name Indication), đặc biệt cần thiết khi máy chủ lưu trữ nhiều website hoặc dịch vụ trên cùng một địa chỉ IP.

Sau khi có file chứng chỉ, thực hiện lại các bước trong Phương pháp 1 để trích xuất SPKI và tạo hash SHA-256.

Cuối cùng, ghép giá trị hash thu được với bộ tham số TLSA đã lựa chọn. Ví dụ:

3 1 1 <certificate_association_data>

Trong đó 3 là Usage, 1 là Selector sử dụng SPKI, 1 là Matching Type SHA-256 và phần còn lại là chuỗi Hex được tạo từ public key.

5. Cách thêm bản ghi TLSA vào hệ thống DNS

Sau khi đã tạo được đầy đủ các giá trị Usage, Selector, Matching Type và Certificate Association Data từ OpenSSL, bước tiếp theo là khai báo TLSA record trên hệ thống DNS. Tùy vào cách quản lý DNS, bạn có thể thực hiện thông qua giao diện Control Panel hoặc chỉnh sửa trực tiếp file zone.

Cấu hình TLSA trên giao diện DNS (Control Panel)

Trước tiên, cần xác định Owner Name theo cấu trúc _<port>._<protocol>.<host>.. Chẳng hạn, với dịch vụ HTTPS của example.com trên cổng 443/TCP, tên bản ghi là:

_443._tcp.example.com.

Khi tạo bản ghi TLSA trên Control Panel, điền các thông tin tương ứng:

• Name/Host: Nhập _443._tcp hoặc _443._tcp.example.com, tùy hệ thống DNS có tự động nối thêm tên miền hay không.
• Type: Chọn loại bản ghi TLSA.
• TTL: Thiết lập thời gian cache DNS, chẳng hạn 3600 giây (1 giờ).
• Usage: Nhập giá trị đã lựa chọn, ví dụ 3.
• Selector: Nhập 1 nếu sử dụng SPKI để đối chiếu.
• Matching Type: Nhập 1 nếu sử dụng SHA-256.
• Data/Certificate Association Data: Dán chuỗi Hex được tạo từ bước xử lý chứng chỉ bằng OpenSSL.

Cấu hình TLSA bằng file Zone (BIND)

Nếu đang quản lý DNS bằng BIND hoặc hệ thống tương đương, bạn có thể thêm trực tiếp bản ghi vào file zone. Ví dụ:

_443._tcp.example.com. 3600 IN TLSA 3 1 1 0DEFB3A9C4D8E7F6A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8192837465

Trong đó:

• _443._tcp.example.com.: Owner Name, xác định dịch vụ trên cổng 443/TCP của example.com.
• 3600: TTL của bản ghi, tương đương 1 giờ.
• IN: Class Internet.
• TLSA: Loại bản ghi DNS.
• 3 1 1: Lần lượt là Usage = 3, Selector = 1 và Matching Type = 1.
• Chuỗi Hex: Giá trị Certificate Association Data được tạo từ chứng chỉ hoặc SPKI.

6. Cách kiểm tra bản ghi TLSA sau khi cấu hình

Sau khi thêm TLSA record vào hệ thống DNS, bạn nên kiểm tra lại để xác nhận bản ghi đã được khai báo chính xác và có thể truy vấn công khai. Cách kiểm tra sẽ khác nhau tùy vào hệ điều hành đang sử dụng.

6.1. Đối với hệ điều hành Linux/ MacOS

Trên Linux hoặc macOS, có thể sử dụng các công cụ DNS như dig để truy vấn trực tiếp bản ghi TLSA.

Ví dụ, kiểm tra TLSA của dịch vụ HTTPS trên example.com:

dig TLSA _443._tcp.example.com

Để xem riêng phần kết quả trả về, có thể sử dụng:

dig +short TLSA _443._tcp.example.com

Nếu bản ghi đã được cấu hình đúng và DNS đã cập nhật, kết quả sẽ hiển thị các trường Usage, Selector, Matching Type cùng Certificate Association Data. Ví dụ:

3 1 1 0DEFB3A9C4D8E7F6A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D6E7F8192837465

Ngoài ra, có thể chỉ định DNS resolver cụ thể để kiểm tra quá trình phân giải:

dig @1.1.1.1 TLSA _443._tcp.example.com

6.2. Đối với hệ điều hành Windows

Trên Windows, bạn có thể sử dụng PowerShell để truy vấn bản ghi TLSA. Mở PowerShell và chạy:

Resolve-DnsName -Name "_443._tcp.example.com" -Type TLSA

Lệnh sẽ trả về thông tin của bản ghi nếu DNS resolver được sử dụng hỗ trợ truy vấn TLSA.

Trong trường hợp muốn kiểm tra thông qua Command Prompt, có thể sử dụng:

nslookup -type=TLSA _443._tcp.example.com

Tuy nhiên, khả năng hiển thị bản ghi TLSA của nslookup phụ thuộc vào phiên bản Windows và DNS resolver đang sử dụng. Nếu kết quả không hiển thị như mong đợi, PowerShell hoặc công cụ DNS chuyên dụng có thể là lựa chọn phù hợp hơn.

Nếu website đang triển khai TLSA Record, việc kết hợp với DNSSEC giúp tăng độ tin cậy của dữ liệu DNS và hỗ trợ bảo vệ thông tin xác thực được công bố trên hệ thống tên miền. VinaHost cung cấp dịch vụ DNS hỗ trợ DNSSEC, phù hợp cho doanh nghiệp cần tăng cường bảo mật và đảm bảo tính toàn vẹn khi cấu hình TLSA Record.

Sở Hữu Tên Miền Mơ Ước Ngay Hôm Nay Tại VinaHost

Tra cứu

7. Lưu ý quan trọng khi vận hành bản ghi TLSA

Trong quá trình sử dụng TLSA record, việc duy trì dữ liệu đồng bộ với chứng chỉ TLS trên máy chủ là yếu tố quan trọng. Chỉ một sai lệch giữa chứng chỉ thực tế và thông tin được khai báo trong DNS cũng có thể khiến quá trình xác thực DANE không thành công. Một số lưu ý quan trọng cần chú ý:

• Cập nhật đồng bộ khi thay chứng chỉ mới: Mỗi khi gia hạn, thay đổi hoặc thay thế chứng chỉ SSL/TLS trên máy chủ, cần chuẩn bị và cập nhật Certificate Association Data tương ứng trong bản ghi TLSA. Nếu dữ liệu TLSA không khớp với chứng chỉ mà máy chủ cung cấp, quá trình xác thực có thể thất bại và client có thể từ chối thiết lập kết nối.
• Thực hiện Rollout an toàn: Khi thay đổi chứng chỉ, không nên xóa TLSA record cũ ngay lập tức. Có thể triển khai theo trình tự sau để hạn chế nguy cơ gián đoạn dịch vụ:
  • Tạo và thêm TLSA record mới chứa thông tin liên kết với chứng chỉ mới, đồng thời duy trì bản ghi cũ.
  • Cài đặt chứng chỉ TLS mới trên máy chủ dịch vụ.
  • Kiểm tra kết nối và xác minh chứng chỉ mới hoạt động chính xác với TLSA record tương ứng.
  • Xóa TLSA record cũ sau khi chắc chắn các resolver đã cập nhật dữ liệu mới và dịch vụ hoạt động ổn định.
• Kiểm tra trước khi triển khai: Nên kiểm tra lại Owner Name, Usage, Selector, Matching Type và Certificate Association Data trước khi thay đổi DNS hoặc chứng chỉ. Điều này giúp hạn chế lỗi cấu hình có thể khiến dịch vụ TLS không thể xác thực.
• Đảm bảo DNSSEC hoạt động ổn định: TLSA phụ thuộc vào DNSSEC để bảo đảm dữ liệu DNS được xác thực. Vì vậy, cần duy trì DNSSEC chính xác và kiểm tra trạng thái DNSSEC sau những thay đổi liên quan đến DNS.

9. Tổng kết 

Nhìn chung, TLSA record không bắt buộc đối với mọi hệ thống nhưng khi kết hợp với DNSSEC và DANE, đây là giải pháp hữu ích giúp tăng cường xác thực chứng chỉ, hạn chế nguy cơ MITM và kiểm soát chặt chẽ hơn kết nối TLS. Nếu đang vận hành website, mail server hoặc các dịch vụ quan trọng, bạn nên triển khai từng bước, kiểm tra kỹ cấu hình trước khi áp dụng rộng rãi. Hy vọng những hướng dẫn trên đã giúp bạn hiểu rõ bản ghi TLSA là gì và cách tạo, cấu hình chính xác. 

Nếu cần hỗ trợ trong quá trình triển khai, hãy liên hệ Vinahost để được tư vấn và hỗ trợ. Xem thêm tại đây để tìm thêm nhiều thông tin và kiến thức hữu ích về DNS, bảo mật và quản trị hệ thống.

• Email: support@vinahost.vn
• Hotline: 1900 6046
• Livechat: https://livechat.vinahost.vn/chat.php