# DNS-PERSIST-01: DNS 기반 챌린지 검증을 위한 새로운 모델 > Clean Markdown view of GeekNews topic #26825. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26825](https://news.hada.io/topic?id=26825) - GeekNews Markdown: [https://news.hada.io/topic/26825.md](https://news.hada.io/topic/26825.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-20T05:37:36+09:00 - Updated: 2026-02-20T05:37:36+09:00 - Original source: [letsencrypt.org](https://letsencrypt.org/2026/02/18/dns-persist-01.html) - Points: 4 - Comments: 1 ## Topic Body - Let's Encrypt의 **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 레코드를 한 번만 설정 - 이후 발급 및 갱신 시 동일 레코드를 재사용 가능 - 예시: ```dns _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` 옵션으로 **와일드카드 및 하위 도메인**까지 확장 가능 ```dns "policy=wildcard" ``` - `persistUntil` 속성으로 **만료 시점(UTC 초 단위)** 을 지정 가능 - 만료 전 갱신 필요, 모니터링 체계 필수 ```dns "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의 인터넷 보안 관련 활동 공개 ## Comments ### Comment 51436 - Author: neo - Created: 2026-02-20T05:37:36+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47064047) - 이 소식을 보게 되어 정말 기쁨 나는 **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**”로 권장하고 있음 ([링크](https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00#name-dnssec)) - DNS는 원래부터 TLS 인증서 발급의 **단일 실패 지점**이었음 공격자가 DNS를 장악하면 HTTP-01, TLS-ALPN-01, DNS-01 어떤 방식으로도 인증서를 위조할 수 있음 - 개인적으로는 DNSSEC보다 **TLSA**가 더 나은 접근이라 생각하지만, 브라우저 지원이 거의 없어 아쉬움 - 이 기능 덕분에 인터넷에 노출되지 않은 **LAN 서버용 인증서** 발급이 훨씬 쉬워질 것 같음 앞으로 대부분의 관리자 UI에서 DNS 레코드에 붙여넣을 문자열을 자동 생성해 바로 Let's Encrypt 인증서를 받을 수 있을 것 같음 - 나도 비슷한 환경에서 시도했지만, **headscale magic DNS** 설정이 생각보다 복잡해서 결국 수동 갱신으로 돌림 - **certbot** 사용자라면 이 기능 지원 현황을 [GitHub 이슈](https://github.com/certbot/certbot/issues/10549)에서 추적할 수 있음 - 예전엔 단기 인증서 발급에 회의적이었지만, **IP 주소 인증서**와 HTTP-01 검증을 보고 생각이 바뀜 이제는 인증서를 디스크에 저장하지 않고, 백그라운드 스레드가 24시간마다 새 인증서를 확인함 이렇게 하면 사용자가 VM에 소프트웨어를 배포해 **5분 내로 운영 가능**한 셀프호스트 솔루션을 만들 수 있음 [checkip.amazonaws.com](https://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 규정 링크](https://cabforum.org/2024/08/05/ballot-sc067v3-require-domain-validation-and-caa-checks-to-be-performed-from-multiple-network-perspectives-corroboration/) - 이런 접근은 사실 **DANE**이 취하는 방식임 [관련 자료](https://www.sidn.nl/en/modern-internet-standards/e-mail-security-standards)