. 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, codice_1 için yapılan bir istek, codice_5 ve codice_6 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.

İ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.

İnternet ülke kodu üst düzey alan adı seviyesinde DNSSEC'i ilk kullananlar Brezilya (.br), Bulgaristan (.bg), Çek Cumhuriyeti (.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ü 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 ise17 Ş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ı 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ı.

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:


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 .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.

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.

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.

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