15 1 0 4000 1 https://haktanbozer.com.tr 300

DNSSEC Nedir?

DNSSEC (Domain Name System Security Extensions veya Türkçe hali ile Alan Adı Sistemi Güvenlik Eklentileri), İnternet Protokolü (IP) ağlarında kullanılan Alan Adı Sistemi (DNS) tarafından sağlanan belirli türdeki bilgilerin güvenliğini sağlamaya yönelik bir İnternet Mühendisliği Görev Grubu (IETF) dokümanıdır. DNS istemcilerine (çözümleyicilerine), DNS verilerinin köken ​kimlik doğrulaması, kimlik doğrulaması reddi ve veri bütünlüğünü sağlayan, ancak kullanılabilirlik veya gizlilik sağlamayan bir DNS eklentisidir.

 

Genel Bakış

Alan Adı Sistemi (DNS), özgün tasarımında hiçbir güvenlik önlemi içermez. Ölçeklendirilebilir dağıtılmış bir sistem olarak tasarlanmıştır. Alan Adı Sistemi Güvenlik Eklentileri (DNSSEC) geriye dönük uyumluluğu korurken, güvenlik önlemleri eklemeye çalışır. RFC 3833, DNS ile ilgili bilinen bazı tehditleri ve DNSSEC‘in bu tehditlere nasıl yanıt verdiğini belgelemektedir.

DNSSEC, sahte veya manipüle edilmiş DNS verilerinden (DNS önbellek zehirlenmesi ile oluşturulan veriler gibi ), uygulamaları korumak için (ve bu uygulamalara hizmet eden çözümleyicileri önbelleğe almak) kullanılacak şekilde tasarlanmıştır. DNSSEC korumasıyla gelen tüm cevaplar dijital olarak imzalanmıştır. Bir DNS çözümleyici, dijital imzayı kontrol ederek, bilgilerin alan sahibi tarafından yayınlanan ve yetkili bir DNS sunucusunda sunulan bilgilerle aynı (yani, değiştirilmemiş ve tam) olup olmadığını kontrol edebilir. IP adreslerini korumak birçok kullanıcı için en öncelikli endişe olsa da, DNSSEC, DNS‘de yayınlanan tüm veriyi koruyabilir, metin kayıtları (TXT) gibi, e-posta değişim kayıtları (MX) gibi ve DNS‘de saklanan kriptografik sertifikalara başvuru yayınlayan diğer güvenlik sistemlerini saklamak için de kullanılabilir (örneğin: Sertifika Kayıtları (CERT records, RFC 4398), SSH parmak izleri (SSHFP, RFC 4255), IPSec açık anahtarları (IPSECKEY, RFC 4025), ve TLS Trust Anchors (TLSA, RFC 6698).

DNSSEC verinin gizliliğini sağlamaz, bütün DNSSEC cevapları doğrulanmıştır ancak şifrelenmez. DNSSEC, DoS ataklarına karşı doğrudan korumaz, ancak dolaylı olarak bazı faydalar sağlar (çünkü imza kontrolü güvenilir olmayan tarafların kullanımına izin verir, bu ancak DNS sunucusu kendinden imzalı bir sertifika kullanıyorsa doğrudur, internet-bağlantılı DNS sunucuları için önerilmez).

DNS sunucuları arasında gönderilen toplu verileri (DNS zone transferi gibi) güvenli hale getirmek için diğer standartlar (DNSSEC olmayan) kullanılır. IETF RFC 4367 ‘ de dökümente edildiği gibi, bazı kullanıcılar ve geliştiriciler DNS adları hakkında yanlış tahminler yapmaktadır, örneğin bir şirketin genel adı artı “.com” her zaman onun alan adıdır gibi. DNSSEC yanlış denemelere karşı korumaz, sadece verinin gerçekte alan sahibinden alındığını veya uygun olmadığını doğrulayabilir.

DNSSEC özellikleri (DNSSEC-bis olarak adlandırılır) geçerli DNSSEC protokolünü detaylı olarak açıklar. Bu yeni RFC‘lerin yayınlanmasıyla (Mart 2005), daha önceki RFC (RFC 2535) geçmişte kalmıştır.

İnternetin bir bütün olarak güvenceye alınması için DNS‘ in güvence altına alınmasının kritik öneme sahip olduğuna inanılmaktadır, ancak DNSSEC‘ in yayılması özellikle bazı zorluklar ile aksamıştır (22 Ocak 2010’dan beri):

 

• İnternet boyutuna göre ölçeklenebilen geriye-yönelik uyumlu bir standart tasarlama ihtiyacı,

• İstenildiğinde, “bölge (DNS zone) ayrıntılı listesi” koruması,

• Çok geniş alanda yayılmış DNS sunucuları ve çözümleyicileri (istemciler) genelinde DNSSEC uygulamalarının yayılması,

• Üst seviye alan kök anahtarlarına kimin sahip olması gerektiği konusunda uygulayıcılar arasındaki anlaşmazlık,

DNSSEC ve DNSSEC yayılımının algılanan zorluğunu, karmaşıklığını aşmak .

 

Microsoft Windows’un kullandığı saplama çözümleyici; Özellikle Windows 7 ve üstü, geçerliliği olmayan (ancak DNSSEC uyumlu) bir türdür. DNSSEC hizmetlerine gerçek bir güvenin yerleştirilmesi için, bu saplama çözümleyici, söz konusu yinelemeli ad sunucularına (genellikle ISP tarafından denetlenir) ve kendisi ile bu ad sunucuları arasındaki iletişim kanallarına IPsec(çok fazla yayılmamış olanın kullanımıyla), SIG(0), or TSIG. gibi yöntemler kullanarak güvenmelidir.

 

İşlemler

DNSSEC, DNS sorguları için kayıtları, açık anahtar şifrelemesi ile dijital olarak imzalayarak çalışır. Doğru DNSKEY kaydı, bir güven zinciri aracılığıyla doğrulanır. Bu zincir güvenilir üçüncü taraf olan DNS kök bölgesi (DNS root zone) için bir dizi onaylanmış açık anahtarla başlar. Alan sahipleri kendi anahtarlarını oluşturur ve DNS kontrol panellerini kullanarak alan adı kayıt sitelerine yüklerler. Burası da anahtarları secDNS aracılığıyla bölge operatörüne (örn. .com için Verisign) gönderir ve bunları DNS‘de imzalar ve yayınlar.

 

Kaynak kayıtları

DNS, çeşitli kaynak kayıtlarının kullanılmasıyla gerçekleştirilir. DNSSEC‘i uygulamak için, DNSsec ile kullanılmak üzere birkaç yeni DNS kayıt türü oluşturulmuş veya uyarlanmıştır. Bunlar aşağıdaki gibidir:

RRSIG (kaynak kayıt imzası)

Bir kayıt grubu için DNSSEC imzasını içerir. DNS çözümleyicileri, imzayı DNSKEY kaydında saklanan açık anahtarla doğrular.

DNSKEY

Bir DNS çözümleyicisinin RRSIG kayıtlarındaki DNSSEC imzalarını doğrulamak için kullandığı açık anahtarı içerir.

 

DS (yetkili imzalayan)

Yetkili bölgenin adını tutar. Bir alt yekili bölgedeki bir DNSKEY kaydına başvurur. DS kaydı, temsilci NS kayıtları ile birlikte üst bölgeye yerleştirilir.

 

NSEC (bir sonraki güvenli kayıt)

Bölgedeki bir sonraki kayıt adına bir bağlantı içerir ve kaydın adı için var olan kayıt türlerini listeler. DNS çözümleyicileri, bir kayıt adının bulunmadığını doğrulamak için NSEC kayıtlarını kullanır ve DNSSEC doğrulamasının bir parçası olarak yazar.

 

NSEC3 (sıradaki güvenli kayıt versiyon 3)

Bölgedeki bir sonraki kayıt adının (karıştırılmış isim sırası düzeninde) bağlantılarını içerir ve NSEC3 kaydının kendi adının ilk etiketindeki hash değerinin kapsadığı ad için varolan kayıt tiplerini listeler. Bu kayıtlar, bir kayıt adının bulunmadığını doğrulamak ve DNSSEC doğrulamasının bir parçası olarak yazmak için çözücüler tarafından kullanılabilir. NSEC3 kayıtları, NSEC kayıtlarına benzerdir, ama NSEC3, bir bölgedeki kayıt adlarının numaralandırılmasını(sayılmasını) önlemek için kriptografik olarak karıştırılmış(hashed) kayıt adları kullanır.

 

NSEC3PARAM (sıradaki güvenli kayıt versiyon 3 parametreleri)

Yetkili DNS sunucuları, varolan adlar / türler için DNSSEC isteklerine yanıtları içerecek NSEC3 kayıtlarını hesaplamak ve belirlemek için bu kaydı kullanır. DNSSEC kullanıldığında, her DNS sorgu yanıtı, istenen kayıt türüne ek olarak bir RRSIG, DNS kaydı içerir. RRSIG kaydı, DNS yanıtı yanıt kümesinin dijital imzasıdır. Dijital imza, bir DNSKEY kaydında bulunan doğru ortak anahtarın yerini belirleyerek doğrulanır. NSEC ve NSEC3 kayıtları herhangi bir RR‘nin varlığının kriptografik kanıtlarını sağlamak için kullanılır. DS kaydı, güven zincirini kullanarak sorgu yordamında DNSKEY‘lerin kimlik doğrulamasında kullanılır. NSEC ve NSEC3 kayıtları, sahteciliğe karşı dayanıklılık için kullanılır.

 

Algoritmalar

DNSSEC, genişletilebilecek şekilde tasarlanmıştır, böylece mevcut algoritmalara karşı saldırılar keşfedildikçe, geriye doğru uyumlu bir şekilde yenileri eklenebilir. Aşağıdaki tablo, en çok kullanılan güvenlik algoritmalarını Nisan 2013 itibarıyla tanımlamaktadır:

Algoritma alanı Algoritma Kaynak Uygulama durumu
1 RSA/MD5 Uygulanmamalı
3 DSA/SHA-1 İsteğe Bağlı
5 RSA/SHA-1 RFC 3110 Gerekli
7 RSASHA1-NSEC3-SHA1 RFC 5155 Önerilen
8 RSA/SHA-256 RFC 5702 Önerilen
10 RSA/SHA-512 Önerilen Önerilen
12 GOST R 34,10-2001 RFC 5933 İsteğe Bağlı
13 ECDSA/SHA-256 RFC 6605 Önerilen
14 ECDSA/SHA-384 Önerilen Önerilen
15 Ed25519 RFC 8080 İsteğe Bağlı
16 Ed448 RFC 8080 İsteğe Bağlı

 

Sorgu Prosedürü

Bir DNS sorgusunun sonuçlarından, güvenlik bilinci olan bir DNS çözümleyici, sorgulanan alan için yetkili ad sunucusunun DNSSEC‘i destekleyip desteklemediğini, yanıtın güvenli olup olmadığını ve bir çeşit hata olup olmadığını belirleyebilir. Sorgu prosedürü birçok ISP’nin ki gibi yinelemeli ad sunucuları ve ana-akım işletim sistemlerinde olan saplama çözücülerden farklıdır. Microsoft Windows ‘ un kullandığı saplama çözümleyici, Windows Server 2008 R2 ,Windows 7 ‘ de özellikle geçerliliği olmayan ama DNSSEC uyumlu bir saplama çözümleyicisidir.

Yinelemeli Ad Sunucuları

Güven modeli zincirini kullanarak, üst etki alanındaki (DNS zone) bir Yetkili İmzalayıcı (DS) kaydı, bir alt etki alanındaki bir DNSKEY kaydını doğrulamak için kullanılabilir; bu, daha sonra alt etki alanlarını doğrulamak için diğer DS kayıtlarını da içerebilir. ISP ad sunucusu gibi özyinelemeli bir çözümleyicinin “www.example.com” alan adının IP adreslerini (A kaydı ve / veya AAAA kayıtları) almak istediğini varsayalım.

1. Güvenlik-tanılı bir çözümleyici, bir DNS sorgusunda “DO” (“DNSSEC OK“) işaret biti ayarladığında işlem başlar. DO biti, EDNS tarafından tanımlanan genişletilmiş bayrak bitlerinden olduğundan, tüm DNSSEC işlemleri EDNS‘yi desteklemelidir. Ayrıca, DNSSEC işlemlerinin gerektirdiği daha büyük paket boyutlarına izin vermek için EDNS desteği de gereklidir.

2. Çözümleyici normal DNS sorgu işlemi yoluyla bir yanıt aldığında, yanıtın doğru olduğundan emin olmak için kontrol eder. İdeal olarak, güvenlik-tanılı çözümleyici, DNS kökündeki DS ve DNSKEY kayıtlarının doğrulanmasıyla başlayacaktır. Daha sonra, “com” bölgesinde DNSKEY kayıtlarını doğrulamak için kökte bulunan “com” üst düzey etki alanı için DS kayıtlarını kullanır. Buradan itibaren, “com” bölgesinde “example.com” alt alanı için bir DS kaydı olup olmadığına bakar ve eğer varsa, DS kaydı, “example.com” bölgesinde bulunan bir DNSKEY kaydını doğrulamak için kullanır. Son olarak, “www.example.com” için A kayıtlarının cevabında bulunan RRSIG kaydını doğrular.

Yukarıdaki örnek için bazı istisnalar vardır.

İlk olarak, “example.com” DNSSEC‘ i desteklemiyorsa, yanıtta RRSIG kaydı olmayacaktır ve “com” bölgesinde “example.com” için bir DS kaydı olmayacaktır. “Example.com” için bir DS kaydı varsa, ancak yanıtta RRSIG kaydı yoksa, bir şey yanlıştır ve belki ortadaki adam saldırısı vardır ve DNSSEC bilgilerinin soyulması, A kayıtlarının değiştirilmesi gerçekleşiyor olabilir. Ya da, DO işaret biti sorgusundan veya RRSIG kaydının cevabından sıyrılan yol boyunca, kırılmış ,güvenlikten habersiz bir isim sunucusu olabilir. Ya da bir yapılandırma hatası olabilir.

Sonra eğer “www.example.com” adında bir alan adı bulunmuyor ise, bu durumda cevapta bir RRSIG kaydı yerine, bir NSEC kaydı veya bir NSEC3 kaydı olacaktır. Bunlar, çözümleyicinin bir alan adının mevcut olmadığını kanıtlamasına izin veren “sonraki güvenli” kayıtlardır. NSEC / NSEC3 kayıtlarında, yukarıdaki gibi doğrulanabilen RRSIG kayıtları bulunur.

Son olarak ise “example.com” bölgesi DNSSEC‘ i uygulamış olabilir, ama “com” bölgesi veya kök bölgesinin uygulamamış olabilir. 15 Temmuz 2010 itibarıyla, DNSSEC‘ in köke dağıtımı tamamlanmıştır.  .com etki alanı geçerli güvenlik anahtarlarıyla imzalanmış ve 1 Nisan 2011’de kök bölgesine güvenli temsilci eklenmiştir.

Saplama çözümleyiciler

Saplama çözümleyicileri, DNS çözümleme çalışmasının çoğunu özyinelemeli bir ad sunucusuna yüklemek için yinelemeli sorgu modunu kullanan minimal DNS çözümleyicileridir. Bir saplama çözümleyici, bir isteği yinelemeli ad sunucusuna iletir ve yanıttaki Kimlik Doğrulama Bilgisi (AD) biti, “yinelemeli ad sunucusunun, yanıtın Cevap ve Yetki bölümünün içindeki tüm veriler için imzaları doğrulayıp doğrulayamadığını bulmak için” ipucu “olarak kullanır. Microsoft Windows’ un kullandığı saplama çözümleyici, Windows Server 2008 R2 ve Windows 7, özellikle doğrulanmamış, ancak AD-bit uyumlu bir saplama çözümleyicisi kullanmaktadır.

Doğrulayıcı saplama çözümleyicisi, sorgulama iletilerinde Devre Dışı Bırakma (CD) biti’ni ayarlayarak kendi imza doğrulamasını da gerçekleştirebilir. Kendi yinelemeli kimlik doğrulamasını gerçekleştirmek için CD biti kullanır. Böyle bir doğrulanmış saplama çözümleyicisi kullanmak, İnternet hizmet sağlayıcısı veya onlarla bağlantı güvenilir olmasa bile, DNSSEC‘yi uygulayan alanlar için istemciye uçtan uca DNS güvenliği sağlar.

Doğrulayıcı olmayan saplama çözümleyicinin DNSSEC hizmetlerine gerçek bir güven yer vermesi için, saplama çözümleyici söz konusu yinelenen ad sunucularına (genellikle Internet hizmet sağlayıcısı tarafından denetlenen) güvenmelidir. Kendisi ile bu isim sunucuları arasındaki iletişim kanalları IPsec, SIG (0) veya TSIG gibi yöntemlerdir. IPsec kullanımı geniş çaplı yayılmamıştır.

 

Güvenli Mekanizma ve Kimlik Doğrulama Zincirleri

DNS yanıtının doğru olduğunu kanıtlayabilmek için, en az bir anahtar veya DNS dışındaki kaynaklardan doğru olan bir DS kaydı bilmesi gerekir. Bu başlangıç noktaları, güven mekanizmaları olarak bilinir ve genellikle işletim sistemi veya başka bir güvenilen kaynak ile elde edilir. DNSSEC orijinal olarak tasarlandığında, gereken tek güven mekanizmasının DNS kökü için olduğu düşünülüyordu. Kök mekanizmalar ilk defa 15 Temmuz 2010’da yayınlandı.

Kimlik doğrulama zinciri, sorgudaki alan için yetkili ad sunucusuna bir güven mekanizması ile başlayan bir dizi bağlı DS ve DNSKEY kaydıdır. Tam bir kimlik doğrulama zinciri olmadan, bir DNS sorgusunun cevabı güvenli bir şekilde doğrulanamaz.

 

İmzalar ve Bölge İmzalama

Yeniden gönderme saldırılarını sınırlamak için, önbelleğe alma amacıyla yalnızca normal DNS TTL değerleri değil, bir imzanın geçerliliğini sınırlamak için RRSIG kayıtlarındaki ek zaman damgaları da vardır. Kayıtların gönderildiği zamana göre TTL değerlerinden farklı olarak, zaman damgaları mutlaktır. Bu, güvenlikle ilgili tüm DNS çözümleyicilerinin, birkaç dakika içinde eşit olarak senkronize olan saatlere sahip olması gerektiği anlamına gelir.

Bu zaman damgaları, bir bölgenin düzenli olarak yeniden imzalanması ve ikincil sunuculara yeniden dağıtılması gerektiğini ya da doğrulanmış çözümleyiciler tarafından imzaların reddedileceğini ima eder.

 

Anahtar Yönetimi

DNSSEC, hem DNSKEY kayıtlarında hem de güven kaynaklarını oluşturmak için diğer kaynaklarda saklanan birçok farklı anahtar içerir.

Yedek anahtarlara izin vermek için, bir anahtar çevrim şeması gereklidir. Genellikle, bu, eski anahtarlara ek olarak, yeni DNSKEY kayıtlarındaki yeni anahtarları ilk kez içerir. Ardından, yaşama değerlerinin eski anahtarların saklanılmasına neden olduğunu varsaymak güvenliyse, bu yeni anahtarlar kullanılabilir. Son olarak zamanı geçmiş eski anahtarları kullanan kayıtları saklamayı varsaymak güvenliyse, eski DNSKEY kayıtları silinebilir. Bu işlem, kökte olduğu gibi, bağlayıcı mekanizmalara(anchor) güvenme anahtarlarındaki gibi şeyler için daha karmaşıktır ,öyle ki, işletim sisteminde bir güncelleştirme gerektirebilir.

DNSKEY kayıtlarındaki anahtarlar iki farklı şey için kullanılabilir ve genellikle her biri için farklı DNSKEY kayıtları kullanılır. İlk olarak, diğer DNSKEY kayıtlarını imzalamak için kullanılan anahtar imzalama anahtarları (KSK) vardır. İkincisi, diğer kayıtları imzalamak için kullanılan bölge imzalama anahtarları (ZSK) vardır. ZSK‘ler belirli bir DNS bölgesi tarafından tam kontrol ve kullanım altında olduğundan, daha kolay ve daha sık değiştirilebilirler. Sonuç olarak, ZSK‘ler KSK‘lerden çok daha kısa olabilir ve RRSIG / DNSKEY kayıtlarının boyutunu azaltırken aynı koruma düzeyini sunmaya devam eder.

Yeni bir KSK oluşturulduğunda, DS kaydı bir üst bölgesine aktarılmalı ve orada yayınlanmalıdır. DS kayıtları, kayıtların boyutunu küçük tutmak için tam anahtar yerine KSK‘nın bir mesaj özetini kullanır. Bu, çok büyük olan .com etki alanı gibi bölgeler için yararlıdır. Üst bölgedeki DS anahtarlarını güncelleme yordamı, üst bölgedeki DNSKEY kayıtlarını gerektiren önceki DNSSEC sürümlerinden de daha basittir.

 

DANE Çalışma Grubu

Adlandırılmış varlıkların DNS tabanlı kimlik doğrulaması (DANE), internet uygulamalarının DNSSEC tabanlı TLS, DTLS, SMTP ve S / MIME ile kriptografik olarak güvenli iletişim kurmasına olanak tanıyan protokoller ve teknikler geliştirme amacıyla bir IETF çalışma grubudur.

Yeni protokoller, açık anahtar altyapısına dayalı geleneksel model için ek güvenceler ve kısıtlamalar getirecektir. Ayrıca, alan sahiplerine üçüncü taraf sertifika yetkililerine atıfta bulunmadan kendileri için sertifikalar vermelerini de sağlar.

Google Chrome 14′ te DNSSEC yerleştirilmiş sertifika desteği sağlandı, ancak daha sonra kaldırıldı. Mozilla Firefox için destek, bir eklenti tarafından sağlanırken, yerel destek şu anda üzerinde çalışmaya başlamak için birilerini bekliyor.

 

Tarihçe

DNS, temel ve ciddi bir internet hizmetidir, ancak 1990 yılında Steve Bellovin sistemin içinde önemli güvenlik açıkları keşfetti. Sistemin güvenlik araştırması başladı ve 1995 yılında yayınladığı makalesinin ardından önemli ölçüde ilerleme katedildi. İlk RFC 2065, 1997 yılında IETF tarafından yayınlandı ve bu spesifikasyonu uygulamaya yönelik ilk girişimler bir düzenlemeye yol açtı, (ve tamamen çalışır olduğuna inanılan) yeni düzenleme 1999 yılında RFC 2535 olarak yayınlandı. RFC 2535‘e dayanan DNSSEC‘i uygulamak için planlar yapıldı.

Ne yazık ki, IETF RFC 2535 dokümanı, internetin tamamına kadar ölçeklenen çok önemli sorunlara sahipti, 2001 yılında bu dokümanın büyük ağlar için kullanılamaz olduğu netleşti. Normal işlemlerde DNS sunucuları sık sık sunucu atalarıyla senkronizasyonu yitirir. Bu durum genellikle sistem için bir sorun oluşturmaz, ama DNSSEC etkinleştirildikten sonra, bu senkronize olmayan veriler ciddi bir kendi kendine oluşturulmuş Denial of Service saldırısına neden olabilir. Orijinal DNSSEC, bir alt seviyedeki DNS sunucusu için anahtar değişikliklerinde karmaşık bir altı mesaj protokolüne ve çok sayıda veri aktarımına ihtiyaç duyuyordu (DNS alt seviyedeki sunucuların tüm verilerini üst seviyeye yollaması, bu verilerin imzalaması ve ardından bu imzaların sunucuya tekrar yollanması gerekiyordu). Ayrıca, açık anahtar değişikliklerinin beklenmedik etkileri olabiliyordu. Örneğin, “.com” kayıtlarının tutulduğu sunucu açık anahtarını değiştirirse, bu sunucunun 22 milyon kayıt göndermesi gerekirdi (tutulan tüm kayıtların imzalarının güncelenmesi için). Böylece, RFC 2535‘te tanımlandığı gibi DNSSEC tüm internete ölçeklendirilemedi.

IETF, DNSSEC‘i RFC 2535‘in DNSSEC yaklaşımından farklı kılmak için temel değişiklikler yaparak DNSSEC-bis‘ i oluşturdu. DNSSEC-bis yaklaşımında, ebeveyn ve çocuk bölgesi arasındaki temsil noktalarında ek bir dolaylılık seviyesi sağlamak için “yetkili imzalı (DS) kaynak kayıtları” kullanır. Yeni yaklaşımda, bir çocuğun ana açık anahtarı değiştiğinde, çocukta bulunan her bir kayıt için altı mesaj göndermesi yerine, sadece bir mesajla yeni açık anahtarını ebeveynine imzalı olarak göndermesi yeterlidir. Böylece oldukça pratik bir şekilde ebeveynler her çocuk için bir ana açık anahtar tutar. Ayrıca ebeveyn ve çocuklar arasında çok büyük boyutta veri değişimini en aza indirger. Bu, kullanıcıların anahtarları doğrularken biraz daha fazla çalışma yapması gerektiği anlamına gelir. Daha spesifik olarak, bir DNS bölgesinin, KEY RRset(kaynak kayıtları anahtarı) doğrulanması, RFC 2535‘de belirtilen tek imza doğrulama işlemi yerine iki imza doğrulama işlemi gerektirir (diğer RRset türleri için doğrulama imzalarının sayısı üzerinde herhangi bir etkisi yoktur). Bu durum DNSSEC dağıtımını daha pratik hale getirdiğinden, çoğu insan için daha küçük bir fiyat olarak görünür.

 

NXDOMAIN yanıtları ve NSEC için Kimlik Doğrulama

Kriptografik olarak bir alanın(domain) yokluğunu kanıtlamak, var olmayan bir alan için her sorguya yanıtı imzalamayı gerektirir. Bu, anahtarları çevrimiçi olarak saklayan çevrimiçi imzalama sunucuları için bir sorun değildir. Ancak DNSSEC, kayıt imzalamak için çevrimdışı bilgisayarları kullanacak şekilde tasarlanmıştır; böylece bölge imzalama anahtarları soğuk depoda tutulabilir. Bu durum, varolan her ana makine(hostname) adı sorgusuna bir yanıtın önceden üretilmesi mümkün olmadığından mevcut olmayan alanlara yönelik sorgulara yanıtları doğrulamaya çalışırken sorun oluşturur.

Bu probleme ilk çözüm, bir bölgedeki her alan çifti için NSEC kaydı oluşturmak şeklindeydi. Böylece, bir kullanıcı var olmayan k.example.com ‘daki bir kaydı sorguladığında, sunucu a.example.com ve z.example.com arasında hiçbir şeyin bulunmadığını belirten bir NSEC kaydıyla yanıt verir. Ancak bu, bölge hakkında daha fazla bilgiyi, gerçek alanlarının varlığını sızdırdığı için, geleneksel kimliği doğrulanmamış NXDOMAIN hatalarından daha fazla veri sızdırmaktadır.

NSEC3 kayıtları (RFC 5155) doğrudan isimleri listelemek yerine alternatif olarak isimlerin özetleriyle (hash fonksiyonu) listelemek için oluşturulmuştur. Zaman içinde, GPU’lar ve özel donanımlar kullanılarak özet fonksiyonundaki ilerlemeler, NSEC3 yanıtlarının çevrimdışı sözlük saldırıları ile kolaylıkla aşılabileceği anlamına geliyordu. NSEC5 13 Eylül 2018 tarihinde Wayback Machine sitesinde arşivlendi., yetkili sunucuların bölgeyi değiştirmek üzere kullanacağı özel bir anahtar bulundurmadan NSEC yanıtlarını imzalamasına izin vermesini önermiştir. Böylece bir NSEC5KEY‘in çalınması sadece bir bölgenin daha kolay sayılmasına neden olacaktır.

Protokolün dağınık evrimi ve geriye dönük uyumluluğu koruma isteğinden dolayı, çevrimiçi DNSSEC imzalama sunucuları, doğrudan bir varlığının reddini(denial of existence) doğrulamak yerine bir “beyaz yalan” döndürüyor. RFC 4470 ‘deki teknik ana hat, etki alanı çiftlerinin istenen etki alanını çevrelediği bir NSEC kaydı döndürür. Örneğin, k.example.com için yapılan bir istek, j.example.com ve l.example.com alan adlarının arasında hiçbir şeyin bulunmadığını kanıtlayan bir NSEC kaydı dönecektir. CloudFlare, “kayıt var, ancak istenen kayıt türü bulunmuyor” mesajıyla, önemli ölçüde azaltılmış veri yükü boyutuna sahip olduğunu kanıtlayan başka bir yaklaşıma öncülük etmiştir.

 

 

Paylaş:
Ulam:Nedir?
Etiket:,
Önceki Yazı
Monster Abra A5 V15.7 Kullanım Kılavuzu
Sıradaki Yazı
Pace DS830NDS Kullanım Kılavuzu