DNS-PERSIST-01: DNS 기반 챌린지 검증을 위한 새로운 모델

(letsencrypt.org)

DNS-PERSIST-01은 기존 DNS-01 방식의 반복 검증을 대체해, 지속적인 인증 레코드를 사용하는 새로운 ACME 챌린지 모델
이 방식은 특정 ACME 계정과 CA에 바인딩된 TXT 레코드를 통해 도메인 제어권을 장기적으로 증명
DNS 변경과 API 자격 증명 배포 부담을 줄여, 운영 효율성과 보안을 동시에 강화
정책 옵션(policy=wildcard) , 만료 시점(persistUntil) , 다중 CA 허용 등 세밀한 제어 기능을 지원
2026년 1분기 말 스테이징, 2분기 본격 롤아웃 예정으로, 대규모·자동화 환경의 인증 관리 단순화 기대

DNS-01 방식의 한계

기존 DNS-01 챌린지는 인증서 발급 시마다 새로운 토큰을 생성하고 _acme-challenge.<도메인>에 TXT 레코드를 추가해야 함
- 각 검증마다 DNS 업데이트가 필요하며, 전파 지연과 자동화 복잡성이 발생
대규모 배포에서는 DNS API 자격 증명이 여러 시스템에 분산되어 보안 위험 증가
일부 구독자는 이러한 반복적 DNS 변경을 피하고 싶어 함

DNS-PERSIST-01의 구조와 작동 방식

새로운 방식은 지속적 권한 부여(persistent authorization) 개념을 도입
- _validation-persist.<도메인>에 CA와 ACME 계정 URI를 포함한 TXT 레코드를 한 번만 설정
- 이후 발급 및 갱신 시 동일 레코드를 재사용 가능

예시:

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

이로써 DNS 변경이 발급 경로에서 제거, 운영 효율성 향상

보안 및 운영상의 균형점

DNS-01에서는 DNS 쓰기 권한이 주요 자산이었으나, DNS-PERSIST-01에서는 ACME 계정 키 보호가 핵심
초기 설정 후에는 DNS 쓰기 접근을 제한할 수 있어 공격 표면 감소
단, 지속적 인증 구조로 인해 계정 키 유출 시 위험이 커지므로 계정 보안 관리 강화 필요

범위 및 수명 제어 기능

기본적으로 검증된 FQDN에만 무기한 유효
policy=wildcard 옵션으로 와일드카드 및 하위 도메인까지 확장 가능
```
"policy=wildcard"
```
persistUntil 속성으로 만료 시점(UTC 초 단위) 을 지정 가능
- 만료 전 갱신 필요, 모니터링 체계 필수
```
"persistUntil=1767225600"
```
여러 CA를 동시에 허용하려면 _validation-persist.<도메인>에 CA별 TXT 레코드를 추가

도입 일정 및 구현 현황

CA/Browser Forum SC-088v3 투표가 2025년 10월 만장일치로 통과, IETF ACME 워킹그룹이 초안 채택
Pebble(Boulder의 축소판)에서 이미 지원 중이며, lego-cli 클라이언트 구현도 진행 중
2026년 1분기 말 스테이징, 2분기 본격 배포 예정
이 모델은 IoT, 멀티테넌트, 대량 인증서 발급 환경 등 기존 방식이 비효율적인 영역에 적합

Let's Encrypt 및 ISRG 배경

Let's Encrypt는 비영리단체 ISRG가 운영하는 무료·자동화·오픈 인증기관(CA)
2025년 연례 보고서에서 ISRG의 인터넷 보안 관련 활동 공개

▲

GN⁺ 2시간전 [-]

Hacker News 의견들

이 소식을 보게 되어 정말 기쁨
나는 bind를 권한 네임서버로 쓰는 경우, 각 웹서버가 자신에게 해당하는 TXT 레코드만 갱신하도록 hmac-secret을 제한할 수 있게 설정함
이렇게 하면 “bob” 서버가 침해되더라도 “bob” 도메인에 대한 인증서만 발급받을 수 있음
설정 예시는 update-policy를 통해 각 키가 _acme-challenge 하위 도메인만 수정하도록 제한함
- bind 대신 별도의 DNS 서버를 운영할 의향이 있다면, acmedns가 비슷한 기능을 제공함
  새 계정을 만들면 고유한 서브도메인이 부여되고, 챌린지 도메인을 그 서브도메인으로 CNAME 처리하면 해당 계정만 그 영역을 갱신할 수 있음
이 기능은 실제 운영상의 큰 불편함을 해결한다고 생각함
다만 관리 계정의 식별자 노출이 걱정임
사용자 이름은 자격 증명만큼 보호되지 않지만, 공격자가 공격 대상을 파악하는 단서가 될 수 있음
Shodan 같은 서비스가 이런 ID를 인덱싱해 역조회 서비스를 제공할 가능성이 큼
- CAA 레코드의 accounturi도 이미 계정 식별자를 노출하므로, 어느 정도는 이미 공개된 셈임
  오히려 CAA와 persist 레코드 포맷이 일치하는 게 낫다고 생각함
- 사용자에게 실제 계정 대신 UUID 같은 임의 ID를 제공해 accounturi에 쓰게 하면 좋겠음
- ACME 클라이언트에서 만드는 계정과 동일하므로, 역조회 위험은 크지 않다고 봄
DNSSEC을 요구하지 않는 점이 놀라움
예전엔 DNSSEC이 번거롭다고 생각했지만, 이제는 CAA, CERT, SSHFP, TXT 등 루트 신뢰를 좌우하는 레코드가 많아져 MITM 공격에 취약해짐
특히 대기업조차 DNSSEC을 제대로 적용하지 않는 경우가 많아, 최소한 권장 사항으로라도 명시해야 한다고 생각함
- RFC 초안에서도 DNSSEC 사용을 “SHOULD”로 권장하고 있음 (링크)
- DNS는 원래부터 TLS 인증서 발급의 단일 실패 지점이었음
  공격자가 DNS를 장악하면 HTTP-01, TLS-ALPN-01, DNS-01 어떤 방식으로도 인증서를 위조할 수 있음
- 개인적으로는 DNSSEC보다 TLSA가 더 나은 접근이라 생각하지만, 브라우저 지원이 거의 없어 아쉬움
이 기능 덕분에 인터넷에 노출되지 않은 LAN 서버용 인증서 발급이 훨씬 쉬워질 것 같음
앞으로 대부분의 관리자 UI에서 DNS 레코드에 붙여넣을 문자열을 자동 생성해 바로 Let's Encrypt 인증서를 받을 수 있을 것 같음
- 나도 비슷한 환경에서 시도했지만, headscale magic DNS 설정이 생각보다 복잡해서 결국 수동 갱신으로 돌림
certbot 사용자라면 이 기능 지원 현황을 GitHub 이슈에서 추적할 수 있음
예전엔 단기 인증서 발급에 회의적이었지만, IP 주소 인증서와 HTTP-01 검증을 보고 생각이 바뀜
이제는 인증서를 디스크에 저장하지 않고, 백그라운드 스레드가 24시간마다 새 인증서를 확인함
이렇게 하면 사용자가 VM에 소프트웨어를 배포해 5분 내로 운영 가능한 셀프호스트 솔루션을 만들 수 있음
checkip.amazonaws.com 같은 서비스와 결합하면 완전 자동화된 배포가 가능함
- 다만 Let's Encrypt의 발급 제한은 협상 불가라, 너무 자주 요청하면 대기해야 하는 위험이 있음
- 인증서를 전혀 저장하지 않으면 가용성이 LE의 업타임에 의존하게 되므로, 최소한의 저장은 필요함
드디어 내부 전용 웹서비스용 인증서를 자동화하기 쉬워진 것 같음
지금까지의 가장 큰 운영상 문제를 해결해준 느낌이라 매우 반가움
여기서 빠진 부분은 ACME 계정 소유 검증임
대부분 자동화 도구가 계정을 생성하므로 사용자가 직접 다루지 않지만, 이제는 계정 소유를 증명할 자격 증명을 ACME 제공자에게 전달해야 함
Let's Encrypt가 도메인별로 제한된 토큰을 만들 수 없다면, 각 도메인마다 별도 계정을 만들어야 할 수도 있음
- 하지만 ACME 계정에는 이미 인증용 자격 증명이 있고, DNS나 HTTP 챌린지를 통해 도메인 소유를 검증하므로
  만약 그 자격 증명이나 엔드포인트가 탈취된다면, 이미 훨씬 더 큰 문제가 발생한 상태임
Dynamic DNS 사용자에게는 정말 반가운 소식임
예를 들어 Namecheap처럼 변경 요청이 고정 IP에서만 가능하던 경우, 이제 한 번 설정해두면 자동 갱신이 가능함
홈랩을 현대화하면서 꼭 시도해볼 예정임
혹시 내가 잘못 이해한 게 아니라면, 내 도메인의 DNS 서버를 제어하는 사람이나
Let's Encrypt와 DNS 서버 사이의 트래픽을 가로채는 사람이 내 도메인용 TLS 인증서를 발급받을 수 있는 것 아닌가 하는 의문이 있음
DNS-01도 마찬가지지만, 이번 방식은 공격자가 자신의 LE 계정을 DNS 응답에 넣기만 하면 되니 더 쉬워 보임
차라리 내 공개 인증서를 DNS에 직접 넣는 게 낫지 않을까 싶음
- DNS 제공자를 신뢰하지 못한다면, 그 관계 자체가 문제임
  LE와 DNS 서버 간 트래픽을 MITM할 수 있다면 이미 훨씬 심각한 상황임
- DNS를 제어하는 사람은 어떤 CA에서든 인증서를 발급받을 수 있음
  DNS를 바꿀 수 있다면, 인증서 차단 방법은 없음
- DNS를 통제한다면 HTTP 챌린지도 수행 가능하므로, 사실상 그 도메인은 그 사람의 것임
- CA들은 이런 네트워크 공격 완화를 위해 여러 지점에서 DNS를 조회함
  Let's Encrypt는 이미 수년 전부터 이렇게 운영 중이며, 2024년부터 모든 CA의 의무사항임
  CAB Forum 규정 링크
- 이런 접근은 사실 DANE이 취하는 방식임
  관련 자료

답변달기