DNS-PERSIST-01: DNS tabanlı challenge doğrulaması için yeni bir model

• Let's Encrypt'in DNS-PERSIST-01 modeli, mevcut DNS-01 yöntemindeki tekrarlı doğrulamanın yerine kalıcı doğrulama kayıtları kullanan yeni bir ACME challenge modeli sunuyor
• Bu yöntem, belirli bir ACME hesabına ve CA'ya bağlanan TXT kaydı üzerinden alan adı kontrolünü uzun vadeli olarak kanıtlıyor
• DNS değişikliklerini ve API kimlik bilgisi dağıtım yükünü azaltarak hem operasyonel verimliliği hem de güvenliği güçlendiriyor
• Politika seçeneği (policy=wildcard), sona erme zamanı (persistUntil), birden fazla CA'ya izin verme gibi ayrıntılı denetim özelliklerini destekliyor
• 2026'nın 1. çeyreğinin sonunda staging, 2. çeyrekte ise tam rollout planlanıyor; bu da büyük ölçekli ve otomasyon ağırlıklı ortamlarda sertifika yönetimini basitleştirme beklentisi yaratıyor

---

DNS-01 yönteminin sınırları

• Mevcut DNS-01 challenge yaklaşımında, her sertifika verilişinde yeni bir token üretilip _acme-challenge. altına TXT kaydı eklenmesi gerekiyor
  • Her doğrulama için DNS güncellemesi gerektiğinden yayılma gecikmesi ve otomasyon karmaşıklığı ortaya çıkıyor
• Büyük ölçekli dağıtımlarda DNS API kimlik bilgileri birçok sisteme dağıtıldığı için güvenlik riski artıyor
• Bazı aboneler bu tür tekrarlı DNS değişikliklerinden kaçınmak istiyor

DNS-PERSIST-01'in yapısı ve çalışma şekli

• Yeni yaklaşım, kalıcı yetkilendirme (persistent authorization) kavramını devreye alıyor
  • _validation-persist. altında, CA ve ACME hesap URI'sini içeren TXT kaydı yalnızca bir kez ayarlanıyor
  • Sonrasında sertifika verme ve yenileme sırasında aynı kayıt yeniden kullanılabiliyor
• Örnek:

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

• Böylece DNS değişiklikleri sertifika verme akışından çıkarılmış oluyor ve operasyonel verimlilik artıyor

Güvenlik ve operasyon arasındaki denge

• DNS-01'de temel varlık DNS yazma yetkisi iken, DNS-PERSIST-01'de odak noktası ACME hesap anahtarının korunması oluyor
• İlk kurulumdan sonra DNS yazma erişimi sınırlandırılabildiği için saldırı yüzeyi azalıyor
• Ancak kalıcı doğrulama yapısı nedeniyle hesap anahtarı sızarsa risk büyüdüğünden hesap güvenliği yönetiminin güçlendirilmesi gerekiyor

Kapsam ve yaşam süresi denetimi

• Varsayılan olarak doğrulanan FQDN için süresiz geçerli
• policy=wildcard seçeneğiyle wildcard ve alt alan adlarına kadar genişletilebiliyor

  "policy=wildcard"  
  

• persistUntil özniteliği ile sona erme zamanı (UTC epoch saniyesi olarak) belirtilebiliyor
  • Süre dolmadan önce yenileme gerekiyor; izleme sistemi şart

  "persistUntil=1767225600"  
  

• Birden fazla CA'ya aynı anda izin vermek için _validation-persist. altına CA başına TXT kaydı ekleniyor

Benimseme takvimi ve uygulama durumu

• CA/Browser Forum SC-088v3 oylaması 2025 Ekim'de oybirliğiyle geçti; IETF ACME çalışma grubu da taslağı kabul etti
• Pebble (Boulder'ın küçültülmüş sürümü) içinde destek zaten mevcut ve lego-cli istemci uygulaması da geliştiriliyor
• 2026 1. çeyrek sonu staging, 2. çeyrek tam dağıtım planlanıyor
• Bu model, IoT, çok kiracılı yapılar ve yüksek hacimli sertifika üretim ortamları gibi mevcut yöntemin verimsiz kaldığı alanlara uygun

Let's Encrypt ve ISRG arka planı

• Let's Encrypt, kâr amacı gütmeyen ISRG tarafından işletilen ücretsiz, otomatik ve açık bir sertifika otoritesi (CA)
• ISRG, 2025 yıllık raporunda internet güvenliğiyle ilgili faaliyetlerini paylaştı

[GN⁺]

Hacker News yorumları

• Bu haberi görmek beni gerçekten çok sevindirdi
  Yetkili nameserver olarak bind kullandığımda, her web sunucusunun yalnızca kendisine ait TXT kayıtlarını güncelleyebilmesi için hmac-secret ayarını kısıtlayabiliyorum
  Böylece “bob” sunucusu ele geçirilse bile yalnızca “bob” alan adı için sertifika alınabilir
  Yapılandırma örneğinde, update-policy ile her anahtarın sadece _acme-challenge alt alanını değiştirmesine izin veriliyor

  • bind yerine ayrı bir DNS sunucusu çalıştırmaya razıysanız, acmedns benzer bir işlev sunuyor
    Yeni bir hesap oluşturulduğunda benzersiz bir alt alan adı veriliyor ve challenge alan adını bu alt alana CNAME yaparsanız yalnızca o hesap ilgili bölgeyi güncelleyebiliyor

• Bence bu özellik pratikteki büyük bir kullanım zorluğunu çözüyor
  Yine de yönetim hesabının kimliğinin açığa çıkması endişe verici
  Kullanıcı adı, kimlik bilgileri kadar korunmasa da saldırganlara hedef belirlemede ipucu verebilir
  Shodan benzeri servislerin bu kimlikleri indeksleyip ters sorgu hizmeti sunması oldukça olası

  • CAA kaydındaki accounturi de zaten hesap kimliğini açığa çıkarıyor; yani bir bakıma bu bilgi zaten görünür durumda
    Hatta CAA ile persist kayıt formatının aynı olmasının daha iyi olacağını düşünüyorum
  • Kullanıcıya gerçek hesap yerine UUID gibi rastgele bir kimlik verilip bunun accounturi içinde kullanılması iyi olabilir
  • ACME istemcisinin oluşturduğu hesapla aynı olduğu için, ters sorgu riskinin çok büyük olmadığını düşünüyorum

• DNSSEC gerektirmemesi şaşırtıcı
  Eskiden DNSSEC’i zahmetli bulurdum ama artık CAA, CERT, SSHFP, TXT gibi kök güveni etkileyen kayıtlar arttığı için MITM saldırılarına daha açık hale gelindi
  Özellikle büyük şirketler bile DNSSEC’i düzgün uygulamıyor; bu yüzden en azından tavsiye olarak açıkça belirtilmesi gerektiğini düşünüyorum

  • RFC taslağı da DNSSEC kullanımını “SHOULD” olarak öneriyor (bağlantı)
  • DNS, TLS sertifikası verilmesi için zaten en başından beri tek hata noktası idi
    Bir saldırgan DNS’i ele geçirirse HTTP-01, TLS-ALPN-01 ya da DNS-01 fark etmeksizin her yöntemle sahte sertifika alabilir
  • Kişisel olarak DNSSEC yerine TLSA yaklaşımını daha iyi buluyorum ama tarayıcı desteği neredeyse olmadığı için yazık oluyor

• Bu özellik sayesinde internete açık olmayan LAN sunucuları için sertifika almak çok daha kolay hale gelecek gibi görünüyor
  Yakında çoğu yönetici arayüzünün DNS kaydına yapıştırılacak metni otomatik üretip doğrudan Let's Encrypt sertifikası aldırabileceğini düşünüyorum

  • Ben de benzer bir ortamda denedim ama headscale magic DNS yapılandırması beklediğimden daha karmaşık çıktı, sonunda yeniden manuel güncellemeye döndüm

• certbot kullanıyorsanız, bu özellik için destek durumunu GitHub issue’sundan takip edebilirsiniz

• Eskiden kısa ömürlü sertifikalara kuşkuyla bakardım ama IP adresi sertifikaları ve HTTP-01 doğrulamasını görünce fikrim değişti
  Artık sertifikaları diskte tutmuyorum; arka plandaki bir thread her 24 saatte bir yeni sertifika olup olmadığını kontrol ediyor
  Bu sayede, kullanıcının bir VM’e yazılım dağıtıp 5 dakika içinde canlıya alabileceği self-hosted bir çözüm yapılabiliyor
  checkip.amazonaws.com gibi servislerle birleştirildiğinde tamamen otomatik dağıtım mümkün oluyor

  • Yine de Let's Encrypt’in rate limit politikası pazarlığa açık değil; çok sık istek atarsanız beklemek zorunda kalma riski var
  • Sertifikaları hiç saklamazsanız erişilebilirlik LE uptime’ına bağımlı hale gelir; bu yüzden en azından asgari düzeyde saklama gerekli

• Sonunda yalnızca iç kullanım için olan web servislerinin sertifikalarını otomatikleştirmek daha kolay olacak gibi görünüyor
  Şimdiye kadarki en büyük operasyonel sorunu çözmüş hissi verdiği için buna gerçekten sevindim

• Burada eksik kalan nokta ACME hesap sahipliğinin doğrulanması
  Çoğu otomasyon aracı hesabı kendi oluşturduğu için kullanıcılar bunu doğrudan ele almıyor ama artık hesap sahipliğini kanıtlayacak kimlik bilgilerinin ACME sağlayıcısına iletilmesi gerekiyor
  Let's Encrypt alan adı bazında sınırlı token oluşturamıyorsa, her alan adı için ayrı hesap açmak gerekebilir

  • Ancak ACME hesabının zaten doğrulama için kimlik bilgileri var ve alan adı sahipliği DNS ya da HTTP challenge ile doğrulanıyor
    Eğer bu kimlik bilgileri ya da endpoint ele geçirilmişse, zaten çok daha büyük bir sorun yaşanıyor demektir

• Dynamic DNS kullanıcıları için gerçekten sevindirici bir gelişme
  Örneğin Namecheap gibi, değişiklik isteğini yalnızca sabit IP üzerinden kabul eden yerlerde artık bir kez kurduktan sonra otomatik yenileme mümkün olacak
  Homelab’imi modernize ederken bunu mutlaka denemeyi planlıyorum

• Eğer yanlış anlamadıysam, alan adımın DNS sunucusunu kontrol eden biri ya da
  Let's Encrypt ile DNS sunucusu arasındaki trafiği ele geçiren biri benim alan adım için TLS sertifikası alabilir mi diye merak ediyorum
  DNS-01’de de durum benzer ama bu yöntemde saldırganın kendi LE hesabını DNS yanıtına koyması yeterli olduğu için daha da kolay görünüyor
  Hatta açık sertifikamı doğrudan DNS’e koymak daha iyi olmaz mı diye düşünüyorum

  • DNS sağlayıcınıza güvenmiyorsanız, asıl sorun o ilişkidir
    LE ile DNS sunucusu arasındaki trafiğe MITM yapabiliyorlarsa zaten çok daha ciddi bir durum vardır
  • DNS’i kontrol eden biri herhangi bir CA’den sertifika alabilir
    DNS’i değiştirebiliyorsa sertifika verilmesini engellemenin bir yolu yoktur
  • DNS’i kontrol eden biri HTTP challenge da yapabilir; yani pratikte o alan adı zaten onundur
  • CA’ler bu tür ağ saldırılarını azaltmak için DNS sorgularını birden fazla noktadan yapar
    Let's Encrypt bunu zaten yıllardır uyguluyor ve 2024’ten itibaren tüm CA’ler için zorunlu hale geldi
    CAB Forum kural bağlantısı
  • Aslında bu yaklaşım DANE’in benimsediği yöntemdir
    ilgili kaynak