DNS-PERSIST-01: Mô hình mới để xác minh thử thách dựa trên DNS

• DNS-PERSIST-01 của Let's Encrypt là một mô hình thử thách ACME mới sử dụng bản ghi xác thực duy trì liên tục, thay thế cho việc xác minh lặp lại của phương thức DNS-01 hiện có
• Cách làm này chứng minh quyền kiểm soát tên miền trong dài hạn thông qua bản ghi TXT được ràng buộc với một tài khoản ACME và CA cụ thể
• Giảm gánh nặng thay đổi DNS và triển khai thông tin xác thực API, từ đó đồng thời tăng cường hiệu quả vận hành và bảo mật
• Hỗ trợ các tính năng kiểm soát chi tiết như tùy chọn chính sách (policy=wildcard), thời điểm hết hạn (persistUntil) và cho phép nhiều CA
• Dự kiến triển khai staging vào cuối quý 1 năm 2026 và rollout chính thức trong quý 2, hứa hẹn đơn giản hóa việc quản lý chứng chỉ trong các môi trường quy mô lớn và tự động hóa cao

---

Giới hạn của phương thức DNS-01

• Thử thách DNS-01 hiện tại yêu cầu tạo token mới mỗi lần phát hành chứng chỉ và thêm bản ghi TXT vào _acme-challenge.
  • Mỗi lần xác minh đều cần cập nhật DNS, gây ra độ trễ lan truyền và làm tăng độ phức tạp của tự động hóa
• Trong các triển khai quy mô lớn, thông tin xác thực DNS API bị phân tán trên nhiều hệ thống, làm tăng rủi ro bảo mật
• Một số người dùng muốn tránh các thay đổi DNS lặp đi lặp lại này

Cấu trúc và cách hoạt động của DNS-PERSIST-01

• Phương thức mới đưa vào khái niệm ủy quyền bền vững (persistent authorization)
  • Chỉ cần thiết lập một lần bản ghi TXT tại _validation-persist. chứa URI của CA và tài khoản ACME
  • Sau đó có thể tái sử dụng cùng bản ghi này khi phát hành và gia hạn
• Ví dụ:

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• Nhờ đó, thay đổi DNS được loại khỏi quy trình phát hành, giúp nâng cao hiệu quả vận hành

Điểm cân bằng giữa bảo mật và vận hành

• Với DNS-01, quyền ghi DNS là tài sản quan trọng nhất, còn với DNS-PERSIST-01, trọng tâm là bảo vệ khóa tài khoản ACME
• Sau khi cấu hình ban đầu, có thể hạn chế quyền ghi DNS để giảm bề mặt tấn công
• Tuy nhiên, do cấu trúc xác thực duy trì liên tục, rủi ro sẽ lớn hơn nếu khóa tài khoản bị lộ, nên cần tăng cường quản lý bảo mật tài khoản

Tính năng kiểm soát phạm vi và thời hạn

• Theo mặc định, chỉ có hiệu lực vô thời hạn với FQDN đã được xác minh
• Có thể mở rộng sang wildcard và tên miền con bằng tùy chọn policy=wildcard

  "policy=wildcard"  
  

• Thuộc tính persistUntil cho phép chỉ định thời điểm hết hạn (tính bằng giây UTC)
  • Cần gia hạn trước khi hết hạn, vì vậy hệ thống giám sát là bắt buộc

  "persistUntil=1767225600"  
  

• Nếu muốn cho phép nhiều CA cùng lúc, hãy thêm bản ghi TXT riêng cho từng CA vào _validation-persist.

Lộ trình triển khai và tình trạng hiện thực

• Cuộc bỏ phiếu CA/Browser Forum SC-088v3 đã được thông qua nhất trí vào tháng 10 năm 2025, và Nhóm công tác IETF ACME đã chấp nhận bản nháp
• Đã được hỗ trợ trong Pebble (phiên bản rút gọn của Boulder), đồng thời phần hiện thực cho client lego-cli cũng đang được tiến hành
• Dự kiến staging vào cuối quý 1 năm 2026 và triển khai chính thức trong quý 2
• Mô hình này phù hợp với các lĩnh vực mà cách làm cũ kém hiệu quả, như IoT, môi trường đa tenant và môi trường phát hành chứng chỉ số lượng lớn

Bối cảnh về Let's Encrypt và ISRG

• Let's Encrypt là tổ chức chứng thực (CA) miễn phí, tự động hóa và mở do tổ chức phi lợi nhuận ISRG vận hành
• Báo cáo thường niên năm 2025 của ISRG đã công bố các hoạt động liên quan đến bảo mật Internet

[GN⁺]

Ý kiến trên Hacker News

• Tôi thật sự rất vui khi thấy tin này
  Khi dùng bind làm nameserver có thẩm quyền, tôi cấu hình để giới hạn hmac-secret sao cho mỗi web server chỉ có thể cập nhật các bản ghi TXT thuộc về chính nó
  Như vậy, ngay cả khi server “bob” bị xâm nhập, nó cũng chỉ có thể lấy chứng chỉ cho miền “bob”
  Ví dụ cấu hình dùng update-policy để giới hạn mỗi key chỉ được sửa các subdomain dưới _acme-challenge

  • Nếu sẵn sàng vận hành một DNS server riêng thay vì bind, acmedns cung cấp tính năng tương tự
    Khi tạo tài khoản mới, bạn sẽ được cấp một subdomain riêng, rồi chỉ cần trỏ CNAME của miền challenge sang subdomain đó thì chỉ tài khoản ấy mới có thể cập nhật vùng đó

• Tôi nghĩ tính năng này giải quyết một bất tiện lớn trong vận hành thực tế
  Tuy vậy, tôi lo ngại về việc lộ định danh của tài khoản quản trị
  Tên người dùng không được bảo vệ nghiêm ngặt như thông tin xác thực, nhưng vẫn có thể giúp kẻ tấn công xác định mục tiêu
  Khả năng cao là các dịch vụ như Shodan sẽ lập chỉ mục những ID này và cung cấp tra cứu ngược

  • accounturi trong bản ghi CAA cũng đã làm lộ định danh tài khoản rồi, nên ở mức nào đó thì chuyện này vốn đã công khai
    Tôi còn nghĩ sẽ tốt hơn nếu định dạng của CAA và bản ghi persist thống nhất với nhau
  • Sẽ hay hơn nếu người dùng được cấp một ID ngẫu nhiên như UUID thay cho tài khoản thật để dùng trong accounturi
  • Vì đây cũng chính là tài khoản do ACME client tạo ra, nên tôi không cho rằng rủi ro tra cứu ngược là quá lớn

• Tôi ngạc nhiên khi điểm này không yêu cầu DNSSEC
  Trước đây tôi từng nghĩ DNSSEC khá phiền phức, nhưng giờ có quá nhiều bản ghi ảnh hưởng đến chuỗi tin cậy gốc như CAA, CERT, SSHFP, TXT nên DNS rất dễ bị tấn công MITM
  Đặc biệt là ngay cả nhiều tập đoàn lớn cũng chưa triển khai DNSSEC đúng cách, nên ít nhất điều này cũng nên được nêu như một khuyến nghị

  • Trong bản nháp RFC, việc dùng DNSSEC cũng được khuyến nghị ở mức “SHOULD” (liên kết)
  • DNS vốn đã là điểm lỗi đơn trong việc cấp chứng chỉ TLS từ trước đến nay
    Nếu kẻ tấn công chiếm được DNS, chúng có thể giả mạo chứng chỉ bằng HTTP-01, TLS-ALPN-01 hay DNS-01 đều được
  • Cá nhân tôi thấy TLSA là cách tiếp cận tốt hơn DNSSEC, nhưng đáng tiếc là gần như không có hỗ trợ từ trình duyệt

• Nhờ tính năng này, việc cấp chứng chỉ cho server LAN không lộ ra Internet có lẽ sẽ dễ hơn rất nhiều
  Trong tương lai, có lẽ hầu hết giao diện quản trị sẽ tự tạo sẵn chuỗi để dán vào bản ghi DNS và nhận chứng chỉ Let's Encrypt ngay lập tức

  • Tôi cũng từng thử trong môi trường tương tự, nhưng cấu hình headscale magic DNS phức tạp hơn tưởng tượng nên cuối cùng lại quay về gia hạn thủ công

• Nếu bạn dùng certbot, có thể theo dõi tình trạng hỗ trợ tính năng này trong GitHub issue

• Trước đây tôi từng hoài nghi về việc phát hành chứng chỉ ngắn hạn, nhưng sau khi thấy chứng chỉ địa chỉ IP và xác minh HTTP-01 thì đã đổi ý
  Giờ tôi không lưu chứng chỉ lên đĩa nữa, mà để một background thread kiểm tra chứng chỉ mới mỗi 24 giờ
  Cách này cho phép tạo ra giải pháp self-host mà người dùng chỉ cần triển khai phần mềm lên VM là có thể đưa vào vận hành trong vòng 5 phút
  Kết hợp với dịch vụ như checkip.amazonaws.com thì có thể tự động hóa hoàn toàn việc triển khai

  • Tuy nhiên, giới hạn cấp phát của Let's Encrypt là không thể thương lượng, nên nếu yêu cầu quá thường xuyên thì vẫn có nguy cơ phải chờ
  • Nếu hoàn toàn không lưu chứng chỉ, tính sẵn sàng sẽ phụ thuộc vào uptime của LE, nên vẫn cần lưu trữ ở mức tối thiểu

• Cuối cùng thì việc tự động hóa chứng chỉ cho web service chỉ dùng nội bộ có vẻ đã trở nên dễ dàng hơn
  Cảm giác như vấn đề vận hành lớn nhất từ trước đến nay cuối cùng đã được giải quyết, nên tôi rất vui

• Phần còn thiếu ở đây là xác minh quyền sở hữu tài khoản ACME
  Hầu hết công cụ tự động đều tự tạo tài khoản nên người dùng không trực tiếp xử lý, nhưng giờ sẽ cần chuyển thông tin xác thực để chứng minh quyền sở hữu tài khoản cho nhà cung cấp ACME
  Nếu Let's Encrypt không thể tạo token bị giới hạn theo từng miền, có thể sẽ phải tạo tài khoản riêng cho mỗi miền

  • Nhưng tài khoản ACME vốn đã có thông tin xác thực để đăng nhập, và quyền sở hữu miền cũng được xác minh qua DNS hoặc HTTP challenge, nên
    nếu những thông tin xác thực hoặc endpoint đó bị chiếm đoạt thì thực ra đã là một sự cố lớn hơn nhiều rồi

• Đây thật sự là tin vui với người dùng Dynamic DNS
  Ví dụ với các dịch vụ như Namecheap, nơi yêu cầu thay đổi chỉ được gửi từ IP cố định, giờ chỉ cần thiết lập một lần là có thể tự động gia hạn
  Tôi chắc chắn sẽ thử khi hiện đại hóa homelab của mình

• Nếu tôi không hiểu nhầm, thì có phải bất kỳ ai kiểm soát DNS server của miền tôi, hoặc
  chặn được lưu lượng giữa Let's Encrypt và DNS server, đều có thể lấy chứng chỉ TLS cho miền của tôi hay không?
  DNS-01 cũng vậy, nhưng với cách này thì có vẻ còn dễ hơn vì kẻ tấn công chỉ cần đưa tài khoản LE của họ vào phản hồi DNS
  Tôi tự hỏi liệu thay vào đó đưa trực tiếp chứng chỉ công khai của tôi vào DNS có tốt hơn không

  • Nếu bạn không thể tin nhà cung cấp DNS của mình, thì bản thân mối quan hệ đó đã là vấn đề rồi
    Nếu ai đó có thể MITM lưu lượng giữa LE và DNS server, thì bạn đã ở trong một tình huống nghiêm trọng hơn nhiều
  • Người kiểm soát DNS có thể lấy chứng chỉ từ bất kỳ CA nào
    Nếu họ có thể thay đổi DNS, thì không có cách nào ngăn việc cấp chứng chỉ cả
  • Nếu kiểm soát được DNS thì họ cũng có thể thực hiện HTTP challenge, nên về cơ bản miền đó đã thuộc về họ
  • Các CA giảm thiểu kiểu tấn công mạng này bằng cách truy vấn DNS từ nhiều vị trí khác nhau
    Let's Encrypt đã vận hành như vậy từ nhiều năm nay, và từ 2024 đây là yêu cầu bắt buộc với mọi CA
    Liên kết quy định CAB Forum
  • Cách tiếp cận này thực ra là điều DANE hướng tới
    Tài liệu liên quan