DNS-PERSIST-01: Model Baru untuk Validasi Tantangan Berbasis DNS

• DNS-PERSIST-01 dari Let's Encrypt adalah model tantangan ACME baru yang menggantikan validasi berulang pada metode DNS-01 lama dengan memakai record otorisasi yang persisten
• Metode ini membuktikan kontrol domain dalam jangka panjang melalui record TXT yang terikat ke akun ACME dan CA tertentu
• Dengan mengurangi perubahan DNS dan beban distribusi kredensial API, pendekatan ini memperkuat efisiensi operasional sekaligus keamanan
• Mendukung fitur kontrol yang rinci seperti opsi kebijakan (policy=wildcard), waktu kedaluwarsa (persistUntil), dan izin untuk banyak CA
• Staging dijadwalkan pada akhir kuartal 1 2026 dan rollout penuh pada kuartal 2, dengan harapan menyederhanakan pengelolaan sertifikat di lingkungan berskala besar dan terotomatisasi

---

Keterbatasan metode DNS-01

• Tantangan DNS-01 yang ada saat ini mengharuskan pembuatan token baru setiap kali sertifikat diterbitkan dan penambahan record TXT di _acme-challenge.
  • Setiap validasi memerlukan pembaruan DNS, yang menimbulkan keterlambatan propagasi dan kompleksitas otomatisasi
• Dalam deployment skala besar, kredensial API DNS tersebar di banyak sistem sehingga meningkatkan risiko keamanan
• Sebagian pelanggan ingin menghindari perubahan DNS yang berulang seperti ini

Struktur dan cara kerja DNS-PERSIST-01

• Metode baru ini memperkenalkan konsep otorisasi persisten (persistent authorization)
  • Cukup atur satu kali record TXT di _validation-persist. yang memuat URI CA dan akun ACME
  • Setelah itu, record yang sama dapat dipakai kembali untuk penerbitan dan perpanjangan
• Contoh:

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

• Dengan demikian, perubahan DNS dihapus dari jalur penerbitan, sehingga efisiensi operasional meningkat

Titik keseimbangan antara keamanan dan operasi

• Pada DNS-01, hak tulis DNS adalah aset utama, sedangkan pada DNS-PERSIST-01 yang paling penting adalah perlindungan kunci akun ACME
• Setelah konfigurasi awal, akses tulis DNS dapat dibatasi sehingga mengurangi permukaan serangan
• Namun, karena struktur otorisasi persisten, kebocoran kunci akun menjadi lebih berisiko sehingga pengelolaan keamanan akun perlu diperkuat

Fitur kontrol cakupan dan masa berlaku

• Secara default, validasi ini berlaku tanpa batas hanya untuk FQDN yang telah diverifikasi
• Opsi policy=wildcard memungkinkan perluasan ke wildcard dan subdomain

  "policy=wildcard"  
  

• Atribut persistUntil dapat dipakai untuk menentukan waktu kedaluwarsa (dalam detik UTC)
  • Perlu diperpanjang sebelum kedaluwarsa, sehingga sistem pemantauan menjadi penting

  "persistUntil=1767225600"  
  

• Untuk mengizinkan beberapa CA sekaligus, tambahkan record TXT per CA di _validation-persist.

Jadwal adopsi dan status implementasi

• Pemungutan suara CA/Browser Forum SC-088v3 disetujui secara bulat pada Oktober 2025, dan IETF ACME Working Group telah mengadopsi draft-nya
• Sudah didukung di Pebble (versi ringkas Boulder), dan implementasi klien lego-cli juga sedang berlangsung
• Staging pada akhir kuartal 1 2026, dengan deployment penuh pada kuartal 2
• Model ini cocok untuk area di mana metode lama tidak efisien, seperti IoT, multi-tenant, dan lingkungan penerbitan sertifikat dalam jumlah besar

Latar belakang Let's Encrypt dan ISRG

• Let's Encrypt adalah CA gratis, otomatis, dan terbuka yang dioperasikan oleh organisasi nirlaba ISRG
• Dalam laporan tahunan 2025, ISRG memaparkan aktivitasnya terkait keamanan internet

[GN⁺]

Komentar Hacker News

• Saya sangat senang melihat kabar ini
  Saat menggunakan bind sebagai nameserver otoritatif, saya mengaturnya agar setiap web server hanya bisa memperbarui record TXT miliknya sendiri dengan membatasi hmac-secret
  Dengan begitu, meskipun server “bob” disusupi, server itu hanya bisa menerbitkan sertifikat untuk domain “bob”
  Contoh konfigurasinya memakai update-policy untuk membatasi tiap key agar hanya bisa mengubah subdomain _acme-challenge

  • Jika Anda bersedia menjalankan server DNS terpisah alih-alih bind, acmedns menyediakan fungsi serupa
    Saat membuat akun baru, Anda akan diberi subdomain unik, lalu jika domain challenge diarahkan dengan CNAME ke subdomain itu, hanya akun tersebut yang bisa memperbarui zona itu

• Saya rasa fitur ini menyelesaikan ketidaknyamanan besar dalam operasional nyata
  Namun saya khawatir soal tereksposnya identifier akun administrasi
  Nama pengguna memang tidak dilindungi seketat kredensial, tetapi tetap bisa menjadi petunjuk bagi penyerang untuk mengidentifikasi target serangan
  Besar kemungkinan layanan seperti Shodan akan mengindeks ID ini dan menyediakan layanan pencarian balik

  • Record CAA accounturi juga sudah mengekspos identifier akun, jadi pada tingkat tertentu ini memang sudah bersifat publik
    Malah menurut saya lebih baik jika format record CAA dan persist selaras
  • Akan bagus jika pengguna diberi ID acak seperti UUID alih-alih akun sebenarnya untuk dipakai di accounturi
  • Karena ini sama dengan akun yang dibuat klien ACME, saya rasa risiko pencarian baliknya tidak terlalu besar

• Cukup mengejutkan bahwa DNSSEC tidak diwajibkan
  Dulu saya menganggap DNSSEC merepotkan, tetapi sekarang ada banyak record yang menentukan root of trust seperti CAA, CERT, SSHFP, dan TXT, sehingga rentan terhadap serangan MITM
  Terutama karena bahkan perusahaan besar pun sering tidak menerapkan DNSSEC dengan benar, saya rasa setidaknya ini perlu dinyatakan sebagai rekomendasi

  • Dalam draft RFC pun penggunaan DNSSEC direkomendasikan sebagai “SHOULD” (tautan)
  • Sejak awal DNS memang merupakan single point of failure untuk penerbitan sertifikat TLS
    Jika penyerang menguasai DNS, mereka bisa memalsukan sertifikat melalui HTTP-01, TLS-ALPN-01, maupun DNS-01
  • Secara pribadi saya menganggap TLSA pendekatan yang lebih baik daripada DNSSEC, tetapi sayangnya dukungan browser hampir tidak ada

• Berkat fitur ini, penerbitan sertifikat untuk server LAN yang tidak terekspos ke internet tampaknya akan jauh lebih mudah
  Ke depannya, sepertinya kebanyakan UI admin akan bisa otomatis membuat string untuk ditempel ke record DNS dan langsung mendapatkan sertifikat Let's Encrypt

  • Saya juga pernah mencoba di lingkungan serupa, tetapi konfigurasi headscale magic DNS ternyata lebih rumit dari dugaan, jadi akhirnya saya kembali ke pembaruan manual

• Jika Anda pengguna certbot, status dukungan fitur ini bisa diikuti lewat isu GitHub

• Dulu saya skeptis terhadap sertifikat berumur pendek, tetapi setelah melihat sertifikat alamat IP dan verifikasi HTTP-01, pandangan saya berubah
  Sekarang saya tidak menyimpan sertifikat di disk, dan thread latar belakang memeriksa sertifikat baru setiap 24 jam
  Dengan begitu, kita bisa membuat solusi self-hosted yang memungkinkan pengguna men-deploy perangkat lunak ke VM dan siap beroperasi dalam 5 menit
  Jika digabungkan dengan layanan seperti checkip.amazonaws.com, deployment yang sepenuhnya otomatis menjadi mungkin

  • Namun batas rate limit penerbitan Let's Encrypt tidak bisa dinegosiasikan, jadi jika meminta terlalu sering ada risiko harus menunggu
  • Jika sertifikat sama sekali tidak disimpan, ketersediaan akan bergantung pada uptime LE, jadi penyimpanan minimal tetap diperlukan

• Akhirnya tampaknya menjadi lebih mudah untuk mengotomatisasi sertifikat bagi web service internal saja
  Rasanya seperti masalah operasional terbesar selama ini akhirnya terselesaikan, jadi saya sangat senang

• Bagian yang hilang di sini adalah verifikasi kepemilikan akun ACME
  Sebagian besar alat otomatisasi membuat akun sendiri sehingga pengguna jarang menanganinya secara langsung, tetapi sekarang kredensial untuk membuktikan kepemilikan akun harus diberikan ke penyedia ACME
  Jika Let's Encrypt tidak bisa membuat token terbatas per domain, mungkin harus dibuat akun terpisah untuk tiap domain

  • Namun akun ACME sudah memiliki kredensial autentikasi, dan kepemilikan domain diverifikasi lewat challenge DNS atau HTTP, jadi
    jika kredensial atau endpoint itu dibajak, berarti sebenarnya sudah terjadi masalah yang jauh lebih besar

• Ini benar-benar kabar baik bagi pengguna Dynamic DNS
  Misalnya pada layanan seperti Namecheap yang hanya mengizinkan permintaan perubahan dari IP tetap, sekarang setelah disetel sekali pembaruan otomatis jadi memungkinkan
  Saya pasti akan mencobanya saat memodernisasi homelab saya

• Kalau saya tidak salah paham, saya bertanya-tanya apakah orang yang mengendalikan server DNS domain saya, atau
  orang yang mencegat trafik antara Let's Encrypt dan server DNS, bisa menerbitkan sertifikat TLS untuk domain saya
  DNS-01 juga sama, tetapi dengan cara ini tampaknya lebih mudah karena penyerang hanya perlu menaruh akun LE mereka sendiri di respons DNS
  Bukankah akan lebih baik kalau saya langsung menaruh sertifikat publik saya di DNS?

  • Jika Anda tidak bisa mempercayai penyedia DNS, hubungan itu sendiri sudah bermasalah
    Jika seseorang bisa melakukan MITM pada trafik antara LE dan server DNS, situasinya sudah jauh lebih serius
  • Orang yang mengendalikan DNS bisa menerbitkan sertifikat dari CA mana pun
    Jika DNS bisa diubah, tidak ada cara untuk memblokir penerbitan sertifikat
  • Jika seseorang mengendalikan DNS, mereka juga bisa menjalankan challenge HTTP, jadi pada dasarnya domain itu memang milik mereka
  • Para CA melakukan lookup DNS dari beberapa titik untuk memitigasi serangan jaringan semacam ini
    Let's Encrypt sudah menjalankan cara ini sejak beberapa tahun lalu, dan sejak 2024 ini menjadi kewajiban bagi semua CA
    Tautan aturan CAB Forum
  • Pendekatan seperti ini sebenarnya adalah yang diambil oleh DANE
    Materi terkait