Azərbaycanca AzərbaycancaБеларускі БеларускіDansk DanskDeutsch DeutschEspañola EspañolaFrançais FrançaisIndonesia IndonesiaItaliana Italiana日本語 日本語Қазақ ҚазақLietuvos LietuvosNederlands NederlandsPortuguês PortuguêsРусский Русскийසිංහල සිංහලแบบไทย แบบไทยTürkçe TürkçeУкраїнська Українська中國人 中國人United State United StateAfrikaans Afrikaans
Destek
www.wikipedia.tr-tr.nina.az
  • Vikipedi

DNSSEC ingilizce Domain Name System Security Extensions Türkçe Alan Adı Sistemi Güvenlik Eklentileri internet Protok

Alan adı sistemi güvenlik eklentileri

Alan adı sistemi güvenlik eklentileri
www.wikipedia.tr-tr.nina.azhttps://www.wikipedia.tr-tr.nina.az

DNSSEC (İngilizce: Domain Name System Security Extensions, Türkçe: 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ı ( 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. Bakınız: RFC 4033, RFC 4034, and [rfc:4035 RFC 4035.] 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) veya 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şturuldu veya uyarlandı:

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 yetkili 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 var olan 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ı, var olan 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'ninki 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ı tamamlandı. 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'i 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 kat edildi. İ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üncellenmesi 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'te 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, var olan 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, 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 etti.

Dağıtım

İnternet hassas bir altyapıya sahiptir, ancak çalışması güvenli olmayan DNS'ye bağlıdır. Bu nedenle, DNS'yi güvence altına almak için güçlü bir teşvik vardır ve DNSSEC'i kullanmak bu çabanın temel bir parçası olarak kabul edilir. Örneğin, ABD Ulusal Siber Güvenlik Stratejisi özellikle DNS'nin güvenliğini sağlamanın gerektiğine değinmiştir. DNSSEC'in geniş çaplı dağıtımı, e-posta adresleri için güvenli anahtar dağıtımı gibi diğer birçok güvenlik problemini de çözebilir.

Büyük ölçekli ağlarda DNSSEC dağıtımı da oldukça zorlayıcıdır. Ozment ve Schechter, DNSSEC'in (ve diğer teknolojilerin) bir "bootstrap problemine" sahip olduğunu gözlemlemiştir. Yani kullanıcılar genellikle anında bir fayda elde ettikleri zaman bir teknolojiyi kullanırlar, ama herhangi bir kullanıcı bu teknoloji için yapacağı harcamadan daha büyük bir kazanç elde etmeden önce minimum düzeyde bir dağıtım gerekiyorsa (DNSSEC için olduğu gibi), dağıtımı zordur. DNSSEC, bir DNS hiyerarşisinin herhangi bir düzeyinde uygulanabilir, ancak diğerlerinin benimsemesini istemeden önce bir bölgede yaygın olarak bulunmalıdır. DNS sunucuları, DNSSEC'i destekleyen bir yazılımla güncelleştirilmeli, DNSSEC verileri oluşturulmalı ve DNS bölgesi verilerine eklenmelidir. Bir TCP/IP kullanan istemcinin, DNSSEC'in özelliklerini kullanabilmesi için DNS çözümleyicisinin (istemci) güncelleştirilmesi gerekir. Ek olarak, herhangi bir çözümleyici, DNSSEC kullanmaya başlamadan önce güvenebileceği en az bir ortak anahtarı olmalıdır veya anahtar elde etme yoluna sahip olmalıdır.

DNSSEC uygulaması bazı DNS sunucularına önemli yükler ekleyebilir. Ortak DNSSEC imzalı yanıtlar, 512 baytlık varsayılan UDP paketi boyutundan çok daha büyüktür. Teoride bu, birden fazla IP parçası kullanılarak çözülebilir, ama bu alandaki birçok "middlebox", bunları doğru şekilde çözemez. Bu UDP yerine TCP kullanılmasına yol açar. Yine de birçok TCP uygulaması, her bir TCP bağlantısı için çok büyük miktarda veri saklar; ağır yüklü sunucular, çok sayıda (ve muhtemelen sahte) DNSSEC isteklerine yanıt vermeye çalışarak kaynakların tükenmesine neden olabilir. Bu yüklemeyi azaltmak için TCP Çerez İşlemleri gibi bazı protokol uzantıları geliştirilmiştir. Bu zorlukları çözmek ve DNSSEC'i yaymak için önemli çabalar devam ediyor, çünkü internet birçok organizasyon için hayati önem taşıyor.

Erken dağıtımlar

İnternet ülke kodu üst düzey alan adı seviyesinde DNSSEC'i ilk kullananlar Brezilya (.br), Bulgaristan (.bg), Çekya (.cz), Namibya (.na)Puerto Rico (.pr) ve İsveç (.se), oldu; tarafından yetkilendirilmiş RIPE NCC'ye tüm geriye doğru arama kayıtlarını (in-addr.arpa) imzalattı. American Registry for Internet Numbers (ARIN)'a da ters bölgeleri imzalattı. Şubat 2007 İsveç'te Tele Danmark Communications (TDC), bu özelliği müşterilerine sunmaya başlayan ilk ISP oldu.

IANA, Haziran 2007'de örnek imzalı kökü[] test etti. Kökün üretiminin imzalanmasından önce bu süre zarfında, birkaç alternatif güven kaynağı da vardı. IKS Jena, 19 Ocak 2006'da bir tanesini uygulamaya koydu, İnternet Sistemleri Konsorsiyumu, aynı yılın 27 Mart tarihinde bir başkasının tanıtımı yaptı.ICANN ise 17 Şubat 2009'da üçüncüsünü duyurdu.

Çok çeşitli pilot projeler ve deneyler yapıldı. dnssec.net bu tür projelerin bir listesini tutar. Ayrıca, Dünya Çapında DNSSEC Dağıtımının bir Google Haritası var.

2 Haziran 2009 tarihinde, Public Interest Registry .org bölgesini imzaladı. PKR 26 Eylül 2008'de, ilk olarak büyük kayıt şirketlerinin ("arkadaş ve aile") güçlü bir çalışma ilişkisine sahip olduğu ilk aşamada, "erken 2009" dan başlayarak, alan adlarını imzalayabilecek ilk kişi olacağını açıklamıştır. 23 Haziran 2010'da, 13 kayıt memuru, .ORG alanları için DNSSEC kayıtları sundular.

VeriSign, .com ve .net alan adlarının NSEC3 denemesi amacıyla kayıt olması için bir pilot proje yürütmüştür. 24 Şubat 2009'da, DNSSEC'i 24 ay içinde tüm üst seviye alanlarına (.com, .net, .tr vb.) dağıtacağını açıkladılar ve aynı yılın 16 Kasım'ında .com ve .net alanları için, uygulanmasının teknik gecikmelerden sonra, 2011'in ilk çeyreğinde imzalanacağını belirttiler. Bu hedefe tam zamanlanan sürede ulaşıldı ve Verisign'ın DNSSEC Başkan Yardımcısı Matt Larson, DNSSEC'i ilerletme rolüyle 2011'de InfoWorld'ün Teknoloji Liderlik Ödülü'nü kazandı.

Kök DNS dağıtımı

DNSSEC ilk defa 15 Temmuz 2010 tarihinde kök düzeyinde dağıtıldı. Kök güven istasyonunun, kökten tam bir güven zincirine sahip olan DNSSEC bölgesini doğrulamak için kullanılabildiğinden, bunun DNSSEC çözümleyicilerinin dağıtımını büyük ölçüde basitleştirmesi beklenmektedir. Güven zinciri, doğrulanması için kesintisiz olarak güvenilen bir köke kadar takip edilmesi gerektiğinden, üst bölgelerden herhangi biri güvenli değilse, güvenin sağlanması için yeniden yapılandırılması gerekir. Örneğin, "signed.example.org" bölgesi güvenliyse ancak "example.org" bölgesi güvenli değilse, ".org" bölgesi ve kök imzalanmış olsa bile, bölgeyi doğrulamak için bir güven mekanizmasının dağıtılması gerekir.

Kökün imzalanmasına dair politik meseleler, esas olarak bazı temel meselelerle ilgili sürekli bir endişe kaynağı olmuştur:

  • Diğer ülkeler, ABD’nin İnternet üzerinden kontrolü konusunda endişeli ve bu sebeple herhangi bir merkezi anahtarlamayı reddedebilir.
  • Bazı hükûmetler DNSSEC destekli şifreleme anahtarı dağıtımını engellemeye çalışabilir.

Planlama

Eylül 2008'de ICANN ve VeriSign ayrı olarak birer uygulama önerisini yayınladı ve Ekim ayında Ulusal Telekomünikasyon ve Bilgi İdaresi (NTIA) kamuoyuna yorum istedi. Alınan yorumların son dağıtım planının tasarımını etkileyip etkilemediği belirsizdir.

Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), 3 Haziran 2009 tarihinde, ICANN, VeriSign ve NTIA ile birlikte 2009'un sonuna kadar kök imzalamayı planladığını duyurdu.

6 Ekim 2009'da, 59. RIPE Konferans toplantısında ICANN ve VeriSign, DNSSEC'in kök bölgesi içinde dağıtımı için planlanan dağıtım zaman çizelgesini duyurdu. Toplantıda, 1 Temmuz 2009 tarihinden başlayarak ayda bir kök ad sunucusuna dağıtılacağını açıkladı, 1 Temmuz 2010'da DNSSEC imzalı bir bölgeye hizmet veren son kök alan adı sunucusu bir kök bölgesi RSA / SHA256 DNSKEY ile imzalanacaktır. Artırımlı dağıtım süresi boyunca kök bölge, Deliberately Unvalidatable Root Zone (DURZ) hizmet edecektir ve 1 Temmuz 2010'da kadar dağıtılacak olan son DNSKEY kaydına kadar dağıtılmayacaktır. Bu, bölge kullanımını imzalamak için kullanılan anahtarların kasten doğrulanamayacağı anlamına gelir; bu dağıtımın nedeni, DNSSEC kaynak kayıtlarını isteyen sorgulara yapılan daha büyük yanıtların neden olduğu trafik modellerindeki değişiklikleri izlemek oldu.

.org üst düzey alan adı Haziran 2010'da DNSSEC ile imzalandı bunu 2010, 2011 ve sonrasında .com, .net ve .edu takip etti.Ülke kodu üst düzey alan adları, Mayıs 2010’dan itibaren anahtarları depolayabildi. Kasım 2011 itibarıyla, üst düzey alanların %25'inden fazlası DNSSEC ile imzalanmıştır.

Uygulama

25 Ocak 2010'da, L (ell) kök sunucusu DURZ hizmetini vermeye başladı. Bölge, RFC 5702'de tanımlandığı gibi RSA algoritması kullanılarak oluşturulan bir SHA-2 (SHA-256) karma imzasını kullanır. Mayıs 2010 itibarıyla, 13 kök sunucunun hepsi DURZ hizmeti vermeye başladı. 15 Temmuz 2010'da, ilk tam kök üretimli DNSSEC kök bölgesi, SOA 2010071501 seri numarasıyla imzalandı. Kök güvenleri IANA'dan temin edilebilir.

TLD düzeyinde dağıtım

Kökün altında, tam DNSSEC dağıtımının gerçekleştirilmesi için imzalanması gereken büyük bir üst düzey alan adı(top level domain) kümesi bulunur. Internet üst düzey alan adlarının listesi, mevcut üst düzey alan adlarından hangilerinin imzalandığına ve köke bağlı olduğuna ilişkin ayrıntılar sağlar.

DNSSEC Denetleme Doğrulaması

2006 Mart ayında, Internet Systems Consortium (ISC), DNSSEC Denetleme Doğrulaması(DNSSEC Lookaside Validation - DLV) kayıt defterini tanıttı. DLV'nin amacı, bir kök güven istasyonu olmadığında DNSSEC'in dağıtımını kolaylaştırmaktı. Bu durumda bir doğrulayıcının, DNS’nin imzalı altkümelerine karşılık gelen çok sayıda güven bağı oluşturmak zorunda kalacağı düşünüldü. DLV'nin amacı, doğrulayıcıların güvenilir bir üçüncü tarafa bir güven istasyonunu yönetmeye gerek kalmamasını sağlamaktı. DLV kayıt defteri, kendi listelerini sürdürme çalışmalarını yineleyen her bir doğrulayıcı yerine, güven istasyonlarının merkezi bir listesini tutmaktadır.

DLV kullanmak için, bir DLV bölgesi için bir güven çapası ile yapılandırılmış Bind veya Unbound gibi bir destekleyici gereklidir. Bu bölge DLV kayıtlarını içerir; bu kayıtlar, DS kayıtlarıyla tam olarak aynı biçime sahiptir, ancak bir temsilci alt bölgeye başvurmak yerine, DNS ağacında başka bir bölgeye başvururlar. Doğrulayıcı, kökten RRset'e bir güven zinciri bulamadığında, tekrar kontrol etmeye çalışır, alternatif bir güven zinciri sağlayabilen bir DLV kaydını arar.

DNSSEC yetkilerini desteklemeyen üst düzey alan adları veya kayıt şirketleri gibi güven zincirindeki boşluklar, alt düzey etki alanlarındaki yöneticilerin DLV'yi, DNS verilerinin, DLV'yi kullanmak üzere yapılandırılan çözücüler tarafından doğrulanmasını sağlamak için kullanabilir. Bu, DNSSEC dağıtımını doğru bir şekilde desteklemek için kayıt memurları ve TLD kayıtlarından baskı alarak DNSSEC dağıtımını engelleyebilirdi. DLV ayrıca DNSSEC doğrulaması için daha fazla katılımcı ve kod yolu ekleyerek karmaşıklığı artırır. Bu durum daha fazla belirsizliği ortaya çıkarmaktadır çünkü doğrulayıcı çözümleyicilerin tümü DLV'yi ya desteklememekte ya da kullanmamaktadır. Bir çözümleyiciyi sorgulayan istemciler, farklı bir doğrulayıcı çözümleyici kullanan istemciler tarafından desteklenmezken, DLV doğrulanmış yanıtları alabilir.

DLV yaygın olarak kullanılamamıştır. Mayıs 2015'e kadar, ISC'nin DLV kaydı toplam 5.000 alan adının altında ve bunların %10'dan daha azında imzasız bir ana alan adı vardı. ISC, DLV kaydını iptal etme planını açıkladı. DLV desteğinin BIND'den ve doğrulama çözümleyicilerinin diğer uygulamalarından kaldırılacağı henüz belli değildir.

ABD Federal Hükümeti tarafından DNSSEC dağıtım girişimi

ABD İç Güvenlik Bakanlığı (DHS) Bilim ve Teknoloji Müdürlüğü, "DNSSEC Dağıtım Girişimi"ni destekliyor. Bu girişim, tüm sektörleri, internet ve adlandırma altyapısının güvenliğini artıracak güvenlik tedbirlerini gönüllü olarak benimsemeye teşvik ediyor, ayrıca kamu ve özel sektördeki birçok ülke ve örgütü içeren küresel, işbirlikçi çabaların bir parçası. DHS ayrıca, DNSSEC'i geliştirmek ve ABD federal hükümetine dağıtılmak için çaba sarf ediyor.

30 Mart 2007'de ABD Dışişleri Bakanlığı Güvenlik Dairesi Başkanlığı'nın “DNS kökenini ABD hükümetinin elinde sağlam bir şekilde imzalamanın anahtarı olması” önerildi. Ancak toplantı odasında ABD Hükûmeti yetkililerinden kimse yoktu ve makaleyi başlatan yorum başka bir taraftan yapılmıştı. DHS daha sonra başkalarının ABD Hükûmeti'nin böyle bir öneride bulunmuş olduğu gibi yanlış bir sonuca vardığına inandıklarını şöyle açıkladı: “ABD İç Güvenlik Bakanlığı, DNSSEC'i uygulamak için teknik bir planın geliştirilmesini finanse ediyor ve son olarak Ekim ayında, ilk taslağını yorumlar için uluslararası uzmanların uzun bir listesine dağıttı. Taslak, temel olarak bir devlet kurumuna veya yükleniciye kaynayan Kök Bölge Anahtarının sahibi veya operatörü olabilmeleri için bir dizi seçenek ortaya koymaktadır. "Bu belgede hiçbir yerde Kök Anahtar Operatörünün kimliği ile ilgili herhangi bir öneride bulunmuyoruz," şeklinde Homeland Security'nin Siber Güvenlik Araştırma ve Geliştirme Müdürü Maughan açıklama yaptı.

ABD Federal Hükümeti'nde DNSSEC dağıtımı

Ulusal Standartlar ve Teknoloji Enstitüsü (NIST), 16 Mayıs 2006 tarihinde NSS Özel Yayını 800-81 Güvenli Alan Adı Sistemi (DNS) Dağıtım Kılavuzu'nu yayınladı ve DNSSEC'in nasıl dağıtılacağı konusunda rehberlik etti. NIST, NIST SP800-53-R1'deki yeni DNSSEC Federal Bilgi Güvenliği Yönetimi Yasası (FISMA) gerekliliklerini yayınlamayı planladı ve bu dağıtım kılavuzuna başvurdu. ABD ajansları, NIST SP800-53-R1'in bu yeni FISMA gerekliliklerini yerine getirmeleri için bir yıl sonra yayınlanacaktı. Ancak, NSEC3 zamanında tamamlanamadı. NIST, mümkün olduğu bilinen ancak doğru bir şekilde dağıtılması zor olan ve yukarıda belirtilen güvenlik zaaflarına sahip olan bölünmüş alan adlarını kullanmayı önerdi.

22 Ağustos 2008'de, Yönetim ve Bütçe Bürosu (OMB), ABD Federal Ajanslarının DNSSEC'yi .gov siteleri arasında dağıtmasını gerektiren bir bildiri yayınladı; .gov kökü Ocak 2009'a kadar imzalanmış olmalı ve .gov altındaki tüm alt alanların Aralık 2009'a kadar imzalanması gerekir. Bildiri, .gov sitelerine odaklanırken, ABD Savunma Bilgi Sistemleri Dairesi, aynı zamanda .mil (ABD askeri) alanında da OMB DNSSEC gereksinimlerini karşılamayı planladığını açıkladı. NetworkWorld'den Carolyn Duffy Marsan, DNSSEC'in "yaygın bir şekilde dağıtılmadığını, çünkü klasik bir tavuk ve yumurta ikileminden acı çektiğini ve OMB'nin görevinin yumurtanın çatlamasına neden olmak olduğunu" söyledi.

Çözümleyicilerin dağıtımı

Birkaç ISP, DNSSEC doğrulayan DNS özyineli çözümleyicilerini dağıtmaya başladı. Comcast, Amerika Birleşik Devletleri'nde 18 Ekim 2010'da yapacağını açıkladı ve 11 Ocak 2012'de dağıtımını tamamlayan ilk büyük ISP oldu.

APNIC'de yapılan bir araştırmaya göre, DNSSEC doğrulama işlemini gerçekleştiren DNS çözümleyicilerini kullanan istemcilerin oranı, Mayıs 2013'te %8,3'e yükseldi. yarım müşterilerin edildi kullanarak Google genel DNS çözümleyici.

Eylül 2015'te Verisign, halka açık ücretsiz DNS çözümleme hizmetini duyurdu ve basında belirtilmemiş olmasına rağmen, DNSSEC doğrulaması hizmetini de gerçekleştiriyor.

2016 yılının başında, APNIC'in araştırmasına göre, DNSSEC doğrulama işlemini gerçekleştiren DNS çözümleyicilerini kullanan müşterilerin oranının yaklaşık %15'e çıkmış olduğunu gösterdi.

Google Genel DNS

Google Genel DNS, DNSSEC'i tamamen destekleyen, ücretsiz olarak sağlanan bir genel DNS hizmetidir.

2009'daki lansmanında Google Genel DNS, DNSSEC'i desteklemiyordu. RRSIG kayıtları sorgulanabiliyor, ancak AD bayrağı (sunucunun, tüm veriler için imzaları doğrulayabilmesi anlamına gelen kimliği doğrulanmış veri) asla ayarlanamıyordu.

28 Ocak 2013'te, Google'ın DNS sunucuları, DNSSEC doğrulama bilgileri sağlamaya sessizce başladı, ancak yalnızca istemcinin kendi sorgusunda DNSSEC OK (DO) işaretini açıkça belirlemesi durumunda çalışıyordu.

6 Mayıs 2013'te, Google Genel DNS, DNSSEC doğrulamasını varsayılan olarak etkinleştirdi; istemciler açıkça belirtmediği sürece tüm sorguların doğrulanacağı anlamına gelir.

Sorunlar

Microsoft Exchange 2013'te MX kayıt aramasını kırdığı ve daha büyük olan #550 4.4.7QUEUE'nun neden olduğu bilinmektedir.

IETF standartları

  • RFC 2535: Domain Name System Security Extensions
  • RFC 3833: A Threat Analysis of the Domain Name System
  • RFC 4033: DNS Security Introduction and Requirements (DNSSEC-bis)
  • RFC 4034: Resource Records for the DNS Security Extensions (DNSSEC-bis)
  • RFC 4035: Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
  • RFC 4398: Storing Certificates in the Domain Name System (DNS)
  • RFC 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing
  • RFC 4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
  • RFC 5155: DNSSEC Hashed Authenticated Denial of Existence
  • RFC 6781: DNSSEC Operational Practices, Version 2
  • RFC 6840: Clarifications and Implementation Notes for DNS Security (DNSSEC)

Araçlar

DNSSEC dağıtımı, sunucu ve istemci tarafında yazılım olmasını gerektirir. DNSSEC'yi destekleyen araçlardan bazıları şunlardır:

  • Windows 7 ve Windows Server 2008 R2, yinelemeli ad sunucusu tarafından güvenli ve güvenli olmayan yanıtlar arasında ayrım yapabilen bir "güvenlik farkındalık" saptama çözümleyicisi içerir. Windows Server 2012 DNSSEC, Active Directory ile tümleşik bölgelerle güvenli dinamik güncelleştirmeler ve buna ek olarak güven anahtarlarının diğer sunuculara Active Directory dağıtmasıyla uyumludur.
  • BIND en popüler DNS isim sunucusudur, yeni DNSSEC-bis (DS kayıtları) protokolünü ve NSEC3 kayıtlarının desteğini içerir.
  • Drill 10 Ekim 2017 tarihinde Wayback Machine sitesinde ., ldns 7 Mart 2018 tarihinde Wayback Machine sitesinde . ile birlikte bir DNSSEC-etkin "dig" benzeri bir araçtır.
  • , Mozilla Firefox'a bir alanın DNSSEC ile doğrulanıp doğrulanamadığını belirleme yeteneğini verir.
  • DNSSEC-Tools, her tür yönetici ve kullanıcının DNSSEC'den yararlanmalarına yardımcı olmak için kullanımı kolay araçlar sağlamayı amaçlamaktadır. , ve yöneticileri için olan araçların yanı sıra için bir kitaplık ve araçlar ve 18 Eylül 2009 tarihinde Wayback Machine sitesinde . genişletmek için mevcut yamalar için araçlar sunar.
  • Phreebird 17 Aralık 2010 tarihinde Wayback Machine sitesinde ., herhangi bir DNS sunucusunun üzerine DNSSEC desteği ekleyebilen bir DNS proxydir.
  • Zone Key Tool 25 Mart 2018 tarihinde Wayback Machine sitesinde ., DNSSEC kullanılan bölgelerinin bakımını kolaylaştırmak için tasarlanmış bir yazılımdır. Öncelikle küçük ila orta ölçekli bölgelere sahip ortamlar için tasarlanmıştır ve bölgenin otomatik olarak istifade edilmesinin yanı sıra tam otomatik bölge imzalama anahtarının aktarılmasını sağlar.
  • Unbound 5 Nisan 2018 tarihinde Wayback Machine sitesinde . DNSSEC kavramları etrafında tasarlanacak şekilde sıfırdan yazılmış bir DNS ad sunucusudur.
  • , Microsoft Windows için kompakt, kurulumu kolay bir DNSSEC isim sunucusudur.
  • mysqlBind, DNS ASP'leri için GPL DNS yönetim yazılımı artık DNSSEC'i destekliyor.
  • OpenDNSSEC, Donanım Güvenlik Modülleri ile arabirim kurmak için PKCS#11 kullanan bir DNSSEC imzalayıcı aracıdır.
  • , DNSSEC dağıtımını ve bölgeleri izler ayrıca izlenen genel anahtarların bir listesini sunar.
  • DNSViz 30 Mart 2018 tarihinde Wayback Machine sitesinde . ve DNSSEC Analyzer 17 Eylül 2020 tarihinde Wayback Machine sitesinde ., bir alanın DNSSEC kimlik doğrulama zincirini görselleştirmek için Web tabanlı araçlardır.
  • DNSSEC/TLSA Validator 2 Haziran 2018 tarihinde Wayback Machine sitesinde ., ziyaret edilen alan adının DNSSEC durumunun görselleştirilmesi için bir Mozilla Firefox eklentisidir; DNSSEC/TLSA Validator 2.1, TLSA kayıtlarının (DANE) durumunu kontrol etmek ve görselleştirmek için destek eklenmiştir.
  • DNSSHİM 14 Şubat 2014 tarihinde Wayback Machine sitesinde . veya DNS Secure Hidden Master, DNSSEC destekli bölgeler için sağlama sürecini otomatikleştirmek için açık kaynaklı bir araçtır.
  • Net::DNS::SEC 6 Nisan 2018 tarihinde Wayback Machine sitesinde ., Perl dili kullanılarak yazılmış bir DNS çözümleyicisidir.
  • Knot DNS, 1.4.0 sürümünde otomatik olarak DNSSEC imzalama desteğini ekledi.
  • PowerDNS, önceden imzalanmış ve canlı imzalı modlarda sürüm 3.0'dan itibaren DNSSEC'i tam olarak destekler.
  • Net_DNS2 7 Nisan 2018 tarihinde Wayback Machine sitesinde ., PHP dili kullanılarak yazılmış bir DNS çözümleyicisidir.
  • DNSd, Google DNS üzerinden HTTPS 20 Mart 2018 tarihinde Wayback Machine sitesinde . sağlayan C dili kullanılarak yazılmış bir DNS çözümleyicisidir.

Ayrıca bakınız

    Kaynakça

    1. ^ . Microsoft. 26 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Ekim 2009. The Windows DNS client is a stub resolver... 
    2. ^ a b c . Microsoft. 26 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 21 Ekim 2009. The DNS client in Windows Server 2008 R2 and Windows® 7 is a non-validating security-aware stub resolver. 
    3. ^ a b c d Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006), Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín (Ed.), "Enabling Practical IPsec Authentication for the Internet" (PDF), On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops, Microsoft, Springer, 1, 26 Nisan 2012 tarihinde (PDF) arşivlendi, erişim tarihi: 21 Ekim 2009 KB1 bakım: Editörler parametresini kullanan ()
    4. ^ a b c d RFC 4033: DNS Security Introduction and Requirements". The Internet Society. March 2005: 12.
    5. ^ , IANA, 12 Temmuz 2010, 19 Eylül 2018 tarihinde kaynağından arşivlendi, erişim tarihi: 17 Temmuz 2010 
    6. ^ Conrad, D., , Internet Engineering Task Force, 4 Nisan 2016 tarihinde kaynağından arşivlendi, erişim tarihi: 27 Nisan 2017 
    7. ^ . 10 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    8. ^ "Arşivlenmiş kopya". 7 Nisan 2018 tarihinde kaynağından . Erişim tarihi: 6 Nisan 2018. 
    9. ^ RFC 4033: DNS Security Introduction and Requirements". The Internet Society. March 2005: 11. "RFC 1123 - Requirements for Internet Hosts -- Application and Support". IETF (Internet Engineering Task Force): 74.
    10. ^ . 10 Ağustos 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    11. ^ . 9 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    12. ^ . 2 Şubat 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    13. ^ . 7 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 26 Kasım 2011. 
    14. ^ . 17 Aralık 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Mart 2013. 
    15. ^ . 2 Haziran 2018 tarihinde kaynağından arşivlendi. 
    16. ^ . 6 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    17. ^ Steve Bellovin (1995). . 26 Şubat 2008 tarihinde kaynağından arşivlendi. 
    18. ^ . 6 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    19. ^ . 6 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    20. ^ (PDF). Şubat 2003. s. 30. 22 Mayıs 2018 tarihinde kaynağından (PDF) arşivlendi. 
    21. ^ Metzger, Perry; William Allen Simpson; Paul Vixie. "Improving TCP security with robust cookies" (PDF). Usenix. 7 Nisan 2018 tarihinde kaynağından (PDF). Erişim tarihi: 17 Aralık 2009. 
    22. ^ . 19 Ağustos 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    23. ^ , Electronic Privacy Information Center (EPIC), 27 Mayıs 2008, 28 Mayıs 2018 tarihinde kaynağından arşivlendi 
    24. ^ . 22 Ekim 2007 tarihinde kaynağından arşivlendi. 
    25. ^ . 6 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    26. ^ Eklund-Löwinder, Anne-Marie (12 Şubat 2012). "[dns-wg] Swedish ISP TCD Song Adopts DNSSEC". dns-wg mailing list. RIPE NCC. 6 Nisan 2018 tarihinde kaynağından . Erişim tarihi: 2 Aralık 2012. 
    27. ^ . 5 Mart 2007 tarihinde kaynağından arşivlendi. 
    28. ^ . 18 Kasım 2008 tarihinde kaynağından arşivlendi. 
    29. ^ . 12 Eylül 2009 tarihinde kaynağından arşivlendi. 
    30. ^ . 29 Haziran 2011 tarihinde kaynağından arşivlendi. 
    31. ^ . 10 Nisan 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 5 Ekim 2020. 
    32. ^ Sean Michael Kerner. . www.internetnews.com. 7 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Ağustos 2009. 
    33. ^ . 12 Haziran 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Haziran 2010. 
    34. ^ . 3 Mart 2009 tarihinde kaynağından arşivlendi. 
    35. ^ . 19 Kasım 2009 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    36. ^ ".com Domain Finally Safe". 23 Ocak 2013 tarihinde kaynağından arşivlendi. Erişim tarihi: 23 Ocak 2013. 
    37. ^ . 7 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    38. ^ "The InfoWorld 2011 Technology Leadership Awards". 19 Temmuz 2014 tarihinde kaynağından . Erişim tarihi: 6 Nisan 2018. 
    39. ^ . 16 Temmuz 2010. 8 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    40. ^ Singel, Ryan (8 Ekim 2006). . Wired News. CondéNet. 9 Ekim 2008 tarihinde kaynağından arşivlendi. Erişim tarihi: 9 Ekim 2008. 
    41. ^ "Press Release: NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System" (Basın açıklaması). National Telecommunications and Information Administration, U.S. Department of Commerce. 9 Ekim 2008. 13 Ekim 2008 tarihinde kaynağından . Erişim tarihi: 9 Ekim 2008. 
    42. ^ "Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet's Domain Name and Addressing System" (Basın açıklaması). National Institute of Standards and Technology. 3 Haziran 2009. 29 Haziran 2011 tarihinde kaynağından . Erişim tarihi: 6 Nisan 2018. 
    43. ^ "DNSSEC for the Root Zone" (PDF). 
    44. ^ Hutchinson, James (6 Mayıs 2010). "ICANN, Verisign place last puzzle pieces in DNSSEC saga". NetworkWorld. 20 Aralık 2013 tarihinde kaynağından . Erişim tarihi: 6 Nisan 2018. 
    45. ^ . 15 Mart 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Mart 2010. 
    46. ^ "The Inquirer: Verisign deploys DNSSEC on .com TLD". 23 Aralık 2019 tarihinde kaynağından . Erişim tarihi: 6 Nisan 2018. 
    47. ^ . Heise Online. 24 Mart 2010. 19 Ocak 2019 tarihinde kaynağından arşivlendi. 
    48. ^ . 6 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    49. ^ (PDF). 4 Mart 2016 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    50. ^ RFC 5702, §2.1. "RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number 8."
    51. ^ RFC 5702, §3.1. "RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8."
    52. ^ . 14 Haziran 2011 tarihinde kaynağından arşivlendi. 
    53. ^ RFC 5011, "Automated Updates of DNS Security (DNSSEC) Trust Anchors"
    54. ^ RFC 4431, "The DNSSEC Lookaside Validation (DLV) DNS Resource Record"
    55. ^ RFC 5074, "DNSSEC Lookaside Validation (DLV)"
    56. ^ (PDF). 25 Ağustos 2016 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    57. ^ . Heise News. 30 Mart 2007. 6 Nisan 2007 tarihinde kaynağından arşivlendi. 
    58. ^ . UPI. 21 Nisan 2007. 12 Şubat 2009 tarihinde kaynağından arşivlendi. 
    59. ^ . 7 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Mart 2011. First link is dead, this is believed to be the same content 
    60. ^ . Haziran 2006. 22 Kasım 2007 tarihinde kaynağından arşivlendi. 
    61. ^ (PDF). Executive Office Of The President — Office Of Management And Budget. 22 Ağustos 2008. 16 Eylül 2008 tarihinde kaynağından (PDF) arşivlendi. 
    62. ^ . Network World. 22 Eylül 2008. 25 Eylül 2008 tarihinde kaynağından arşivlendi. 
    63. ^ . 22 Ekim 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Ekim 2010. 
    64. ^ . 21 Ekim 2010 tarihinde kaynağından arşivlendi. Erişim tarihi: 18 Ekim 2010. 
    65. ^ . 13 Şubat 2012 tarihinde kaynağından arşivlendi. Erişim tarihi: 11 Ocak 2012. 
    66. ^ . 1 Temmuz 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    67. ^ . 20 Kasım 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    68. ^ . 24 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    69. ^ . 11 Kasım 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Ocak 2013. nanog mailing list archives 
    70. ^ . Google Code Blog. 10 Şubat 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Haziran 2013. 
    71. ^ . 24 Ekim 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    72. ^ Seshadri, Shyam (11 Kasım 2008). . Port 53. Microsoft. 7 Kasım 2009 tarihinde kaynağından arşivlendi. Erişim tarihi: 6 Nisan 2018. 
    73. ^ (PDF). 29 Temmuz 2016 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 6 Nisan 2018. 

    Dış bağlantılar

    • DNSSEC 23 Aralık 2017 tarihinde Wayback Machine sitesinde .- DNSSEC bilgi sitesi: DNSSEC.net
    • DNS Uzantıları IETF Çalışma Grubu
    • DNSSEC- Proje Araçları 11 Eylül 2009 tarihinde Wayback Machine sitesinde .
    • DNSSEC Dağıtım Koordinasyon Girişimi 4 Nisan 2018 tarihinde Wayback Machine sitesinde .
    • DNSSEC Dağıtım Ekibi 10 Eylül 2017 tarihinde Wayback Machine sitesinde .
    • ICANN DNS Operasyon Ekibi 18 Temmuz 2014 tarihinde Wayback Machine sitesinde .
    • DNSSEC is unnecessary - Against DNSSEC 2 Şubat 2018 tarihinde Wayback Machine sitesinde .
    • DNSSEC is necessary - For DNSSEC 11 Ocak 2017 tarihinde Wayback Machine sitesinde .

    wikipedia, wiki, viki, vikipedia, oku, kitap, kütüphane, kütübhane, ara, ara bul, bul, herşey, ne arasanız burada,hikayeler, makale, kitaplar, öğren, wiki, bilgi, tarih, yukle, izle, telefon için, turk, türk, türkçe, turkce, nasıl yapılır, ne demek, nasıl, yapmak, yapılır, indir, ücretsiz, ücretsiz indir, bedava, bedava indir, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, resim, müzik, şarkı, film, film, oyun, oyunlar, mobil, cep telefonu, telefon, android, ios, apple, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, pc, web, computer, bilgisayar

    DNSSEC Ingilizce Domain Name System Security Extensions Turkce Alan Adi Sistemi Guvenlik Eklentileri Internet Protokolu IP aglarinda kullanilan Alan Adi Sistemi DNS tarafindan saglanan belirli turdeki bilgilerin guvenligini saglamaya yonelik bir Internet Muhendisligi Gorev Grubu IETF dokumanidir DNS istemcilerine cozumleyicilerine DNS verilerinin koken kimlik dogrulamasi kimlik dogrulamasi reddi ve veri butunlugunu saglayan ancak kullanilabilirlik veya gizlilik saglamayan bir DNS eklentisidir Genel bakisAlan Adi Sistemi DNS ozgun tasariminda hicbir guvenlik onlemi icermez Olceklendirilebilir dagitilmis bir sistem olarak tasarlanmistir Alan Adi Sistemi Guvenlik Eklentileri DNSSEC geriye donuk uyumlulugu korurken guvenlik onlemleri eklemeye calisir RFC 3833 DNS ile ilgili bilinen bazi tehditleri ve DNSSEC in bu tehditlere nasil yanit verdigini belgelemektedir DNSSEC sahte veya manipule edilmis DNS verilerinden DNS onbellek zehirlenmesi ile olusturulan veriler gibi uygulamalari korumak icin ve bu uygulamalara hizmet eden cozumleyicileri onbellege almak kullanilacak sekilde tasarlanmistir DNSSEC korumasiyla gelen tum cevaplar dijital olarak imzalanmistir Bir DNS cozumleyici dijital imzayi kontrol ederek bilgilerin alan sahibi tarafindan yayinlanan ve yetkili bir DNS sunucusunda sunulan bilgilerle ayni yani degistirilmemis ve tam olup olmadigini kontrol edebilir IP adreslerini korumak bircok kullanici icin en oncelikli endise olsa da DNSSEC DNS de yayinlanan tum veriyi koruyabilir metin kayitlari TXT gibi e posta degisim kayitlari MX gibi ve DNS de saklanan kriptografik sertifikalara basvuru yayinlayan diger guvenlik sistemlerini saklamak icin de kullanilabilir ornegin Sertifika Kayitlari records RFC 4398 SSH parmak izleri SSHFP RFC 4255 IPSec acik anahtarlari IPSECKEY RFC 4025 ve TLS Trust Anchors TLSA RFC 6698 DNSSEC verinin gizliligini saglamaz butun DNSSEC cevaplari dogrulanmistir ancak sifrelenmez DNSSEC DoS ataklarina karsi dogrudan korumaz ancak dolayli olarak bazi faydalar saglar cunku imza kontrolu guvenilir olmayan taraflarin kullanimina izin verir bu ancak DNS sunucusu kendinden imzali bir sertifika kullaniyorsa dogrudur internet baglantili DNS sunuculari icin onerilmez DNS sunuculari arasinda gonderilen toplu verileri DNS zone transferi gibi guvenli hale getirmek icin diger standartlar DNSSEC olmayan kullanilir IETF RFC 4367 de dokumente edildigi gibi bazi kullanicilar ve gelistiriciler DNS adlari hakkinda yanlis tahminler yapmaktadir ornegin bir sirketin genel adi arti com her zaman onun alan adidir gibi DNSSEC yanlis denemelere karsi korumaz sadece verinin gercekte alan sahibinden alindigini veya uygun olmadigini dogrulayabilir DNSSEC ozellikleri DNSSEC bis olarak adlandirilir gecerli DNSSEC protokolunu detayli olarak aciklar Bakiniz RFC 4033 RFC 4034 and rfc 4035 RFC 4035 Bu yeni RFC lerin yayinlanmasiyla Mart 2005 daha onceki RFC RFC 2535 gecmiste kalmistir Internetin bir butun olarak guvenceye alinmasi icin DNS in guvence altina alinmasinin kritik oneme sahip olduguna inanilmaktadir ancak DNSSEC in yayilmasi ozellikle bazi zorluklar ile aksamistir 22 Ocak 2010 dan beri Internet boyutuna gore olceklenebilen geriye yonelik uyumlu bir standart tasarlama ihtiyaci Istenildiginde bolge DNS zone ayrintili listesi korumasi Cok genis alanda yayilmis DNS sunuculari ve cozumleyicileri istemciler genelinde DNSSEC uygulamalarinin yayilmasi Ust seviye alan kok anahtarlarina kimin sahip olmasi gerektigi konusunda uygulayicilar arasindaki anlasmazlik DNSSEC ve DNSSEC yayiliminin algilanan zorlugunu karmasikligini asmak Microsoft Windows un kullandigi saplama cozumleyici Ozellikle Windows 7 ve ustu gecerliligi olmayan ancak DNSSEC uyumlu bir turdur DNSSEC hizmetlerine gercek bir guvenin yerlestirilmesi icin bu saplama cozumleyici soz konusu yinelemeli ad sunucularina genellikle ISP tarafindan denetlenir ve kendisi ile bu ad sunuculari arasindaki iletisim kanallarina IPsec cok fazla yayilmamis olanin kullanimiyla SIG 0 veya TSIG gibi yontemler kullanarak guvenmelidir IslemlerDNSSEC DNS sorgulari icin kayitlari acik anahtar sifrelemesi ile dijital olarak imzalayarak calisir Dogru DNSKEY kaydi bir guven zinciri araciligiyla dogrulanir Bu zincir guvenilir ucuncu taraf olan DNS kok bolgesi DNS root zone icin bir dizi onaylanmis acik anahtarla baslar Alan sahipleri kendi anahtarlarini olusturur ve DNS kontrol panellerini kullanarak alan adi kayit sitelerine yuklerler Burasi da anahtarlari secDNS araciligiyla bolge operatorune orn com icin Verisign gonderir ve bunlari DNS de imzalar ve yayinlar Kaynak kayitlari DNS cesitli kaynak kayitlarinin kullanilmasiyla gerceklestirilir DNSSEC i uygulamak icin DNSsec ile kullanilmak uzere birkac yeni DNS kayit turu olusturuldu veya uyarlandi RRSIG kaynak kayit imzasi Bir kayit grubu icin DNSSEC imzasini icerir DNS cozumleyicileri imzayi DNSKEY kaydinda saklanan acik anahtarla dogrular DNSKEY Bir DNS cozumleyicisinin RRSIG kayitlarindaki DNSSEC imzalarini dogrulamak icin kullandigi acik anahtari icerir DS yetkili imzalayan Yetkili bolgenin adini tutar Bir alt yetkili bolgedeki bir DNSKEY kaydina basvurur DS kaydi temsilci NS kayitlari ile birlikte ust bolgeye yerlestirilir NSEC bir sonraki guvenli kayit Bolgedeki bir sonraki kayit adina bir baglanti icerir ve kaydin adi icin var olan kayit turlerini listeler DNS cozumleyicileri bir kayit adinin bulunmadigini dogrulamak icin NSEC kayitlarini kullanir ve DNSSEC dogrulamasinin bir parcasi olarak yazar NSEC3 siradaki guvenli kayit versiyon 3 Bolgedeki bir sonraki kayit adinin karistirilmis isim sirasi duzeninde baglantilarini icerir ve NSEC3 kaydinin kendi adinin ilk etiketindeki hash degerinin kapsadigi ad icin var olan kayit tiplerini listeler Bu kayitlar bir kayit adinin bulunmadigini dogrulamak ve DNSSEC dogrulamasinin bir parcasi olarak yazmak icin cozuculer tarafindan kullanilabilir NSEC3 kayitlari NSEC kayitlarina benzerdir ama NSEC3 bir bolgedeki kayit adlarinin numaralandirilmasini sayilmasini onlemek icin kriptografik olarak karistirilmis hashed kayit adlari kullanir NSEC3PARAM siradaki guvenli kayit versiyon 3 parametreleri Yetkili DNS sunuculari var olan adlar turler icin DNSSEC isteklerine yanitlari icerecek NSEC3 kayitlarini hesaplamak ve belirlemek icin bu kaydi kullanir DNSSEC kullanildiginda her DNS sorgu yaniti istenen kayit turune ek olarak bir RRSIG DNS kaydi icerir RRSIG kaydi DNS yaniti yanit kumesinin dijital imzasidir Dijital imza bir DNSKEY kaydinda bulunan dogru ortak anahtarin yerini belirleyerek dogrulanir NSEC ve NSEC3 kayitlari herhangi bir RR nin varliginin kriptografik kanitlarini saglamak icin kullanilir DS kaydi guven zincirini kullanarak sorgu yordaminda DNSKEY lerin kimlik dogrulamasinda kullanilir NSEC ve NSEC3 kayitlari sahtecilige karsi dayaniklilik icin kullanilir Algoritmalar DNSSEC genisletilebilecek sekilde tasarlanmistir boylece mevcut algoritmalara karsi saldirilar kesfedildikce geriye dogru uyumlu bir sekilde yenileri eklenebilir Asagidaki tablo en cok kullanilan guvenlik algoritmalarini Nisan 2013 itibariyla tanimlamaktadir Algoritma alani Algoritma Kaynak Uygulama durumu1 RSA MD5 Uygulanmamali3 DSA SHA 1 Istege Bagli5 RSA SHA 1 RFC 3110 Gerekli7 RSASHA1 NSEC3 SHA1 RFC 5155 Onerilen8 RSA SHA 256 RFC 5702 Onerilen10 RSA SHA 512 Onerilen Onerilen12 GOST R 34 10 2001 RFC 5933 Istege Bagli13 ECDSA SHA 256 RFC 6605 Onerilen14 ECDSA SHA 384 Onerilen Onerilen15 Ed25519 RFC 8080 Istege Bagli16 Ed448 RFC 8080 Istege BagliSorgu Proseduru Bir DNS sorgusunun sonuclarindan guvenlik bilinci olan bir DNS cozumleyici sorgulanan alan icin yetkili ad sunucusunun DNSSEC i destekleyip desteklemedigini yanitin guvenli olup olmadigini ve bir cesit hata olup olmadigini belirleyebilir Sorgu proseduru bircok ISP ninki gibi yinelemeli ad sunuculari ve ana akim isletim sistemlerinde olan saplama cozuculerden farklidir Microsoft Windows un kullandigi saplama cozumleyici Windows Server 2008 R2 Windows 7 de ozellikle gecerliligi olmayan ama DNSSEC uyumlu bir saplama cozumleyicisidir Yinelemeli ad sunuculari Guven modeli zincirini kullanarak ust etki alanindaki DNS zone bir Yetkili Imzalayici DS kaydi bir alt etki alanindaki bir DNSKEY kaydini dogrulamak icin kullanilabilir bu daha sonra alt etki alanlarini dogrulamak icin diger DS kayitlarini da icerebilir ISP ad sunucusu gibi ozyinelemeli bir cozumleyicinin www example com alan adinin IP adreslerini A kaydi ve veya AAAA kayitlari almak istedigini varsayalim 1 Guvenlik tanili bir cozumleyici bir DNS sorgusunda DO DNSSEC OK isaret biti ayarladiginda islem baslar DO biti EDNS tarafindan tanimlanan genisletilmis bayrak bitlerinden oldugundan tum DNSSEC islemleri EDNS yi desteklemelidir Ayrica DNSSEC islemlerinin gerektirdigi daha buyuk paket boyutlarina izin vermek icin EDNS destegi de gereklidir 2 Cozumleyici normal DNS sorgu islemi yoluyla bir yanit aldiginda yanitin dogru oldugundan emin olmak icin kontrol eder Ideal olarak guvenlik tanili cozumleyici DNS kokundeki DS ve DNSKEY kayitlarinin dogrulanmasiyla baslayacaktir Daha sonra com bolgesinde DNSKEY kayitlarini dogrulamak icin kokte bulunan com ust duzey etki alani icin DS kayitlarini kullanir Buradan itibaren com bolgesinde example com alt alani icin bir DS kaydi olup olmadigina bakar ve eger varsa DS kaydi example com bolgesinde bulunan bir DNSKEY kaydini dogrulamak icin kullanir Son olarak www example com icin A kayitlarinin cevabinda bulunan RRSIG kaydini dogrular Yukaridaki ornek icin bazi istisnalar vardir Ilk olarak example com DNSSEC i desteklemiyorsa yanitta RRSIG kaydi olmayacaktir ve com bolgesinde example com icin bir DS kaydi olmayacaktir Example com icin bir DS kaydi varsa ancak yanitta RRSIG kaydi yoksa bir sey yanlistir ve belki ortadaki adam saldirisi vardir ve DNSSEC bilgilerinin soyulmasi A kayitlarinin degistirilmesi gerceklesiyor olabilir Ya da DO isaret biti sorgusundan veya RRSIG kaydinin cevabindan siyrilan yol boyunca kirilmis guvenlikten habersiz bir isim sunucusu olabilir Ya da bir yapilandirma hatasi olabilir Sonra eger www example com adinda bir alan adi bulunmuyor ise bu durumda cevapta bir RRSIG kaydi yerine bir NSEC kaydi veya bir NSEC3 kaydi olacaktir Bunlar cozumleyicinin bir alan adinin mevcut olmadigini kanitlamasina izin veren sonraki guvenli kayitlardir NSEC NSEC3 kayitlarinda yukaridaki gibi dogrulanabilen RRSIG kayitlari bulunur Son olarak ise example com bolgesi DNSSEC i uygulamis olabilir ama com bolgesi veya kok bolgesinin uygulamamis olabilir 15 Temmuz 2010 itibariyla DNSSEC in koke dagitimi tamamlandi com etki alani gecerli guvenlik anahtarlariyla imzalanmis ve 1 Nisan 2011 de kok bolgesine guvenli temsilci eklenmistir Saplama cozumleyiciler Saplama cozumleyicileri DNS cozumleme calismasinin cogunu ozyinelemeli bir ad sunucusuna yuklemek icin yinelemeli sorgu modunu kullanan minimal DNS cozumleyicileridir Bir saplama cozumleyici bir istegi yinelemeli ad sunucusuna iletir ve yanittaki Kimlik Dogrulama Bilgisi AD biti yinelemeli ad sunucusunun yanitin Cevap ve Yetki bolumunun icindeki tum veriler icin imzalari dogrulayip dogrulayamadigini bulmak icin ipucu olarak kullanir Microsoft Windows un kullandigi saplama cozumleyici Windows Server 2008 R2 ve Windows 7 ozellikle dogrulanmamis ancak AD bit uyumlu bir saplama cozumleyicisi kullanmaktadir Dogrulayici saplama cozumleyicisi sorgulama iletilerinde Devre Disi Birakma CD biti ni ayarlayarak kendi imza dogrulamasini da gerceklestirebilir Kendi yinelemeli kimlik dogrulamasini gerceklestirmek icin CD biti kullanir Boyle bir dogrulanmis saplama cozumleyicisi kullanmak Internet hizmet saglayicisi veya onlarla baglanti guvenilir olmasa bile DNSSEC i uygulayan alanlar icin istemciye uctan uca DNS guvenligi saglar Dogrulayici olmayan saplama cozumleyicinin DNSSEC hizmetlerine gercek bir guven yer vermesi icin saplama cozumleyici soz konusu yinelenen ad sunucularina genellikle Internet hizmet saglayicisi tarafindan denetlenen guvenmelidir Kendisi ile bu isim sunuculari arasindaki iletisim kanallari IPsec SIG 0 veya TSIG gibi yontemlerdir IPsec kullanimi genis capli yayilmamistir Guvenli Mekanizma ve Kimlik Dogrulama Zincirleri DNS yanitinin dogru oldugunu kanitlayabilmek icin en az bir anahtar veya DNS disindaki kaynaklardan dogru olan bir DS kaydi bilmesi gerekir Bu baslangic noktalari guven mekanizmalari olarak bilinir ve genellikle isletim sistemi veya baska bir guvenilen kaynak ile elde edilir DNSSEC orijinal olarak tasarlandiginda gereken tek guven mekanizmasinin DNS koku icin oldugu dusunuluyordu Kok mekanizmalar ilk defa 15 Temmuz 2010 da yayinlandi Kimlik dogrulama zinciri sorgudaki alan icin yetkili ad sunucusuna bir guven mekanizmasi ile baslayan bir dizi bagli DS ve DNSKEY kaydidir Tam bir kimlik dogrulama zinciri olmadan bir DNS sorgusunun cevabi guvenli bir sekilde dogrulanamaz Imzalar ve Bolge Imzalama Yeniden gonderme saldirilarini sinirlamak icin onbellege alma amaciyla yalnizca normal DNS TTL degerleri degil bir imzanin gecerliligini sinirlamak icin RRSIG kayitlarindaki ek zaman damgalari da vardir Kayitlarin gonderildigi zamana gore TTL degerlerinden farkli olarak zaman damgalari mutlaktir Bu guvenlikle ilgili tum DNS cozumleyicilerinin birkac dakika icinde esit olarak senkronize olan saatlere sahip olmasi gerektigi anlamina gelir Bu zaman damgalari bir bolgenin duzenli olarak yeniden imzalanmasi ve ikincil sunuculara yeniden dagitilmasi gerektigini ya da dogrulanmis cozumleyiciler tarafindan imzalarin reddedilecegini ima eder Anahtar Yonetimi DNSSEC hem DNSKEY kayitlarinda hem de guven kaynaklarini olusturmak icin diger kaynaklarda saklanan bircok farkli anahtar icerir Yedek anahtarlara izin vermek icin bir anahtar cevrim semasi gereklidir Genellikle bu eski anahtarlara ek olarak yeni DNSKEY kayitlarindaki yeni anahtarlari ilk kez icerir Ardindan yasama degerlerinin eski anahtarlarin saklanilmasina neden oldugunu varsaymak guvenliyse bu yeni anahtarlar kullanilabilir Son olarak zamani gecmis eski anahtarlari kullanan kayitlari saklamayi varsaymak guvenliyse eski DNSKEY kayitlari silinebilir Bu islem kokte oldugu gibi baglayici mekanizmalara anchor guvenme anahtarlarindaki gibi seyler icin daha karmasiktir oyle ki isletim sisteminde bir guncellestirme gerektirebilir DNSKEY kayitlarindaki anahtarlar iki farkli sey icin kullanilabilir ve genellikle her biri icin farkli DNSKEY kayitlari kullanilir Ilk olarak diger DNSKEY kayitlarini imzalamak icin kullanilan anahtar imzalama anahtarlari KSK vardir Ikincisi diger kayitlari imzalamak icin kullanilan bolge imzalama anahtarlari ZSK vardir ZSK ler belirli bir DNS bolgesi tarafindan tam kontrol ve kullanim altinda oldugundan daha kolay ve daha sik degistirilebilirler Sonuc olarak ZSK ler KSK lerden cok daha kisa olabilir ve RRSIG DNSKEY kayitlarinin boyutunu azaltirken ayni koruma duzeyini sunmaya devam eder Yeni bir KSK olusturuldugunda DS kaydi bir ust bolgesine aktarilmali ve orada yayinlanmalidir DS kayitlari kayitlarin boyutunu kucuk tutmak icin tam anahtar yerine KSK nin bir mesaj ozetini kullanir Bu cok buyuk olan com etki alani gibi bolgeler icin yararlidir Ust bolgedeki DS anahtarlarini guncelleme yordami ust bolgedeki DNSKEY kayitlarini gerektiren onceki DNSSEC surumlerinden de daha basittir DANE Calisma Grubu Adlandirilmis varliklarin DNS tabanli kimlik dogrulamasi DANE internet uygulamalarinin DNSSEC tabanli TLS DTLS SMTP ve S MIME ile kriptografik olarak guvenli iletisim kurmasina olanak taniyan protokoller ve teknikler gelistirme amaciyla bir IETF calisma grubudur Yeni protokoller acik anahtar altyapisina dayali geleneksel model icin ek guvenceler ve kisitlamalar getirecektir Ayrica alan sahiplerine ucuncu taraf sertifika yetkililerine atifta bulunmadan kendileri icin sertifikalar vermelerini de saglar Google Chrome 14 te DNSSEC yerlestirilmis sertifika destegi saglandi ancak daha sonra kaldirildi Mozilla Firefox icin destek bir eklenti tarafindan saglanirken yerel destek su anda uzerinde calismaya baslamak icin birilerini bekliyor TarihceDNS temel ve ciddi bir internet hizmetidir ancak 1990 yilinda Steve Bellovin sistemin icinde onemli guvenlik aciklari kesfetti Sistemin guvenlik arastirmasi basladi ve 1995 yilinda yayinladigi makalesinin ardindan onemli olcude ilerleme kat edildi Ilk RFC 2065 1997 yilinda IETF tarafindan yayinlandi ve bu spesifikasyonu uygulamaya yonelik ilk girisimler bir duzenlemeye yol acti ve tamamen calisir olduguna inanilan yeni duzenleme 1999 yilinda RFC 2535 olarak yayinlandi RFC 2535 e dayanan DNSSEC i uygulamak icin planlar yapildi Ne yazik ki IETF RFC 2535 dokumani internetin tamamina kadar olceklenen cok onemli sorunlara sahipti 2001 yilinda bu dokumanin buyuk aglar icin kullanilamaz oldugu netlesti Normal islemlerde DNS sunuculari sik sik sunucu atalariyla senkronizasyonu yitirir Bu durum genellikle sistem icin bir sorun olusturmaz ama DNSSEC etkinlestirildikten sonra bu senkronize olmayan veriler ciddi bir kendi kendine olusturulmus Denial of Service saldirisina neden olabilir Orijinal DNSSEC bir alt seviyedeki DNS sunucusu icin anahtar degisikliklerinde karmasik bir alti mesaj protokolune ve cok sayida veri aktarimina ihtiyac duyuyordu DNS alt seviyedeki sunucularin tum verilerini ust seviyeye yollamasi bu verilerin imzalamasi ve ardindan bu imzalarin sunucuya tekrar yollanmasi gerekiyordu Ayrica acik anahtar degisikliklerinin beklenmedik etkileri olabiliyordu Ornegin com kayitlarinin tutuldugu sunucu acik anahtarini degistirirse bu sunucunun 22 milyon kayit gondermesi gerekirdi tutulan tum kayitlarin imzalarinin guncellenmesi icin Boylece RFC 2535 te tanimlandigi gibi DNSSEC tum internete olceklendirilemedi IETF DNSSEC i RFC 2535 in DNSSEC yaklasimindan farkli kilmak icin temel degisiklikler yaparak DNSSEC bis i olusturdu DNSSEC bis yaklasiminda ebeveyn ve cocuk bolgesi arasindaki temsil noktalarinda ek bir dolaylilik seviyesi saglamak icin yetkili imzali DS kaynak kayitlari kullanir Yeni yaklasimda bir cocugun ana acik anahtari degistiginde cocukta bulunan her bir kayit icin alti mesaj gondermesi yerine sadece bir mesajla yeni acik anahtarini ebeveynine imzali olarak gondermesi yeterlidir Boylece oldukca pratik bir sekilde ebeveynler her cocuk icin bir ana acik anahtar tutar Ayrica ebeveyn ve cocuklar arasinda cok buyuk boyutta veri degisimini en aza indirger Bu kullanicilarin anahtarlari dogrularken biraz daha fazla calisma yapmasi gerektigi anlamina gelir Daha spesifik olarak bir DNS bolgesinin KEY RRset kaynak kayitlari anahtari dogrulanmasi RFC 2535 te belirtilen tek imza dogrulama islemi yerine iki imza dogrulama islemi gerektirir diger RRset turleri icin dogrulama imzalarinin sayisi uzerinde herhangi bir etkisi yoktur Bu durum DNSSEC dagitimini daha pratik hale getirdiginden cogu insan icin daha kucuk bir fiyat olarak gorunur NXDOMAIN yanitlari ve NSEC icin Kimlik DogrulamaKriptografik olarak bir alanin domain yoklugunu kanitlamak var olmayan bir alan icin her sorguya yaniti imzalamayi gerektirir Bu anahtarlari cevrimici olarak saklayan cevrimici imzalama sunuculari icin bir sorun degildir Ancak DNSSEC kayit imzalamak icin cevrimdisi bilgisayarlari kullanacak sekilde tasarlanmistir boylece bolge imzalama anahtarlari soguk depoda tutulabilir Bu durum var olan her ana makine hostname adi sorgusuna bir yanitin onceden uretilmesi mumkun olmadigindan mevcut olmayan alanlara yonelik sorgulara yanitlari dogrulamaya calisirken sorun olusturur Bu probleme ilk cozum bir bolgedeki her alan cifti icin NSEC kaydi olusturmak seklindeydi Boylece bir kullanici var olmayan k example com daki bir kaydi sorguladiginda sunucu a example com ve z example com arasinda hicbir seyin bulunmadigini belirten bir NSEC kaydiyla yanit verir Ancak bu bolge hakkinda daha fazla bilgiyi gercek alanlarinin varligini sizdirdigi icin geleneksel kimligi dogrulanmamis NXDOMAIN hatalarindan daha fazla veri sizdirmaktadir NSEC3 kayitlari RFC 5155 dogrudan isimleri listelemek yerine alternatif olarak isimlerin ozetleriyle hash fonksiyonu listelemek icin olusturulmustur Zaman icinde GPU lar ve ozel donanimlar kullanilarak ozet fonksiyonundaki ilerlemeler NSEC3 yanitlarinin cevrimdisi sozluk saldirilari ile kolaylikla asilabilecegi anlamina geliyordu NSEC5 yetkili sunucularin bolgeyi degistirmek uzere kullanacagi ozel bir anahtar bulundurmadan NSEC yanitlarini imzalamasina izin vermesini onermistir Boylece bir NSEC5KEY in calinmasi sadece bir bolgenin daha kolay sayilmasina neden olacaktir Protokolun daginik evrimi ve geriye donuk uyumlulugu koruma isteginden dolayi cevrimici DNSSEC imzalama sunuculari dogrudan bir varliginin reddini denial of existence dogrulamak yerine bir beyaz yalan donduruyor RFC 4470 deki teknik ana hat etki alani ciftlerinin istenen etki alanini cevreledigi bir NSEC kaydi dondurur Ornegin k example com icin yapilan bir istek j example com ve l example com alan adlarinin arasinda hicbir seyin bulunmadigini kanitlayan bir NSEC kaydi donecektir CloudFlare kayit var ancak istenen kayit turu bulunmuyor mesajiyla onemli olcude azaltilmis veri yuku boyutuna sahip oldugunu kanitlayan baska bir yaklasima onculuk etti DagitimInternet hassas bir altyapiya sahiptir ancak calismasi guvenli olmayan DNS ye baglidir Bu nedenle DNS yi guvence altina almak icin guclu bir tesvik vardir ve DNSSEC i kullanmak bu cabanin temel bir parcasi olarak kabul edilir Ornegin ABD Ulusal Siber Guvenlik Stratejisi ozellikle DNS nin guvenligini saglamanin gerektigine deginmistir DNSSEC in genis capli dagitimi e posta adresleri icin guvenli anahtar dagitimi gibi diger bircok guvenlik problemini de cozebilir Buyuk olcekli aglarda DNSSEC dagitimi da oldukca zorlayicidir Ozment ve Schechter DNSSEC in ve diger teknolojilerin bir bootstrap problemine sahip oldugunu gozlemlemistir Yani kullanicilar genellikle aninda bir fayda elde ettikleri zaman bir teknolojiyi kullanirlar ama herhangi bir kullanici bu teknoloji icin yapacagi harcamadan daha buyuk bir kazanc elde etmeden once minimum duzeyde bir dagitim gerekiyorsa DNSSEC icin oldugu gibi dagitimi zordur DNSSEC bir DNS hiyerarsisinin herhangi bir duzeyinde uygulanabilir ancak digerlerinin benimsemesini istemeden once bir bolgede yaygin olarak bulunmalidir DNS sunuculari DNSSEC i destekleyen bir yazilimla guncellestirilmeli DNSSEC verileri olusturulmali ve DNS bolgesi verilerine eklenmelidir Bir TCP IP kullanan istemcinin DNSSEC in ozelliklerini kullanabilmesi icin DNS cozumleyicisinin istemci guncellestirilmesi gerekir Ek olarak herhangi bir cozumleyici DNSSEC kullanmaya baslamadan once guvenebilecegi en az bir ortak anahtari olmalidir veya anahtar elde etme yoluna sahip olmalidir DNSSEC uygulamasi bazi DNS sunucularina onemli yukler ekleyebilir Ortak DNSSEC imzali yanitlar 512 baytlik varsayilan UDP paketi boyutundan cok daha buyuktur Teoride bu birden fazla IP parcasi kullanilarak cozulebilir ama bu alandaki bircok middlebox bunlari dogru sekilde cozemez Bu UDP yerine TCP kullanilmasina yol acar Yine de bircok TCP uygulamasi her bir TCP baglantisi icin cok buyuk miktarda veri saklar agir yuklu sunucular cok sayida ve muhtemelen sahte DNSSEC isteklerine yanit vermeye calisarak kaynaklarin tukenmesine neden olabilir Bu yuklemeyi azaltmak icin TCP Cerez Islemleri gibi bazi protokol uzantilari gelistirilmistir Bu zorluklari cozmek ve DNSSEC i yaymak icin onemli cabalar devam ediyor cunku internet bircok organizasyon icin hayati onem tasiyor Erken dagitimlar Internet ulke kodu ust duzey alan adi seviyesinde DNSSEC i ilk kullananlar Brezilya br Bulgaristan bg Cekya cz Namibya na Puerto Rico pr ve Isvec se oldu tarafindan yetkilendirilmis RIPE NCC ye tum geriye dogru arama kayitlarini in addr arpa imzalatti American Registry for Internet Numbers ARIN a da ters bolgeleri imzalatti Subat 2007 Isvec te Tele Danmark Communications TDC bu ozelligi musterilerine sunmaya baslayan ilk ISP oldu IANA Haziran 2007 de ornek imzali koku olu kirik baglanti test etti Kokun uretiminin imzalanmasindan once bu sure zarfinda birkac alternatif guven kaynagi da vardi IKS Jena 19 Ocak 2006 da bir tanesini uygulamaya koydu Internet Sistemleri Konsorsiyumu ayni yilin 27 Mart tarihinde bir baskasinin tanitimi yapti ICANN ise 17 Subat 2009 da ucuncusunu duyurdu Cok cesitli pilot projeler ve deneyler yapildi dnssec net bu tur projelerin bir listesini tutar Ayrica Dunya Capinda DNSSEC Dagitiminin bir Google Haritasi var 2 Haziran 2009 tarihinde Public Interest Registry org bolgesini imzaladi PKR 26 Eylul 2008 de ilk olarak buyuk kayit sirketlerinin arkadas ve aile guclu bir calisma iliskisine sahip oldugu ilk asamada erken 2009 dan baslayarak alan adlarini imzalayabilecek ilk kisi olacagini aciklamistir 23 Haziran 2010 da 13 kayit memuru ORG alanlari icin DNSSEC kayitlari sundular VeriSign com ve net alan adlarinin NSEC3 denemesi amaciyla kayit olmasi icin bir pilot proje yurutmustur 24 Subat 2009 da DNSSEC i 24 ay icinde tum ust seviye alanlarina com net tr vb dagitacagini acikladilar ve ayni yilin 16 Kasim inda com ve net alanlari icin uygulanmasinin teknik gecikmelerden sonra 2011 in ilk ceyreginde imzalanacagini belirttiler Bu hedefe tam zamanlanan surede ulasildi ve Verisign in DNSSEC Baskan Yardimcisi Matt Larson DNSSEC i ilerletme roluyle 2011 de InfoWorld un Teknoloji Liderlik Odulu nu kazandi Kok DNS dagitimi DNSSEC ilk defa 15 Temmuz 2010 tarihinde kok duzeyinde dagitildi Kok guven istasyonunun kokten tam bir guven zincirine sahip olan DNSSEC bolgesini dogrulamak icin kullanilabildiginden bunun DNSSEC cozumleyicilerinin dagitimini buyuk olcude basitlestirmesi beklenmektedir Guven zinciri dogrulanmasi icin kesintisiz olarak guvenilen bir koke kadar takip edilmesi gerektiginden ust bolgelerden herhangi biri guvenli degilse guvenin saglanmasi icin yeniden yapilandirilmasi gerekir Ornegin signed example org bolgesi guvenliyse ancak example org bolgesi guvenli degilse org bolgesi ve kok imzalanmis olsa bile bolgeyi dogrulamak icin bir guven mekanizmasinin dagitilmasi gerekir Kokun imzalanmasina dair politik meseleler esas olarak bazi temel meselelerle ilgili surekli bir endise kaynagi olmustur Diger ulkeler ABD nin Internet uzerinden kontrolu konusunda endiseli ve bu sebeple herhangi bir merkezi anahtarlamayi reddedebilir Bazi hukumetler DNSSEC destekli sifreleme anahtari dagitimini engellemeye calisabilir Planlama Eylul 2008 de ICANN ve VeriSign ayri olarak birer uygulama onerisini yayinladi ve Ekim ayinda Ulusal Telekomunikasyon ve Bilgi Idaresi NTIA kamuoyuna yorum istedi Alinan yorumlarin son dagitim planinin tasarimini etkileyip etkilemedigi belirsizdir Ulusal Standartlar ve Teknoloji Enstitusu NIST 3 Haziran 2009 tarihinde ICANN VeriSign ve NTIA ile birlikte 2009 un sonuna kadar kok imzalamayi planladigini duyurdu 6 Ekim 2009 da 59 RIPE Konferans toplantisinda ICANN ve VeriSign DNSSEC in kok bolgesi icinde dagitimi icin planlanan dagitim zaman cizelgesini duyurdu Toplantida 1 Temmuz 2009 tarihinden baslayarak ayda bir kok ad sunucusuna dagitilacagini acikladi 1 Temmuz 2010 da DNSSEC imzali bir bolgeye hizmet veren son kok alan adi sunucusu bir kok bolgesi RSA SHA256 DNSKEY ile imzalanacaktir Artirimli dagitim suresi boyunca kok bolge Deliberately Unvalidatable Root Zone DURZ hizmet edecektir ve 1 Temmuz 2010 da kadar dagitilacak olan son DNSKEY kaydina kadar dagitilmayacaktir Bu bolge kullanimini imzalamak icin kullanilan anahtarlarin kasten dogrulanamayacagi anlamina gelir bu dagitimin nedeni DNSSEC kaynak kayitlarini isteyen sorgulara yapilan daha buyuk yanitlarin neden oldugu trafik modellerindeki degisiklikleri izlemek oldu org ust duzey alan adi Haziran 2010 da DNSSEC ile imzalandi bunu 2010 2011 ve sonrasinda com net ve edu takip etti Ulke kodu ust duzey alan adlari Mayis 2010 dan itibaren anahtarlari depolayabildi Kasim 2011 itibariyla ust duzey alanlarin 25 inden fazlasi DNSSEC ile imzalanmistir Uygulama 25 Ocak 2010 da L ell kok sunucusu DURZ hizmetini vermeye basladi Bolge RFC 5702 de tanimlandigi gibi RSA algoritmasi kullanilarak olusturulan bir SHA 2 SHA 256 karma imzasini kullanir Mayis 2010 itibariyla 13 kok sunucunun hepsi DURZ hizmeti vermeye basladi 15 Temmuz 2010 da ilk tam kok uretimli DNSSEC kok bolgesi SOA 2010071501 seri numarasiyla imzalandi Kok guvenleri IANA dan temin edilebilir TLD duzeyinde dagitim Kokun altinda tam DNSSEC dagitiminin gerceklestirilmesi icin imzalanmasi gereken buyuk bir ust duzey alan adi top level domain kumesi bulunur Internet ust duzey alan adlarinin listesi mevcut ust duzey alan adlarindan hangilerinin imzalandigina ve koke bagli olduguna iliskin ayrintilar saglar DNSSEC Denetleme Dogrulamasi 2006 Mart ayinda Internet Systems Consortium ISC DNSSEC Denetleme Dogrulamasi DNSSEC Lookaside Validation DLV kayit defterini tanitti DLV nin amaci bir kok guven istasyonu olmadiginda DNSSEC in dagitimini kolaylastirmakti Bu durumda bir dogrulayicinin DNS nin imzali altkumelerine karsilik gelen cok sayida guven bagi olusturmak zorunda kalacagi dusunuldu DLV nin amaci dogrulayicilarin guvenilir bir ucuncu tarafa bir guven istasyonunu yonetmeye gerek kalmamasini saglamakti DLV kayit defteri kendi listelerini surdurme calismalarini yineleyen her bir dogrulayici yerine guven istasyonlarinin merkezi bir listesini tutmaktadir DLV kullanmak icin bir DLV bolgesi icin bir guven capasi ile yapilandirilmis Bind veya Unbound gibi bir destekleyici gereklidir Bu bolge DLV kayitlarini icerir bu kayitlar DS kayitlariyla tam olarak ayni bicime sahiptir ancak bir temsilci alt bolgeye basvurmak yerine DNS agacinda baska bir bolgeye basvururlar Dogrulayici kokten RRset e bir guven zinciri bulamadiginda tekrar kontrol etmeye calisir alternatif bir guven zinciri saglayabilen bir DLV kaydini arar DNSSEC yetkilerini desteklemeyen ust duzey alan adlari veya kayit sirketleri gibi guven zincirindeki bosluklar alt duzey etki alanlarindaki yoneticilerin DLV yi DNS verilerinin DLV yi kullanmak uzere yapilandirilan cozuculer tarafindan dogrulanmasini saglamak icin kullanabilir Bu DNSSEC dagitimini dogru bir sekilde desteklemek icin kayit memurlari ve TLD kayitlarindan baski alarak DNSSEC dagitimini engelleyebilirdi DLV ayrica DNSSEC dogrulamasi icin daha fazla katilimci ve kod yolu ekleyerek karmasikligi artirir Bu durum daha fazla belirsizligi ortaya cikarmaktadir cunku dogrulayici cozumleyicilerin tumu DLV yi ya desteklememekte ya da kullanmamaktadir Bir cozumleyiciyi sorgulayan istemciler farkli bir dogrulayici cozumleyici kullanan istemciler tarafindan desteklenmezken DLV dogrulanmis yanitlari alabilir DLV yaygin olarak kullanilamamistir Mayis 2015 e kadar ISC nin DLV kaydi toplam 5 000 alan adinin altinda ve bunlarin 10 dan daha azinda imzasiz bir ana alan adi vardi ISC DLV kaydini iptal etme planini acikladi DLV desteginin BIND den ve dogrulama cozumleyicilerinin diger uygulamalarindan kaldirilacagi henuz belli degildir ABD Federal Hukumeti tarafindan DNSSEC dagitim girisimi ABD Ic Guvenlik Bakanligi DHS Bilim ve Teknoloji Mudurlugu DNSSEC Dagitim Girisimi ni destekliyor Bu girisim tum sektorleri internet ve adlandirma altyapisinin guvenligini artiracak guvenlik tedbirlerini gonullu olarak benimsemeye tesvik ediyor ayrica kamu ve ozel sektordeki bircok ulke ve orgutu iceren kuresel isbirlikci cabalarin bir parcasi DHS ayrica DNSSEC i gelistirmek ve ABD federal hukumetine dagitilmak icin caba sarf ediyor 30 Mart 2007 de ABD Disisleri Bakanligi Guvenlik Dairesi Baskanligi nin DNS kokenini ABD hukumetinin elinde saglam bir sekilde imzalamanin anahtari olmasi onerildi Ancak toplanti odasinda ABD Hukumeti yetkililerinden kimse yoktu ve makaleyi baslatan yorum baska bir taraftan yapilmisti DHS daha sonra baskalarinin ABD Hukumeti nin boyle bir oneride bulunmus oldugu gibi yanlis bir sonuca vardigina inandiklarini soyle acikladi ABD Ic Guvenlik Bakanligi DNSSEC i uygulamak icin teknik bir planin gelistirilmesini finanse ediyor ve son olarak Ekim ayinda ilk taslagini yorumlar icin uluslararasi uzmanlarin uzun bir listesine dagitti Taslak temel olarak bir devlet kurumuna veya yukleniciye kaynayan Kok Bolge Anahtarinin sahibi veya operatoru olabilmeleri icin bir dizi secenek ortaya koymaktadir Bu belgede hicbir yerde Kok Anahtar Operatorunun kimligi ile ilgili herhangi bir oneride bulunmuyoruz seklinde Homeland Security nin Siber Guvenlik Arastirma ve Gelistirme Muduru Maughan aciklama yapti ABD Federal Hukumeti nde DNSSEC dagitimi Ulusal Standartlar ve Teknoloji Enstitusu NIST 16 Mayis 2006 tarihinde NSS Ozel Yayini 800 81 Guvenli Alan Adi Sistemi DNS Dagitim Kilavuzu nu yayinladi ve DNSSEC in nasil dagitilacagi konusunda rehberlik etti NIST NIST SP800 53 R1 deki yeni DNSSEC Federal Bilgi Guvenligi Yonetimi Yasasi FISMA gerekliliklerini yayinlamayi planladi ve bu dagitim kilavuzuna basvurdu ABD ajanslari NIST SP800 53 R1 in bu yeni FISMA gerekliliklerini yerine getirmeleri icin bir yil sonra yayinlanacakti Ancak NSEC3 zamaninda tamamlanamadi NIST mumkun oldugu bilinen ancak dogru bir sekilde dagitilmasi zor olan ve yukarida belirtilen guvenlik zaaflarina sahip olan bolunmus alan adlarini kullanmayi onerdi 22 Agustos 2008 de Yonetim ve Butce Burosu OMB ABD Federal Ajanslarinin DNSSEC yi gov siteleri arasinda dagitmasini gerektiren bir bildiri yayinladi gov koku Ocak 2009 a kadar imzalanmis olmali ve gov altindaki tum alt alanlarin Aralik 2009 a kadar imzalanmasi gerekir Bildiri gov sitelerine odaklanirken ABD Savunma Bilgi Sistemleri Dairesi ayni zamanda mil ABD askeri alaninda da OMB DNSSEC gereksinimlerini karsilamayi planladigini acikladi NetworkWorld den Carolyn Duffy Marsan DNSSEC in yaygin bir sekilde dagitilmadigini cunku klasik bir tavuk ve yumurta ikileminden aci cektigini ve OMB nin gorevinin yumurtanin catlamasina neden olmak oldugunu soyledi Cozumleyicilerin dagitimi Birkac ISP DNSSEC dogrulayan DNS ozyineli cozumleyicilerini dagitmaya basladi Comcast Amerika Birlesik Devletleri nde 18 Ekim 2010 da yapacagini acikladi ve 11 Ocak 2012 de dagitimini tamamlayan ilk buyuk ISP oldu APNIC de yapilan bir arastirmaya gore DNSSEC dogrulama islemini gerceklestiren DNS cozumleyicilerini kullanan istemcilerin orani Mayis 2013 te 8 3 e yukseldi yarim musterilerin edildi kullanarak Google genel DNS cozumleyici Eylul 2015 te Verisign halka acik ucretsiz DNS cozumleme hizmetini duyurdu ve basinda belirtilmemis olmasina ragmen DNSSEC dogrulamasi hizmetini de gerceklestiriyor 2016 yilinin basinda APNIC in arastirmasina gore DNSSEC dogrulama islemini gerceklestiren DNS cozumleyicilerini kullanan musterilerin oraninin yaklasik 15 e cikmis oldugunu gosterdi Google Genel DNS Google Genel DNS DNSSEC i tamamen destekleyen ucretsiz olarak saglanan bir genel DNS hizmetidir 2009 daki lansmaninda Google Genel DNS DNSSEC i desteklemiyordu RRSIG kayitlari sorgulanabiliyor ancak AD bayragi sunucunun tum veriler icin imzalari dogrulayabilmesi anlamina gelen kimligi dogrulanmis veri asla ayarlanamiyordu 28 Ocak 2013 te Google in DNS sunuculari DNSSEC dogrulama bilgileri saglamaya sessizce basladi ancak yalnizca istemcinin kendi sorgusunda DNSSEC OK DO isaretini acikca belirlemesi durumunda calisiyordu 6 Mayis 2013 te Google Genel DNS DNSSEC dogrulamasini varsayilan olarak etkinlestirdi istemciler acikca belirtmedigi surece tum sorgularin dogrulanacagi anlamina gelir Sorunlar Microsoft Exchange 2013 te MX kayit aramasini kirdigi ve daha buyuk olan 550 4 4 7QUEUE nun neden oldugu bilinmektedir IETF standartlariRFC 2535 Domain Name System Security Extensions RFC 3833 A Threat Analysis of the Domain Name System RFC 4033 DNS Security Introduction and Requirements DNSSEC bis RFC 4034 Resource Records for the DNS Security Extensions DNSSEC bis RFC 4035 Protocol Modifications for the DNS Security Extensions DNSSEC bis RFC 4398 Storing Certificates in the Domain Name System DNS RFC 4470 Minimally Covering NSEC Records and DNSSEC On line Signing RFC 4509 Use of SHA 256 in DNSSEC Delegation Signer DS Resource Records RRs RFC 5155 DNSSEC Hashed Authenticated Denial of Existence RFC 6781 DNSSEC Operational Practices Version 2 RFC 6840 Clarifications and Implementation Notes for DNS Security DNSSEC AraclarDNSSEC dagitimi sunucu ve istemci tarafinda yazilim olmasini gerektirir DNSSEC yi destekleyen araclardan bazilari sunlardir Windows 7 ve Windows Server 2008 R2 yinelemeli ad sunucusu tarafindan guvenli ve guvenli olmayan yanitlar arasinda ayrim yapabilen bir guvenlik farkindalik saptama cozumleyicisi icerir Windows Server 2012 DNSSEC Active Directory ile tumlesik bolgelerle guvenli dinamik guncellestirmeler ve buna ek olarak guven anahtarlarinin diger sunuculara Active Directory dagitmasiyla uyumludur BIND en populer DNS isim sunucusudur yeni DNSSEC bis DS kayitlari protokolunu ve NSEC3 kayitlarinin destegini icerir Drill 10 Ekim 2017 tarihinde Wayback Machine sitesinde ldns 7 Mart 2018 tarihinde Wayback Machine sitesinde ile birlikte bir DNSSEC etkin dig benzeri bir aractir Mozilla Firefox a bir alanin DNSSEC ile dogrulanip dogrulanamadigini belirleme yetenegini verir DNSSEC Tools her tur yonetici ve kullanicinin DNSSEC den yararlanmalarina yardimci olmak icin kullanimi kolay araclar saglamayi amaclamaktadir ve yoneticileri icin olan araclarin yani sira icin bir kitaplik ve araclar ve 18 Eylul 2009 tarihinde Wayback Machine sitesinde genisletmek icin mevcut yamalar icin araclar sunar Phreebird 17 Aralik 2010 tarihinde Wayback Machine sitesinde herhangi bir DNS sunucusunun uzerine DNSSEC destegi ekleyebilen bir DNS proxydir Zone Key Tool 25 Mart 2018 tarihinde Wayback Machine sitesinde DNSSEC kullanilan bolgelerinin bakimini kolaylastirmak icin tasarlanmis bir yazilimdir Oncelikle kucuk ila orta olcekli bolgelere sahip ortamlar icin tasarlanmistir ve bolgenin otomatik olarak istifade edilmesinin yani sira tam otomatik bolge imzalama anahtarinin aktarilmasini saglar Unbound 5 Nisan 2018 tarihinde Wayback Machine sitesinde DNSSEC kavramlari etrafinda tasarlanacak sekilde sifirdan yazilmis bir DNS ad sunucusudur Microsoft Windows icin kompakt kurulumu kolay bir DNSSEC isim sunucusudur mysqlBind DNS ASP leri icin GPL DNS yonetim yazilimi artik DNSSEC i destekliyor OpenDNSSEC Donanim Guvenlik Modulleri ile arabirim kurmak icin PKCS 11 kullanan bir DNSSEC imzalayici aracidir DNSSEC dagitimini ve bolgeleri izler ayrica izlenen genel anahtarlarin bir listesini sunar DNSViz 30 Mart 2018 tarihinde Wayback Machine sitesinde ve DNSSEC Analyzer 17 Eylul 2020 tarihinde Wayback Machine sitesinde bir alanin DNSSEC kimlik dogrulama zincirini gorsellestirmek icin Web tabanli araclardir DNSSEC TLSA Validator 2 Haziran 2018 tarihinde Wayback Machine sitesinde ziyaret edilen alan adinin DNSSEC durumunun gorsellestirilmesi icin bir Mozilla Firefox eklentisidir DNSSEC TLSA Validator 2 1 TLSA kayitlarinin DANE durumunu kontrol etmek ve gorsellestirmek icin destek eklenmistir DNSSHIM 14 Subat 2014 tarihinde Wayback Machine sitesinde veya DNS Secure Hidden Master DNSSEC destekli bolgeler icin saglama surecini otomatiklestirmek icin acik kaynakli bir aractir Net DNS SEC 6 Nisan 2018 tarihinde Wayback Machine sitesinde Perl dili kullanilarak yazilmis bir DNS cozumleyicisidir Knot DNS 1 4 0 surumunde otomatik olarak DNSSEC imzalama destegini ekledi PowerDNS onceden imzalanmis ve canli imzali modlarda surum 3 0 dan itibaren DNSSEC i tam olarak destekler Net DNS2 7 Nisan 2018 tarihinde Wayback Machine sitesinde PHP dili kullanilarak yazilmis bir DNS cozumleyicisidir DNSd Google DNS uzerinden HTTPS 20 Mart 2018 tarihinde Wayback Machine sitesinde saglayan C dili kullanilarak yazilmis bir DNS cozumleyicisidir Ayrica bakinizKaynakca Microsoft 26 Agustos 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 7 Ekim 2009 The Windows DNS client is a stub resolver a b c Microsoft 26 Agustos 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 21 Ekim 2009 The DNS client in Windows Server 2008 R2 and Windows 7 is a non validating security aware stub resolver a b c d Munoz Merino Pedro J Garcia Martinez Alberto Organero Mario Munoz Kloos Carlos Delgado 2006 Meersman Robert Tari Zahir Herrero Herrero Martin Ed Enabling Practical IPsec Authentication for the Internet PDF On the Move to Meaningful Internet Systems 2006 OTM 2006 Workshops Microsoft Springer 1 26 Nisan 2012 tarihinde PDF arsivlendi erisim tarihi 21 Ekim 2009 KB1 bakim Editorler parametresini kullanan link a b c d RFC 4033 DNS Security Introduction and Requirements The Internet Society March 2005 12 IANA 12 Temmuz 2010 19 Eylul 2018 tarihinde kaynagindan arsivlendi erisim tarihi 17 Temmuz 2010 Conrad D Internet Engineering Task Force 4 Nisan 2016 tarihinde kaynagindan arsivlendi erisim tarihi 27 Nisan 2017 10 Eylul 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Arsivlenmis kopya 7 Nisan 2018 tarihinde kaynagindan Erisim tarihi 6 Nisan 2018 RFC 4033 DNS Security Introduction and Requirements The Internet Society March 2005 11 RFC 1123 Requirements for Internet Hosts Application and Support IETF Internet Engineering Task Force 74 10 Agustos 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 9 Eylul 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 2 Subat 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 7 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 26 Kasim 2011 17 Aralik 2013 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Mart 2013 2 Haziran 2018 tarihinde kaynagindan arsivlendi 6 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Steve Bellovin 1995 26 Subat 2008 tarihinde kaynagindan arsivlendi 6 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 6 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 PDF Subat 2003 s 30 22 Mayis 2018 tarihinde kaynagindan PDF arsivlendi Metzger Perry William Allen Simpson Paul Vixie Improving TCP security with robust cookies PDF Usenix 7 Nisan 2018 tarihinde kaynagindan PDF Erisim tarihi 17 Aralik 2009 19 Agustos 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Electronic Privacy Information Center EPIC 27 Mayis 2008 28 Mayis 2018 tarihinde kaynagindan arsivlendi 22 Ekim 2007 tarihinde kaynagindan arsivlendi 6 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Eklund Lowinder Anne Marie 12 Subat 2012 dns wg Swedish ISP TCD Song Adopts DNSSEC dns wg mailing list RIPE NCC 6 Nisan 2018 tarihinde kaynagindan Erisim tarihi 2 Aralik 2012 5 Mart 2007 tarihinde kaynagindan arsivlendi 18 Kasim 2008 tarihinde kaynagindan arsivlendi 12 Eylul 2009 tarihinde kaynagindan arsivlendi 29 Haziran 2011 tarihinde kaynagindan arsivlendi 10 Nisan 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 5 Ekim 2020 Sean Michael Kerner www internetnews com 7 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 27 Agustos 2009 12 Haziran 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 23 Haziran 2010 3 Mart 2009 tarihinde kaynagindan arsivlendi 19 Kasim 2009 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 com Domain Finally Safe 23 Ocak 2013 tarihinde kaynagindan arsivlendi Erisim tarihi 23 Ocak 2013 7 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 The InfoWorld 2011 Technology Leadership Awards 19 Temmuz 2014 tarihinde kaynagindan Erisim tarihi 6 Nisan 2018 16 Temmuz 2010 8 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Singel Ryan 8 Ekim 2006 Wired News CondeNet 9 Ekim 2008 tarihinde kaynagindan arsivlendi Erisim tarihi 9 Ekim 2008 Press Release NTIA Seeks Public Comments for the Deployment of Security Technology Within the Internet Domain Name System Basin aciklamasi National Telecommunications and Information Administration U S Department of Commerce 9 Ekim 2008 13 Ekim 2008 tarihinde kaynagindan Erisim tarihi 9 Ekim 2008 Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet s Domain Name and Addressing System Basin aciklamasi National Institute of Standards and Technology 3 Haziran 2009 29 Haziran 2011 tarihinde kaynagindan Erisim tarihi 6 Nisan 2018 DNSSEC for the Root Zone PDF Hutchinson James 6 Mayis 2010 ICANN Verisign place last puzzle pieces in DNSSEC saga NetworkWorld 20 Aralik 2013 tarihinde kaynagindan Erisim tarihi 6 Nisan 2018 15 Mart 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 24 Mart 2010 The Inquirer Verisign deploys DNSSEC on com TLD 23 Aralik 2019 tarihinde kaynagindan Erisim tarihi 6 Nisan 2018 Heise Online 24 Mart 2010 19 Ocak 2019 tarihinde kaynagindan arsivlendi 6 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 PDF 4 Mart 2016 tarihinde kaynagindan PDF arsivlendi Erisim tarihi 6 Nisan 2018 RFC 5702 2 1 RSA public keys for use with RSA SHA 256 are stored in DNSKEY resource records RRs with the algorithm number 8 RFC 5702 3 1 RSA SHA 256 signatures are stored in the DNS using RRSIG resource records RRs with algorithm number 8 14 Haziran 2011 tarihinde kaynagindan arsivlendi RFC 5011 Automated Updates of DNS Security DNSSEC Trust Anchors RFC 4431 The DNSSEC Lookaside Validation DLV DNS Resource Record RFC 5074 DNSSEC Lookaside Validation DLV PDF 25 Agustos 2016 tarihinde kaynagindan PDF arsivlendi Erisim tarihi 6 Nisan 2018 Heise News 30 Mart 2007 6 Nisan 2007 tarihinde kaynagindan arsivlendi UPI 21 Nisan 2007 12 Subat 2009 tarihinde kaynagindan arsivlendi 7 Nisan 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 24 Mart 2011 First link is dead this is believed to be the same content Haziran 2006 22 Kasim 2007 tarihinde kaynagindan arsivlendi PDF Executive Office Of The President Office Of Management And Budget 22 Agustos 2008 16 Eylul 2008 tarihinde kaynagindan PDF arsivlendi Network World 22 Eylul 2008 25 Eylul 2008 tarihinde kaynagindan arsivlendi 22 Ekim 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 18 Ekim 2010 21 Ekim 2010 tarihinde kaynagindan arsivlendi Erisim tarihi 18 Ekim 2010 13 Subat 2012 tarihinde kaynagindan arsivlendi Erisim tarihi 11 Ocak 2012 1 Temmuz 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 20 Kasim 2017 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 24 Mart 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 11 Kasim 2018 tarihinde kaynagindan arsivlendi Erisim tarihi 29 Ocak 2013 nanog mailing list archives Google Code Blog 10 Subat 2016 tarihinde kaynagindan arsivlendi Erisim tarihi 1 Haziran 2013 24 Ekim 2014 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 Seshadri Shyam 11 Kasim 2008 Port 53 Microsoft 7 Kasim 2009 tarihinde kaynagindan arsivlendi Erisim tarihi 6 Nisan 2018 PDF 29 Temmuz 2016 tarihinde kaynagindan PDF arsivlendi Erisim tarihi 6 Nisan 2018 Dis baglantilarDNSSEC 23 Aralik 2017 tarihinde Wayback Machine sitesinde DNSSEC bilgi sitesi DNSSEC net DNS Uzantilari IETF Calisma Grubu DNSSEC Proje Araclari 11 Eylul 2009 tarihinde Wayback Machine sitesinde DNSSEC Dagitim Koordinasyon Girisimi 4 Nisan 2018 tarihinde Wayback Machine sitesinde DNSSEC Dagitim Ekibi 10 Eylul 2017 tarihinde Wayback Machine sitesinde ICANN DNS Operasyon Ekibi 18 Temmuz 2014 tarihinde Wayback Machine sitesinde DNSSEC is unnecessary Against DNSSEC 2 Subat 2018 tarihinde Wayback Machine sitesinde DNSSEC is necessary For DNSSEC 11 Ocak 2017 tarihinde Wayback Machine sitesinde

    Yayın tarihi: Temmuz 09, 2024, 04:24 am
    En çok okunan
    • Kasım 23, 2024

      Irakoniscus

    • Kasım 24, 2024

      Iddrisu Baba

    • Kasım 25, 2024

      Ion Barbu

    • Kasım 22, 2024

      Indoclystus

    • Kasım 25, 2024

      Incertae familiae

    Günlük

    • Türk edebiyatında hikâye

    • Ahmet Hamdi Tanpınar

    • Binbir Gece Masalları

    • Balkan Savaşları

    • Midilli (kruvazör)

    • Concorde

    • Ernest Belfort Bax

    • Haluk Levent

    • 26 Kasım

    • Nicéphore Niepce

    NiNa.Az - Stüdyo

    • Vikipedi

    Bültene üye ol

    Mail listemize abone olarak bizden her zaman en son haberleri alacaksınız.
    Temasta ol
    Bize Ulaşın
    DMCA Sitemap Feeds
    © 2019 nina.az - Her hakkı saklıdır.
    Telif hakkı: Dadaş Mammedov
    Üst