DNSSEC DS Kaydı Nedir? Registrar Tarafında Ne Yapılır?

DNSSEC etkinleştirildi, zone imzalandı — ama bir şey eksik. DS kaydı parent zone'a iletilmeden DNSSEC zinciri tamamlanmaz; alan adı teknik olarak imzalı görünür ama doğrulanamaz. Bu noktada yapılması gereken işlem bir DNS kaydı düzenlemesi değil, registrar tarafında birkaç adımlık bir prosedür.

DS (Delegation Signer) kaydı, sizin zone'unuzu imzalayan anahtarın kriptografik özetini taşır ve bu özet kendi zone'unuzda değil, üst zone'da — yani parent zone'da — bulunur. .com alan adları için bu, Verisign'ın yönettiği .com zone'udur. Kaydı siz doğrudan yazamazsınız; registrar'ınız bu veriyi TLD registry'ye iletir. Zone imzalama işleminin tamamlanmış sayılabilmesi için bu iletim adımı şarttır.

Genel DNSSEC mekanizması — RRSIG kayıtları, imza doğrulama, NSEC/NSEC3 inkâr yanıtları — DNSSEC ve domain güvenliği yazısında ele alındı. Burada farklı bir soruyu yanıtlıyoruz: zone imzalandıktan sonra güven zincirini tamamlayan DS kaydı nasıl oluşur, registrar tarafında ne yapılır ve her şey doğru yapıldığında bunu nasıl doğrularsınız?

DNSKEY'den DS kaydına: zone imzalama sonrasında tablodaki veriler

Zone imzalama süreci iki farklı anahtar çifti üretir. ZSK (Zone Signing Key) zone içindeki kayıtları — A, MX, NS gibi — imzalar. KSK (Key Signing Key) ise ZSK'yı imzalar ve güven zincirinde üst bağlantı noktasını oluşturur. Her iki anahtar da zone'da DNSKEY kaydı olarak yayımlanır; aralarındaki fark bayrak alanında gizlidir. KSK için bayrak değeri 257, ZSK için 256'dır.

example.com.  300  IN  DNSKEY  257 3 13 mdsswUyr3DPW...  ; KSK — flags: 257
example.com.  300  IN  DNSKEY  256 3 13 aFEkzHgN2p8...  ; ZSK — flags: 256

DS kaydı, KSK'nın kriptografik özetinden türetilir. Özet algoritması SHA-256 (digest type 2) veya SHA-384 (digest type 4) olabilir; SHA-1 (digest type 1) artık güvenli kabul edilmemektedir. DS kaydı dört alan içerir: key tag (anahtarı tanımlayan kısa sayısal kimlik), algoritma numarası, digest türü ve özetin kendisi.

example.com.  3600  IN  DS  12345 13 2 e1eef49a...ab3c

Algoritma 13, modern kurulumların büyük çoğunluğunda kullanılan ECDSA P-256 / SHA-256'yı ifade eder. Algoritma 8, RSA/SHA-256'dır ve hâlâ yaygın görülür. ECDSA (13 ve 14) ve EdDSA (15, Ed25519) RSA'ya kıyasla hem daha küçük anahtar boyutları hem de daha iyi performans sunar; yeni kurulumlar için 13 ya da 15 tercih edilmesi önerilir.

Bu noktada önemli bir ayrım var: DS kaydı, zone'u imzalayan yazılım tarafından hesaplanır ve size sunulur. Bazı sistemler bunu doğrudan DS kaydı formatında verir; bazıları DNSKEY verisi olarak sunar ve registrar bu veriden DS kaydını kendisi hesaplar. İkisi de aynı sonuca ulaşır; fark yalnızca registrar arayüzüne hangi formatın girileceğidir.

Güven zincirinin halkası: DS kaydı neden parent zone'da bulunmak zorunda?

DNSSEC güven zinciri, kök zone'dan başlar ve her seviyede aşağı doğru uzanır. Kök zone kendi DNSKEY'lerini taşır; bu anahtarlar imzalıdır ve doğrulayıcıya önceden yüklü "trust anchor" ile güvenilir kabul edilir. Kök zone, her TLD için bir DS kaydı bulundurur; bu DS kaydı TLD zone'unun DNSKEY'ini doğrular. TLD zone'u da kendi altındaki her alan adı için DS kaydı taşır — ve bu DS kaydı sizin zone'unuzun KSK'ını doğrular.

. (kök zone)
  └── DS → .com DNSKEY doğrulanır
        └── .com zone
              └── DS → example.com DNSKEY doğrulanır
                    └── example.com zone
                          └── RRSIG kayıtlarıyla imzalı tüm kayıtlar

Zincirin her halkası, bir üst zone'un onayıyla güvenilir hale gelir. Kendi zone'unuzdaki DNSKEY kaydı, üst zone'da karşılığı olan bir DS kaydı yoksa doğrulayıcı bu anahtarın meşru olup olmadığını bilemez. Zone imzalanmış olsa da zincir kopuktur; doğrulayıcı imzaları teknik olarak görebilir ama güvenemez.

DS kaydının kendi zone'unuzda değil parent zone'da bulunmasının nedeni tam da budur: kendi zone'unuza kendiniz her şeyi yazabilirsiniz, bu doğrulama sağlamaz. Güven, dışarıdan — üst seviyeden — gelmelidir. NS kaydı mantığına benzer bir bağımlılık bu: NS kaydı da kendi zone'unuzdaki sürümünün yanı sıra parent zone'da bulunur ve parent zone'daki kayıt yetkiyi resmileştirir. DS kaydı da aynı prensibi güvenlik zinciri için uygular.

DS kaydı eksikken doğrulama neden başarısız olur?

DS kaydı olmadan zone'unuzu DNSSEC doğrulayıcılı bir resolver üzerinden sorgulayan istemciler genellikle SERVFAIL yanıtı alır. Bu "sunucu hata döndürdü" anlamına gelir ama aslında mesaj şudur: "bu zone için DNSSEC zinciri tamamlanamadı, güvenli yanıt veremiyorum."

Ayrıntıda şu olur: TLD zone'unda sizin domain'iniz için DS kaydı gördüğünde doğrulayıcı, zone'unuzun DNSSEC ile imzalı olduğunu varsayar ve imzaları doğrulayacak anahtarı bekler. DS kaydı yoksa doğrulayıcı zone'u "insecure" olarak işaretler ve imzalı bile olsa doğrulama yapmaz. Zone'u "signed but unverifiable" durumunda bırakmak, katı modda çalışan doğrulayıcıların SERVFAIL döndürmesine yol açar.

DNSSEC etkin olmayan zone'lar için bu tablo farklıdır. TLD zone'unda hiç DS kaydı yoksa doğrulayıcılar zone'u "insecure" olarak işaretler — bu hata değil, DNSSEC'in devrede olmadığı normal durumdur. Sorun yalnızca DS kaydı var ama DNSKEY eşleşmiyor ya da DS kaydı var ama zone'da RRSIG kayıtları eksik olduğunda çıkar. Bu durumda zone imzalı görünür ama zincir kırılmıştır ve SERVFAIL kaçınılmazdır.

Registrar tarafında DS kaydı ekleme süreci

DS kaydı ekleme prosedürü, authoritative nameserver yazılımınızın nerede çalıştığına ve registrar'ınızın hangi veriyi beklediğine göre iki farklı akışa ayrılır.

Birinci akış: authoritative nameserver yazılımınız (BIND, PowerDNS, Knot DNS gibi) size doğrudan DS kaydı satırını verir. Bu satırı registrar arayüzüne olduğu gibi girersiniz. BIND'da zone imzalandıktan sonra oluşan .ds uzantılı dosya ya da dnssec-dsfromkey komutu bu veriyi üretir.

# DNSKEY kaydından DS verisi hesaplama
dnssec-dsfromkey -2 Kexample.com.+013+12345.key

# Çıktı:
example.com. IN DS 12345 13 2 e1eef49a...ab3c

İkinci akış: Cloudflare, AWS Route 53 veya bazı managed DNS sağlayıcıları DNSSEC'i kendi altyapılarında otomatik olarak etkinleştirir ve size DS kaydı yerine DNSKEY verisi sunar. Registrar arayüzüne DNSKEY içeriğini girdiğinizde registrar bu veriden DS kaydını kendisi hesaplar. Hangi formatı kullandığınıza registrar arayüzü karar verir; bazıları her ikisini de kabul eder.

Registrar arayüzlerinde genellikle dört alan doldurursunuz. Key Tag, anahtarı tanımlayan sayısal kimlik — zone imzalama yazılımından gelir, genellikle 0–65535 arasında. Algorithm, algoritma numarası; örneğin 13. Digest Type, özet türü; çoğunlukla 2 (SHA-256). Digest ise onaltılık formatta uzun karakter dizisi. Bu bilgilerin tamamı zone imzalama yazılımından ya da managed DNS sağlayıcınızın panelinden temin edilir; manuel hesaplama yapılmaz.

Arayüz farkları registrar'dan registrar'a büyük değişkenlik gösterir. Bazı registrar'lar DS kaydı ekleme için "DNSSEC Management" ya da "DS Records" başlıklı ayrı bir sekme sunar. Bazıları bu işlemi domain yönetim panelinin alt kısmına, nameserver ayarlarının yanına gömer. Bazı eski registrar'lar ise DNSSEC'i hiç desteklemez; bu durumda domain'i DNSSEC destekleyen bir registrar'a transfer etmek dışında seçenek kalmaz. Transfer öncesi mevcut DNSSEC durumunu not almak ve hedef registrar'da DS kaydını hemen eklemek, kesintisiz bir geçiş için zorunludur.

DS kaydı registry'ye iletildikten sonra TLD nameserver'larında görünmesi için belirli bir süre beklenir. .com ve .net için bu genellikle birkaç dakika ile birkaç saat arasındadır. TLD zone'unun güncelleme döngüsüne ve TTL değerine bağlı olarak değişir.

DS kaydını doğrulama: dig ve çevrimiçi araçlar

DS kaydının TLD zone'una başarıyla iletilip iletilmediğini doğrulamanın en doğrudan yolu, TLD nameserver'larını doğrudan sorgulamaktır. Kendi resolver'ınız üzerinden yapılan sorgular önbellek sonuçları döndürebilir; TLD nameserver'ını hedef almanız gerekir.

# .com TLD nameserver'larından birini bul
dig NS com. +short

# DS kaydını doğrudan TLD nameserver'ından sorgula
dig DS example.com @a.gtld-servers.net +short

# Beklenen çıktı (DS kaydı varsa):
12345 13 2 e1eef49a...ab3c

# DNSSEC güvenlik bitleriyle birlikte genel sorgu
dig example.com +dnssec +short

Çıktıda key tag, algoritma numarası, digest türü ve digest görünüyorsa DS kaydı parent zone'a ulaşmış demektir. Boş çıktı ya da hiç DS satırı dönmemesi, iletimin henüz tamamlanmadığını ya da kayıt girilmediğini gösterir. Komut satırı erişimi olmadan hızlı bir ilk kontrol için DNS lookup aracı üzerinden DS kaydı türünü seçerek sorgu yapmak da mümkündür.

Zincirin uçtan uca sağlıklı olup olmadığını görmek için çevrimiçi araçlar çok daha kapsamlı görünürlük sunar. DNSViz (dnsviz.net) güven zincirini görsel olarak haritalar ve her düğümdeki sorunu — eksik DS, eşleşmeyen digest, süresi dolmuş imza — ayrı ayrı işaretler. Verisign'ın DNSSEC Analyzer (dnssec-analyzer.verisignlabs.com) ise yapılandırma hatalarını sade bir arayüzde listeler. Her iki araç da sorguları doğrulayıcı perspektifinden yapar; kendi sisteminizdeki önbellek sonuçlarından bağımsızdır.

delv komutu, BIND ile birlikte gelen ve DNSSEC doğrulamasını yerel olarak yapan bir araçtır. Doğrulama adımlarını ayrıntılı gösterir; dig'in basit çıktısının ötesine geçmek isteyenler için daha bilgilendirici bir seçenektir.

delv @8.8.8.8 example.com A +rtrace

# Zincir tamsa çıktıda görünen ifade:
; fully validated

Anahtar rotasyonu ve DS güncellemesi: silme sırası önemli

KSK değiştirildiğinde — periyodik güvenlik güncellemesi ya da algoritma geçişi nedeniyle — DS kaydı da güncellenmek zorundadır. Bu süreç yapısal olarak DKIM selector rotasyonuna benzer: eski kayıt silinmeden önce yeni kayıt yerleşmeli, geçiş süresi boyunca her ikisi eş zamanlı aktif olmalı.

Rotasyon adımları şöyle işler. Önce yeni KSK üretilir ve zone'a eklenir; bu aşamada zone'da iki DNSKEY (eski ve yeni KSK) bulunur. Yeni KSK'dan türetilen yeni DS kaydı registrar üzerinden parent zone'a iletilir. Yeni DS kaydının TLD zone'unda göründüğü doğrulandıktan sonra, propagasyonun tamamlanması beklenir. Ancak bu doğrulamadan sonra eski KSK zone'dan kaldırılır ve ardından eski DS kaydı registrar üzerinden silinir.

Bazı managed DNS sağlayıcıları anahtar rotasyonunu otomatik yapar ve DS kaydını registrar API'si üzerinden kendileri günceller. Bu kolaylık yalnızca registrar ile DNS sağlayıcısı arasında bu entegrasyonun kurulu olduğu durumlarda çalışır. Authoritative DNS'i Cloudflare'de ama domain kaydı başka bir registrar'da olanlar için süreç hâlâ manueldir; rotasyonu otomatik yapan altyapı DS güncellemesini registrar'a iletemiyor. Bu yapılandırmada DNSKEY'lerin değiştiğini fark etmek ve DS kaydını zamanında güncellemek yönetici sorumluluğunda kalır.

DS kaydı, zone imzalamanın görünür yüzüdür — tek başına DNSSEC'i çalıştırmaz ama olmadan hiçbir şey çalışmaz. Zone'un imzalı olması yetmez; bu imzanın üst otorite tarafından tanınması gerekir. Registrar arayüzündeki birkaç alan ve bir onay adımı, güven zincirini tamamlar ya da açık bırakır. Doğrulama adımını atlamadan, propagasyon süresine dikkat ederek ve rotasyon sırasını bozmadan yürütülen bir DS yönetimi, DNSSEC'in vaat ettiği güvenlik katmanını gerçekten aktive eder.