stanford-oval/wikipedia huggingface dataset:
DNSSEC
İşlemler > 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.
İşlemler > 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'teki 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.
Dağıtım > 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; Internet Assigned Numbers Authority (IANA) 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ü[ölü/kırık bağlantı] 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ı.
Dağıtım > 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.
Dağıtım > Kök DNS dağıtımı > 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.
Dağıtım > Kök DNS dağıtımı > 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.
Dağıtım > 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.
Dağıtım > 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.
Dağıtım > 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ı.
Dağıtım > 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.
Dağıtım > Çö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.
Dağıtım > Çözümleyicilerin dağıtımı > 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.
Dağıtım > Çözümleyicilerin dağıtımı > 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)