irdaweb Bilgi Teknolojileri
Telefon numaramız +90 541 209 02 05
E-posta adresimiz [email protected]
Konu 23 · DNSSEC

DNSSEC — DNS yanıtlarını imzalayan güven zinciri.

DNS, internetin adres defteridir ama tasarımı gereği saf bir defterdir: kendisine dönen yanıtın gerçekten doğru kaynaktan gelip gelmediğini sorgulamaz. DNSSEC (DNS Security Extensions), bu boşluğu kapatmak için DNS kayıtlarını kriptografik olarak imzalar ve bu imzaları root'tan alan adınıza kadar uzanan bir güven zincirine bağlar. Böylece bir resolver, aldığı yanıtın yolda değiştirilmediğini matematiksel olarak doğrulayabilir. Bu sayfada DNSSEC'in neden gerektiğini, güven zincirinin nasıl kurulduğunu, kayıtların nasıl imzalandığını (RRSIG, DNSKEY, KSK/ZSK), zinciri üst bölgeye bağlayan çapayı (DS), bir resolver'ın yaptığı doğrulama yürüyüşünü ve "böyle bir kayıt yok" yanıtının bile nasıl imzalandığını (NSEC/NSEC3) adım adım birlikte ele alıyoruz.

01 — Neden gerekir

DNS'in güven boşluğu ve cache zehirlenmesi

Klasik DNS, hız için tasarlandı; güvenlik için değil. Bir resolver bir alan adı sorduğunda, dönen yanıtın gerçekten yetkili sunucudan mı geldiğini yoksa araya giren biri tarafından mı uydurulduğunu ayırt edemez. Saldırgan, resolver'ın önbelleğine sahte bir kayıt yerleştirebilirse (cache zehirlenmesi / Kaminsky saldırısı), o alan adını ziyaret eden herkesi sessizce kendi sunucusuna yönlendirebilir — tarayıcıda hiçbir uyarı çıkmadan. DNSSEC bu sorunu şifreleyerek değil, imzalayarak çözer: her kayıt kümesine, yalnızca alan adının özel anahtarıyla üretilebilen bir imza eklenir. Yanıt yolda değiştirilirse imza tutmaz ve doğrulayan resolver yanıtı reddeder.

Tehdit imzasız DNS
# resolver sorar, kim cevaplarsa ona inanır
soru    banka.com A = ?
sahte   banka.com A = 203.0.113.9   # saldırgan
gerçek  banka.com A = 198.51.100.4

# imza yoksa resolver ikisini ayırt edemez

İmzalama, şifreleme değil

DNSSEC yanıtın doğruluğunu (bütünlük + köken) garanti eder, gizliliğini değil. İmzalı bir yanıt yine herkese açıktır; sadece kurcalanamaz. Sorguyu gizlemek DoH/DoT'un işidir.

Köken doğrulama

İmza, kaydın gerçekten o alan adının yetkili anahtarıyla üretildiğini kanıtlar. Araya giren bir aktör imzayı taklit edemez çünkü özel anahtara sahip değildir.

Zincirleme güven

Her halka bir üstündekini imzalar: root → TLD → alan adı. Resolver zaten güvendiği root anahtarından başlayıp aşağı doğru her imzayı doğrular.

02 — Güven zinciri

Root'tan alan adına: zincir nasıl kurulur

DNS zaten hiyerarşiktir: root, TLD'leri (.com, .org) tanır, TLD de alan adlarını. DNSSEC bu yapıya güveni ekler: her seviye, bir alt seviyenin anahtarını onaylar. Resolver tek bir şeye baştan güvenir — root bölgesinin açık anahtarına (trust anchor). Geri kalan her şey buradan zincirlenir: root, .com'un anahtarını onaylar; .com, alan adınızın anahtarını; alan adınız da A, MX, TXT gibi kayıtlarını imzalar. Tek bir halka kopuksa zincir kırılır ve resolver alan adını "imzasız" sayar.

Chain of trust yukarıdan aşağı
root (.)          # resolver'ın baştan güvendiği çapa
  │ DS → DNSKEY imzalar
  ▼
.com
  │ DS → DNSKEY imzalar
  ▼
irdaweb.com
  │ DNSKEY → RRSIG imzalar
  ▼
A / MX / TXT …   # imzalı kayıtlar

Trust anchor — başlangıç noktası

Resolver, root bölgesinin açık anahtarını (KSK) önceden bilir; bu, zincirin sorgulanmadan güvenilen tek halkasıdır. Root anahtarı periyodik olarak yenilenir (KSK rollover).

Delegasyon — her seviye bir alt seviyeyi onaylar

Üst bölge, alt bölgenin anahtarının özetini (DS) yayınlayarak "bu çocuğa güvenebilirsin" der. Güven, isim hiyerarşisiyle birebir aynı yolu izler.

Kopuk halka — secure fail

DS ile DNSKEY uyuşmazsa veya imza süresi dolmuşsa, doğrulayan resolver yanıtı SERVFAIL ile reddeder — kullanıcı siteye hiç erişemez.

03 — İmzalama & anahtarlar

RRSIG, DNSKEY ve KSK ile ZSK ayrımı

Bir bölgeyi imzalamak, her kayıt kümesi (RRset) için bir imza üretmek demektir. Bu imza RRSIG kaydında saklanır; doğrulamak için gereken açık anahtar ise DNSKEY kaydında yayınlanır. DNSSEC pratikte iki ayrı anahtar kullanır: küçük ve sık değişen ZSK bölgedeki kayıtları imzalar, büyük ve nadiren değişen KSK ise yalnızca DNSKEY kümesini imzalar. Bu ayrım, anahtar yenilemeyi üst bölgeyi rahatsız etmeden yapabilmek içindir — çünkü üst bölgede duran DS yalnızca KSK'ye bağlıdır.

Signing iki anahtarlı imzalama
# ZSK kayıtları imzalar → RRSIG üretir
A     irdaweb.com  198.51.100.4
RRSIG A  ...imza...        # ZSK ile

# KSK yalnızca anahtar kümesini imzalar
DNSKEY  257  KSK   ...      # 257 = KSK
DNSKEY  256  ZSK   ...      # 256 = ZSK
RRSIG DNSKEY  ...imza...   # KSK ile

# üst bölgedeki DS, KSK'nin özetini tutar
RRSIG
Her RRset için ayrı bir imza. İmzalanan veriyi, kullanılan anahtarı ve bir geçerlilik penceresi (inception–expiration) içerir. Süre dolmadan imzalar yeniden üretilmelidir; aksi halde geçerli kayıt bile reddedilir.
DNSKEY
Doğrulama için kullanılan açık anahtarları yayınlar. Bayrak alanı rolü belirtir: 256 ZSK, 257 KSK. Özel anahtarlar asla yayınlanmaz; bölgeyi imzalayan tarafta saklı kalır.
ZSK
Zone Signing Key. Bölgedeki tüm normal kayıtları imzalar. Daha kısa ve sık yenilenir; yenilenmesi üst bölgeyi ilgilendirmez, çünkü DS ona bağlı değildir.
KSK
Key Signing Key. Yalnızca DNSKEY kümesini imzalar ve zincirin alan adı ucundaki çapasıdır. Yenilendiğinde üst bölgedeki DS kaydının da güncellenmesi gerekir — bu yüzden nadiren değiştirilir.
04 — DS çapası

DS kaydı: zinciri üst bölgeye bağlamak

Alan adınızı imzalamanız tek başına yetmez; üst bölgenin (TLD) sizin anahtarınızı tanıması gerekir. Bu bağ, DS (Delegation Signer) kaydıyla kurulur. DS, sizin KSK'nizin kriptografik özetidir (parmak izi) ve sizin bölgenizde değil, üst bölgede yayınlanır. Onu oraya siz yazamazsınız: tescilciniz aracılığıyla registry'ye bildirirsiniz, registry de TLD bölgesine işler. Böylece .com, "irdaweb.com'un anahtarı şudur" diye imzalı bir beyanda bulunmuş olur — zincirin kritik köprüsü budur.

Delegation DS nerede durur
# .com bölgesinde (üst seviye):
irdaweb.com  DS  12345 13 2  A1B2…F9
                  │     │  │   └ KSK'nin özeti
                  │     │  └ özet algoritması
                  │     └ imza algoritması
                  └ key tag

# irdaweb.com bölgesinde (alt seviye):
DNSKEY 257 …  # DS bunun özetiyle eşleşmeli

Özet, anahtarın kendisi değil

DS, KSK'nin tamamını değil hash'ini taşır. Resolver, bölgeden gelen DNSKEY'i hash'leyip üst bölgedeki DS ile karşılaştırır; tutuyorsa anahtara güvenir.

Tescilci üzerinden yayınlanır

DS'yi üst bölgeye yazma yetkisi registry'dedir; siz tescilci panelinden iletirsiniz. DNS sağlayıcısı ile tescilci farklıysa bu adım çoğu zaman atlanır ve zincir kurulmaz.

Yanlış DS = erişilemezlik

KSK'yi değiştirip DS'yi güncellemeyi unutursanız özet artık eşleşmez ve doğrulayan resolver'lar siteyi reddeder. DS ve anahtar her zaman birlikte planlanmalıdır.

05 — Doğrulama yürüyüşü

Resolver imzaları nasıl doğrular

Doğrulama, root'tan aşağı doğru yürür. Doğrulayan bir resolver, güvendiği root anahtarından başlar ve her seviyede iki şeyi kontrol eder: bu seviyenin DNSKEY'i, üst bölgenin DS'iyle eşleşiyor mu ve istediğim kaydın RRSIG'i bu anahtarla doğrulanıyor mu? Her adım tutarsa resolver yanıta AD biti (Authenticated Data) ekler — "bu veriyi DNSSEC ile doğruladım" demektir. Herhangi bir adım tutmazsa yanıt SERVFAIL olur.

Validation dig irdaweb.com +dnssec
root KSK  (trust anchor) ✓
  └─ DS(.com) imzalı, DNSKEY ile doğrulandı ✓
.com
  └─ DS(irdaweb.com) imzalı ✓
irdaweb.com
  └─ DNSKEY, DS özetiyle eşleşti ✓
  └─ RRSIG(A) bu DNSKEY ile doğrulandı ✓

flags: qr rd ra ad   # ad = doğrulandı

Yukarıdan aşağı, adım adım

Her seviyede DS↔DNSKEY eşleşmesi ve RRSIG doğrulaması yapılır. Zincir kopmadan alan adına ulaşılırsa veri güvenilir kabul edilir.

AD biti — doğrulandı işareti

ad bayrağı yanıtın DNSSEC ile doğrulandığını gösterir. Bayrak yoksa ya bölge imzasızdır ya da resolver doğrulama yapmıyordur.

SERVFAIL — sessiz değil, sert

Doğrulama başarısızsa resolver kaydı hiç döndürmez. Kullanıcı için site "çalışmıyor" gibi görünür; yanlış imza, gerçek bir kesinti gibi yaşanır.

06 — NSEC & imzalı yokluk

"Böyle bir kayıt yok" yanıtını imzalamak

DNSSEC yalnızca var olan kayıtları değil, olmayan kayıtları da güvence altına almalıdır. Aksi halde saldırgan, geçerli bir kaydı "yok" gibi göstererek (downgrade) korumayı atlayabilirdi. Çözüm, yokluğu da imzalamaktır. NSEC, bölgedeki adları sıralayıp "şu ile şu arasında başka isim yok" diyen imzalı bir kayıttır. Ne var ki bu, bölgenin tüm içeriğinin tek tek dökülmesine (zone walking) izin verir. NSEC3 bunu, isimleri açık metin yerine hash'leyerek zorlaştırır.

NSEC

İmzalı yokluk kanıtı

Sıralı isimler arasında boşluk göstererek bir adın gerçekten var olmadığını imzalı biçimde kanıtlar. Sahte "yok" yanıtlarını engeller.

Zone walking

NSEC'in sızıntısı

NSEC zinciri tek tek izlenerek bölgedeki tüm isimler çıkarılabilir. Gizli alt alan adları olan bölgeler için bu istenmeyen bir ifşadır.

NSEC3

Hash'li yokluk

İsimleri hash'leyerek listeler; yokluk kanıtını korur ama bölge içeriğini dökmeyi pahalı hale getirir. Bugün yaygın varsayılan yaklaşımdır.

07 — Sık karıştırılanlar

Sık karıştırılan DNSSEC kavramları

DNSSEC vs. TLS / SSL

DNSSEC, "bana dönen DNS yanıtı sahte mi?" sorusunu yanıtlar; alan adı çözümlemesini imzalar. TLS ise "bağlandığım sunucuyla aramdaki trafik şifreli ve doğru sunucu mu?" sorusunu yanıtlar. Farklı katmanları korurlar; biri diğerini gereksiz kılmaz. Ayrıntı için TLS, SSL & Sertifika.

DNSSEC vs. DoH / DoT

DNSSEC yanıtı imzalar ama gizlemez — sorgu ve yanıt yine açıkta görünür. DoH/DoT ise DNS trafiğini şifreleyerek araya bakanın sorguyu görmesini engeller ama yanıtın doğruluğunu garanti etmez. İkisi tamamlayıcıdır: biri bütünlük, diğeri gizlilik sağlar.

DS vs. DNSKEY

DNSKEY alan adınızın kendi bölgesinde yayınladığı açık anahtardır. DS ise bu anahtarın bir özetidir (parmak izi) ve üst bölgede (TLD) durur. DNSKEY "anahtarım bu", DS ise "üst otorite bu anahtarı tanıyor" demektir; zinciri kuran köprü DS'tir.

KSK vs. ZSK

KSK (Key Signing Key) yalnızca DNSKEY kümesini imzalar ve DS ile üst bölgeye bağlanır; nadiren değişir. ZSK (Zone Signing Key) bölgedeki normal kayıtları imzalar ve sık yenilenir. Ayrımın amacı, ZSK'yi DS'yi hiç ellemeden güvenle döndürebilmektir.

İmzalı vs. Doğrulanan

Bir bölgeyi imzalamak (RRSIG/DNSKEY üretip DS yayınlamak) tek başına yetmez; koruma ancak resolver tarafı doğrulama (validating resolver) yaptığında devreye girer. İmzalı bir alan adı, doğrulamayan bir resolver için imzasız gibi davranır. İki uç da gerekir.

Birinci el kaynaklar

DNSSEC'i protokol düzeyinde tanımlayan IETF belgeleri, ICANN'in temel rehberi ve kavramları görselleştiren açıklayıcılar.

Sıradaki adım

DNSSEC'i alan adınızda birlikte kuralım.

İmzalama, DS bildirimi ve doğrulama; yanlış bir adımda alan adını erişilemez kılabilir. Geçişi planlayıp güvenle devreye almak için bize yazabilirsiniz.