DNSSEC का व्यावहारिक अनुप्रयोग

आलेख में मौजूदा DNS संरचना की कमियों का वर्णन है, एक उदाहरण के रूप में .com और .org डोमेन का उपयोग करके DNSSEC को लागू करने की पूरी प्रक्रिया, DNSSEC के साथ हस्ताक्षरित एक वैध स्व-हस्ताक्षरित SSL प्रमाणपत्र बनाने की प्रक्रिया।

डीएनएस क्या बुरा है

अपने वर्तमान स्वरूप में DNS सिस्टम 20 साल से अधिक पहले विकसित किया गया था जब सूचना सुरक्षा के बारे में विशेष रूप से नहीं सोचा गया था। इसकी कई बुनियादी कमजोरियां हैं।

DNS सर्वर की प्रतिक्रिया की विश्वसनीयता की किसी भी तरह से जाँच नहीं की जाती है। यह आपको उस उपयोगकर्ता को भेजने की अनुमति देता है जिसने डोमेन नाम को एक मनमाने ढंग से आईपी पते पर भेजा है, जो सर्वर की प्रतिक्रिया को प्रतिस्थापित करता है। व्यवहार में, इस तरह के हमले इस तरह दिख सकते हैं।

ग्राहकों के लिए रिज़ॉल्वर के रूप में काम करने वाले प्रदाताओं के कैशिंग डीएनएस सर्वर भी कमजोर होते हैं: कामिंस्की हमला ।

आज, ऐसी तकनीकें हैं जो DNS रिकॉर्ड्स में सार्वजनिक कुंजी संग्रहीत करने के लिए प्रदान करती हैं, उदाहरण के लिए, ईमेल में DKIM हस्ताक्षर , SSHFP रिकॉर्ड्स में SSH कुंजी आदि। इन सभी तकनीकों को DNS जालसाज़ी से सुरक्षा की आवश्यकता होती है।

DNSSEC सिद्धांत

DNSSEC एक ऐसी तकनीक है जो आपको क्रिप्टोग्राफिक हस्ताक्षर का उपयोग करके DNS जानकारी की प्रामाणिकता को विशिष्ट रूप से सत्यापित करने की अनुमति देती है।

DNSSEC के बारे में लोकप्रिय रूप से यहां पढ़ा जा सकता है: dxdt.ru/2009/03/04/2163

यहाँ अधिक जानकारी: habrahabr.ru/blogs/sysadm/120620

और Verisign.com पर

जारी रखने से पहले, यह दृढ़ता से अनुशंसा की जाती है कि आप उपरोक्त लिंक को ध्यान से पढ़ें, क्योंकि पहली नज़र में ज़ोन पर हस्ताक्षर करने की प्रक्रिया बल्कि भ्रामक लगती है।


जितना संभव हो उतना सरल है, यह कुछ इस तरह दिखता है: एक रूट ज़ोन है "।", जिसमें सभी प्रथम-स्तरीय डोमेन के बारे में जानकारी है। अपेक्षाकृत बोलना, यह एक पाठ फ़ाइल है जिसमें कुछ लाइनों के सेट होते हैं, जो बहुत बार नहीं बदलते हैं। एक सार्वजनिक / निजी कुंजी जोड़ी बनाई जाती है और इस फ़ाइल में प्रत्येक पंक्ति पर हस्ताक्षर किए जाते हैं (PGP / GPG में "स्पष्ट संकेत" प्रकार से, जिसका उपयोग ईमेल में खुले तौर पर पाठ पर हस्ताक्षर करने और "BEGIN PGP हस्ताक्षर" से शुरू होता है)।
अब जब आपके पास इस जोड़ी के लिए सार्वजनिक कुंजी है, तो आप इस सूची में प्रत्येक प्रविष्टि की प्रामाणिकता को सत्यापित कर सकते हैं। उदाहरण के लिए, जाँचें कि ripn.net सर्वर वास्तव में "आरयू" के लिए जिम्मेदार हैं। जोन:

डिग -t किसी भी + dnssec @ k.root-servers.net एन।

प्रतिक्रिया में, आप हैश हस्ताक्षर वाले आरआरएसआईजी रिकॉर्ड देख सकते हैं।

लेकिन यह पर्याप्त नहीं है, चूंकि डाउनस्ट्रीम सर्वर रिज़ॉल्यूशन में भाग लेते हैं, जिसके उत्तर को भी सत्यापित करने की आवश्यकता है। फिर शीर्ष-स्तरीय डोमेन के मालिक, उदाहरण के लिए, "कॉम"। एक ही कुंजी जोड़ी बनाएं और अपने ज़ोन के सभी रिकॉर्ड्स पर हस्ताक्षर करें, और फिर रूट ज़ोन में अपनी सार्वजनिक कुंजी की एक डाली जोड़ें। नतीजतन, रूट ज़ोन की सार्वजनिक कुंजी पर भरोसा करते हुए, आप ज़ोन कुंजी "कॉम" की प्रामाणिकता को सत्यापित कर सकते हैं। और, तदनुसार, इस पर भरोसा करें:

डिग-टी किसी भी + dnssec @ k.root-servers.net कॉम।

प्रतिक्रिया में, डीएस रिकॉर्ड में उस कुंजी की एक कास्ट होती है जिसके साथ ज़ोन "कॉम" पर हस्ताक्षर किया जाता है

यह समझना महत्वपूर्ण है कि ज़ोन में प्रत्येक परिवर्तन के बाद, हस्ताक्षर करना नए सिरे से किया जाता है। लेकिन, चूंकि रूट ज़ोन केवल "कॉम" क्षेत्र की सार्वजनिक कुंजी पर हस्ताक्षर करता है, इसलिए रूट "कॉम" में हर परिवर्तन के साथ रूट ज़ोन में प्रविष्टियों को फिर से कैश करने की आवश्यकता नहीं है।

अब आप com के लिए जिम्मेदार सर्वर से प्रतिक्रियाओं को प्रमाणित कर सकते हैं।

dig + dnssec -t any @ a.gtld-servers.net verisign.com

यह देखा जा सकता है कि डोमेन रिकॉर्ड verisign.com है। हस्ताक्षरित है, लेकिन इस स्तर पर यह केवल संभव है कि verisign.com डोमेन के लिए जिम्मेदार NS सर्वर के पतों की प्रामाणिकता स्थापित की जाए। आईपी ​​पते को हल करने के लिए, आपको उनसे प्रतिक्रिया प्राप्त करने की आवश्यकता है, इसलिए इन एनएस सर्वर के मालिकों की अपनी महत्वपूर्ण जोड़ी है, जिसके साथ वे ज़ोन पर हस्ताक्षर करते हैं और सार्वजनिक कुंजी स्नैपशॉट को डीएस रिकॉर्ड में डालते हैं।

Verisign.com के लिए ए-रिकॉर्ड का अनुरोध करें।:

dig + dnssec -ta verisign.com @ a2.nstld.com

परिणामस्वरूप, इस तथ्य को सत्यापित करने के लिए कि ए-रिकॉर्ड verisign.com में मूल्य 192.5.6.31 है, विश्वास की निम्नलिखित श्रृंखला निर्मित है:
हम रूट ज़ोन की सार्वजनिक कुंजी को पहले से जानते हैं "।" और हम उस पर भरोसा करते हैं। रूट ज़ोन में एक DS रिकॉर्ड होता है जो बताता है कि "com" में सभी प्रविष्टियाँ ज़ोन में निर्दिष्ट की के साथ साइन की गई हैं और रिकॉर्ड क्रमशः, रूट ज़ोन कुंजी के साथ साइन किया गया है। इस प्रविष्टि की प्रामाणिकता की पुष्टि करने के बाद, हम इस कुंजी द्वारा हस्ताक्षरित "कॉम" जोन में सभी प्रविष्टियों पर भरोसा करते हैं। कॉम के लिए ज़िम्मेदार सर्वर। ज़ोन में सार्वजनिक कुंजी verisign.com के साथ DS-record होता है, जो कॉम की कुंजी द्वारा हस्ताक्षरित होता है। ज़ोन, जो आपको verisign.com के लिए जिम्मेदार NS सर्वर की प्रतिक्रिया में हस्ताक्षर की प्रामाणिकता सत्यापित करने की अनुमति देता है।

योजनाबद्ध रूप से, यह इस तरह दिखता है:

उपरोक्त विवरण काफी आदिम और हास्यास्पद है। यह "उंगलियों पर" काम करने के सिद्धांत को समझाने के उद्देश्य से लिखा गया है। शायद, यह समझ को सरल नहीं करेगा, लेकिन केवल इसे और भी अधिक भ्रमित करेगा।

DNSSEC कार्यान्वयन अभ्यास

चेतावनी! यह निर्देश पुराना है। NSEC3 का उपयोग किए बिना ज़ोन पर हस्ताक्षर करना आपको ज़ोन के सभी DNS रिकॉर्ड्स को खोजने की अनुमति देता है।
वास्तविक निर्देश www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2

वर्तमान में, केवल कुछ शीर्ष-स्तरीय डोमेन ज़ोन हस्ताक्षरित हैं, विशेष रूप से: .net, .com, .org।
Ph ज़ोन पर अभी तक हस्ताक्षर नहीं किए गए हैं, .ua ज़ोन का परीक्षण मोड में हस्ताक्षर किया गया है, .su ज़ोन को आधिकारिक रूप से हस्ताक्षरित किया गया है, लेकिन अभी तक कोई भी रजिस्ट्रार डीएस रिकॉर्ड के अतिरिक्त का समर्थन नहीं करता है।
आईसीएएनएन वेबसाइट पर पूरी सूची देखें।

अपने क्षेत्र पर हस्ताक्षर करने के लिए, यह सुविधा डोमेन पंजीयक द्वारा समर्थित होनी चाहिए। फिलहाल, मैं DNSSEC का समर्थन करने वाले घरेलू रजिस्टरों से अवगत नहीं हूं। R01 रजिस्ट्रार और dnssec.ru वेबसाइट जो DNSSEC समर्थन के साथ Ph डोमेन के प्रतिनिधिमंडल को बढ़ावा देती है, क्योंकि Ph ज़ोन पर हस्ताक्षर नहीं किए गए हैं और इस मामले में, R01 सर्वर एक विश्वास श्रृंखला बनाने के लिए शुरुआती बिंदु बन जाता है।

सहायक लोगों में से, सबसे बड़े को प्रतिष्ठित किया जा सकता है:

• Godaddy.com
• Dyn.com
• 101domain.com
• GKG.net

UPD: अब nic.ru भी DNSSEC www.nic.ru/news/2012/dnssec.html का समर्थन करता है
एक आंशिक सूची यहां पाई जा सकती है ।
रजिस्ट्रार के अलावा, एनएसएसएसईसी-सक्षम एनएस सर्वर की आवश्यकता होती है। कुछ रजिस्ट्रार ऐसी सेवाएं प्रदान करते हैं। गोडैडी का सबसे सस्ता विकल्प प्रीमियम डीएनएस $ 35 / वर्ष है। Dyn.com पर सबसे महंगी को डाइनेक्ट लाइट $ 30 / महीना कहा जाता है। यह आलेख BIND 9.7.3 पर आधारित अपने स्वयं के मास्टर DNS सर्वर को स्थापित करने का एक उदाहरण दिखाएगा।

यह आगे माना जाता है कि हमारे पास पहले से ही अपने स्वयं के लिए एक डोमेन प्रतिनिधि, पूरी तरह से कॉन्फ़िगर किया गया डीएनएस, और एक समाप्त ज़ोन फ़ाइल है।
DN.ECF समर्थन को name.conf में सक्षम करने के लिए, विकल्प अनुभाग में जोड़ें:

 
  विकल्प { 
         ... 
        dnssec- सक्षम हाँ; 
         ... 
  }; 

प्रमुख पीढ़ी और क्षेत्र के हस्ताक्षर उपकरण नवीनतम BIND पैकेज में शामिल हैं।
इस स्तर पर, यह माना जाता है कि पाठक को पहले से ही पता है कि ZSK (जोन साइन कुंजी) और KSK (कुंजी साइन कुंजी) क्या हैं।
निम्नलिखित सभी कार्यों को एक अलग से बनाए गए फ़ोल्डर में किया जाना चाहिए।

ZSK प्रमुख पीढ़ी:

  dnssec-keygen -a RSASHA1 -b 1024 -n ZONE my-domain.com 

KSK प्रमुख पीढ़ी:

  dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE my-domain.com 

जहाँ my-domain.com वह डोमेन है जिसके लिए कुंजियाँ बनाई जाती हैं। इन आदेशों के परिणामस्वरूप, दो प्रमुख जोड़े बनाए जाएंगे।
अगला, आपको वर्तमान फ़ोल्डर में ज़ोन फ़ाइल को कॉपी करने और उस पर हस्ताक्षर करने की आवश्यकता है:

  dnssec-signzone -S -N INCREMENT my-domain.com 

जहाँ my-domain.com ज़ोन टेक्स्ट फ़ाइल है। कमांड को निष्पादित करना महत्वपूर्ण है, चाबियाँ और ज़ोन फ़ाइल के साथ एक ही फ़ोल्डर में होना; पथ के बिना फ़ाइल का नाम।
परिणामस्वरूप, दो फाइलें बनाई जाएंगी:

my-domain.com.sign - ज़ोन हस्ताक्षरित फ़ाइल
dsset-my-domain.com - दो डीएस रिकॉर्ड वाली फ़ाइल

स्रोत ज़ोन फ़ाइल अपरिवर्तित रहेगी। अगला, BIND कॉन्फ़िग में, आपको फ़ाइल को हस्ताक्षरित के साथ बदलना होगा:

  ज़ोन "my-domain.com" { 
          टाइप मास्टर; 
          फ़ाइल "my-domain.com.signed"; 
	  अनुमति-क्वेरी {कोई भी;  }; 
          अनुमति-हस्तांतरण {....;  }; 
  }; 

ज़ोन फ़ाइलों के विस्तृत उदाहरण nox.su पर देखे जा सकते हैं।
अपने DNS की लचीलापन बढ़ाने के लिए, द्वितीयक सर्वरों की सिफारिश की जाती है। DNSSEC- सक्षम दासों की पेशकश करने वाली कई मुफ्त सेवाएँ हैं। यहां http://www.frankb.us/dns/ की आंशिक सूची दी गई है। मैं Rollernet.us का उपयोग करता हूं, इसलिए मैं 208.79.240.3 और 208.79.241.3 पते से स्थानांतरण की अनुमति देता हूं। माध्यमिक-सर्वर का उपयोग करते समय, हस्ताक्षर करने से पहले उनके बारे में रिकॉर्ड ज़ोन फ़ाइल में मौजूद होना चाहिए। मैं मास्टर सर्वर पर हस्ताक्षरित ज़ोन स्थित होने के बाद स्थानांतरण को सक्रिय करने की सलाह देता हूं।

यह आगे माना जाता है कि हस्ताक्षरित क्षेत्र पहले से ही एक अधिकृत एनएस सर्वर पर होस्ट किया गया है और बाहर से सुलभ है:

  dig + dnssec -t any @ super.vip.my.dns.com my-domain.com 

टीम को हस्ताक्षरित ज़ोन वापस करना होगा।

इस स्तर पर, आप द्वितीयक सर्वर को सक्रिय कर सकते हैं और AXFR के माध्यम से क्षेत्र को सिंक्रनाइज़ कर सकते हैं।

इसके बाद, आपको डोमेन रजिस्ट्रार पैनल में डीएस रिकॉर्ड जोड़ना होगा। वे dnssec-signzone के दौरान उत्पन्न हुए थे और निम्नानुसार- dsset-my-domain फ़ाइल में स्थित हैं:

 
  my-domain.com।  IN DS 40513 5 1 6198D29A9FB9797719CDFD2316986BDFF5C29323 
  my-domain.com।  IN DS 40513 5 2 1AAB29EC7B67013F45865AEB06D93899B45C598D65A4E4D5522BC39E B5B9212F 

यह GoDaddy पैनल में DS रिकॉर्ड जोड़ने के लिए फॉर्म है:



संपादन के बाद आपको "उन्नत मोड" पर स्विच करना होगा और दोनों लाइनों को कॉपी करना होगा। आपको TTL मान को जोड़ने और कुंजी के फ़िंगरप्रिंट में दूसरी पंक्ति में स्थान निकालने की आवश्यकता है, अन्यथा फ़ॉर्म एक त्रुटि लौटाएगा। परिणामस्वरूप, प्रतिलिपि बनाई गई लाइनें इस तरह दिखनी चाहिए:

 
  my-domain.com।  86400 इन डीएस 40513 5 1 6198D29A9FB9797719CDFD2316986BDFF5C29323 
  my-domain.com।  86400 इन डीएस 40513 5 2 1AAB29EC7B67013F45865AEB06D93899B45C598D65A4E4D5522BC39EB5B9212F 

प्रविष्टियां तभी जोड़ी जाएंगी जब मास्टर सर्वर पर ज़ोन उपलब्ध हो और सही तरीके से हस्ताक्षरित हो।

डीएस रिकॉर्ड में फ़ील्ड मान:

86400 - इस प्रविष्टि का टीटीएल
40513 - कुंजी टैग
5 - एल्गोरिदम
1/2 - डाइजेस्ट टाइप

उपरोक्त उदाहरण में, आरएसए-एसएचए 1 एल्गोरिथ्म का उपयोग चाबियाँ उत्पन्न करने के लिए किया गया था, इसलिए रिकॉर्ड नंबर पांच है।
एल्गोरिथम संख्या तालिका:

संख्या	एल्गोरिथ्म
1	RSAMD5
2	DH
3	DSA / SHA1
4	ईसीसी
5	आरएसए / एसएचए -1
6	DSA-NSEC3-SHA1
7	RSASHA1-NSEC3-SHA1
8	RSA / SHA-256
9	-
10	RSA / SHA-512
11	-
12	GOST R 34.10-2001

उपरोक्त उदाहरण में डाइजेस्ट टाइप, पहला रिकॉर्ड 1, दूसरा 2 है।
डाइजेस्ट टाइप नंबर टेबल:

संख्या	पाचन प्रकार
1	SHA-1
2	SHA-256
3	SHA-512

कुछ रजिस्ट्रार के लिए, उदाहरण के लिए Dyn.com, एक DS रिकॉर्ड जोड़ने के लिए फार्म कॉपी लाइनों के लिए प्रदान नहीं करता है, लेकिन सभी क्षेत्रों को अलग से भरने की आवश्यकता होती है:


इस तथ्य के कारण कि Dyn.com में एल्गोरिदम की एक सूची है जो क्रम से बाहर हैं और संख्याओं के साथ लेबल नहीं हैं, यह कुछ भ्रम का कारण बनता है। इस फ़ॉर्म को जोड़ते समय, आपको दूसरी कुंजी के फ़िंगरप्रिंट में स्थान को भी निकालना होगा।

डीएस रिकॉर्ड जोड़ने के बाद, आप शीर्ष-स्तरीय डोमेन के लिए जिम्मेदार सर्वर पर उनकी उपस्थिति की जांच कर सकते हैं। डोमेन "com" के लिए यह इस तरह दिखता है:

  dig + dnssec -t DS @ a.gtld-servers.net my-domain.com 

जब ऐसा होता है, तो आप सत्यापित कर सकते हैं कि वेरिसाइन से DNSSEC डीबगर और साइनिंग चेन विज़ुअलाइज़र का उपयोग करके ज़ोन सही ढंग से हस्ताक्षरित है ।
आपको याद दिला दूं कि जोन प्रविष्टियों में प्रत्येक परिवर्तन के बाद, फिर से हस्ताक्षर करना आवश्यक है। डीएस रिकॉर्ड को अद्यतन करने की आवश्यकता नहीं है।
यदि सब कुछ सही है, तो आप क्लाइंट साइड को कॉन्फ़िगर करने के लिए आगे बढ़ सकते हैं।

क्लाइंट रिज़ॉल्वर को कॉन्फ़िगर करना

क्लाइंट पक्ष पर हस्ताक्षर सत्यापित करने के लिए, यह फ़ंक्शन सिस्टम DNS द्वारा समर्थित होना चाहिए, जिसके माध्यम से पता रिज़ॉल्यूशन होता है। Google का सार्वजनिक DNS 8.8.8.8 DNSSEC रिकॉर्ड का समर्थन करता है, लेकिन उन्हें सत्यापित नहीं करता है। एफएक्यू में अधिक पढ़ें
UPD: 19 मार्च, 2013 से, Google सार्वजनिक DNS ने DNSSEC हस्ताक्षर सत्यापित किए हैं, और एक अमान्य हस्ताक्षर के मामले में, यह googleonlinesecurity.blogspot.com/2013/03/google-public-dns-now-supports-dnssec.html को हल नहीं करेगा।

सबसे आसान विकल्प फ़ायरफ़ॉक्स और क्रोम के लिए एक प्लगइन है।



प्लगइन डीएनएस सिस्टम को दरकिनार करने की अनुमति देता है, इसके पास डीएनएसएसईसी सत्यापन के समर्थन के साथ अपने पहले से स्थापित सर्वर हैं। डिफ़ॉल्ट रूप से, प्लगइन सिस्टम DNS का उपयोग करता है, आप इसे प्लगइन सेटिंग्स में बदल सकते हैं: CZ.NIC या 217.31.57.6 का चयन करें

हस्ताक्षर को सत्यापित करने के लिए खुदाई उपयोगिता सिखाने के लिए, आपको रूट ज़ोन के साथ एक फ़ाइल बनाकर विश्वास श्रृंखला में एक प्रारंभिक बिंदु बनाने की आवश्यकता है:

dig +nocomments +nostats +nocmd +noquestion -t dnskey . > /etc/trusted-key.key 

उसके बाद आपको /etc/trusted-key.key फ़ाइल में लाइन हटाने की आवश्यकता है:

 ;; Truncated, retrying in TCP mode. 

यदि ऐसा नहीं किया जाता है, तो खुदाई वापस आ जाएगी:

 No trusted keys present 

अब आप खुदाई का उपयोग करके हस्ताक्षर की प्रामाणिकता को सत्यापित कर सकते हैं:

 dig +sigchase @217.31.57.6 whitehouse.gov 

हस्ताक्षर सत्यापन फ़ंक्शन के साथ एक पुनरावर्ती रिवाल्वर को कैसे कॉन्फ़िगर किया जाए, यहां पाया जा सकता है।

व्यावहारिक लाभ

इस तथ्य के बावजूद कि DNSSEC मानक अभी भी विकास के अधीन है, इससे पहले से ही इसका लाभ संभव है।

SSH सार्वजनिक कुंजी

पहली बार SSH सर्वर से कनेक्ट होने पर, क्लाइंट सर्वर की सार्वजनिक कुंजी के फिंगरप्रिंट को स्वतंत्र रूप से सत्यापित करने और हां दर्ज करने के लिए कहता है, जिसके बाद सर्वर की सार्वजनिक कुंजी ज्ञात_होस्ट फ़ाइल में सहेजी जाती है।
DNSSEC के आगमन के साथ, सार्वजनिक कुंजी को SSHFP प्रकार के DNS-रिकॉर्ड में रखा जा सकता है और, जब पहली बार सर्वर से कनेक्ट होता है, तो यह बिना किसी अनुरोध के स्वचालित रूप से जांच की जाएगी। इस फ़ंक्शन को सक्रिय करने के लिए, आपको SSH क्लाइंट कॉन्फ़िगर के लिए VerifyHostKeyDNS = हाँ विकल्प जोड़ना होगा, यह भी आवश्यक है कि सिस्टम रिज़ॉल्वर DNSSEC सत्यापन का समर्थन करता है।

स्व हस्ताक्षरित एसएसएल प्रमाणपत्र (HTTPS)

UPD: DNS में ssl कीज़ को संग्रहीत करने के लिए मानक प्रकाशित होने के बाद, यह अब और प्रासंगिक नहीं है, और इसका नाम DANE ru.wikipedia.org/wiki/DANE Google ने Chrome से DANE समर्थन हटा दिया। Chrome डेवलपर github.com/agl/dnssec-tls-tools/issues/4 के साथ चर्चा
DNSSEC का उपयोग करके, आप स्वतंत्र रूप से एक SSL प्रमाणपत्र पर हस्ताक्षर कर सकते हैं जो ब्राउज़र में "मान्य" होगा।
यह प्रयोगात्मक सुविधा वर्तमान में सक्रिय विकास में है और वर्तमान में केवल Google Chrome / Chromium ब्राउज़र द्वारा समर्थित है।
ड्राफ्ट मानक: tools.ietf.org/html/draft-agl-dane-serializechain-01

इस तकनीक को एडम लैंगले नामक एक Google कर्मचारी द्वारा विकसित किया जा रहा है, और उसके पास एक बहुत ही दिलचस्प ब्लॉग है http://www.imperialviolet.org/ ।
इस तकनीक के बारे में एक पोस्ट ।

यह आगे माना जाता है कि जिस डोमेन के लिए प्रमाणपत्र उत्पन्न होता है, वह DNSSEC द्वारा हस्ताक्षरित हो सकता है।

डाउनलोड dnssec-tls-tools:

  git क्लोन क्लोन git: //github.com/agl/dnssec-tls-tools.git 

और संकलन करें:

  gcc -o gencert gencert.c -Wall -lcrypto 

RSA प्रमुख पीढ़ी:

  Opensl genrsa 1024> privkey.pem
 opensl rsa -pubout -in privkey.pem> pubkey.pem 

एक प्रमुख फिंगरप्रिंट बनाना:

  python ./gencaa.py pubkey.pem 

जहाँ dnssec-tls-tools पैकेज से gencaa.py फ़ाइल है।
आदेश प्रपत्र की एक पंक्ति लौटाएगा:

  EXAMPLE.COM।  60 IN TYPE257 \ # 70 020461757468303e3039060a2b06010401d6790203010 ... 

यह DNS रिकॉर्ड है जिसे आपको EXAMPLE.COM की जगह अपनी ज़ोन फ़ाइल में जोड़ना होगा। इसका अर्थ है। यदि ज़ोन पर अभी तक हस्ताक्षर नहीं किए गए हैं, तो यह किया जाना चाहिए। यदि रिकॉर्ड पहले से ही हस्ताक्षरित ज़ोन में जोड़ा जाता है, तो फिर से, साइनिंग फिर से करने के लिए आवश्यक है।

DNS में सही कुंजी की जाँच करें:

  खुदाई + dnssec + sigchase -t type27 example.com 

कमांड DNSSEC लौटना चाहिए सत्यापन ठीक है: सफलता

Type27 रिकॉर्ड उपलब्ध है और हस्ताक्षर किए जाने के बाद, आप DNSSEC विश्वास श्रृंखला उत्पन्न कर सकते हैं:

  python ./chain.py example.com chain 

और प्रमाण पत्र ही:

  ./gencert privkey.pem चेन> cert.pem 

Nginx में एक प्रमाण पत्र को जोड़ना इस तरह दिखता है:

 सर्वर {
         ...
	 ssl on;
	 ssl_certificate cert.pem;
	 ssl_certificate_key privkey.pem;
         ...
  } 

इस तथ्य के कारण कि DNSSEC हस्ताक्षर करने वाली श्रृंखला बदल सकती है, श्रृंखला निर्माण और प्रमाणपत्र पीढ़ी (अंतिम दो कमांड) को मुकुट में जोड़ा जाना चाहिए और निष्पादित किया जाना चाहिए, उदाहरण के लिए, दिन में एक बार।

परिणाम इस तरह दिखना चाहिए: https://dnssec.imperialviolet.org/

इस तथ्य के कारण कि पूरी DNSSEC श्रृंखला को प्रमाण पत्र में रखा गया है, ब्राउज़र को पूर्ण श्रृंखला जांच करने की आवश्यकता नहीं है, इसलिए सिस्टम रिज़ॉल्वर DNSSEC सत्यापन का समर्थन नहीं करने पर भी प्रमाणपत्र "मान्य" होगा।

---

PS यह आलेख DNSSEC कुंजियों की वैधता पर चर्चा नहीं करता है, ट्रस्ट के वैकल्पिक DLVEC लुक-साइड सत्यापन DLV श्रृंखला के बारे में बात नहीं करता है। मैं उन लोगों का आभारी रहूंगा जो इन मुद्दों को समझेंगे और उनका वर्णन करेंगे।

पीपीएस मैं ऐसे टर्न-आधारित HOWTO के नकारात्मक प्रभाव को जानता हूं जो बिना समझ के टीमों की नासमझ नकल की ओर ले जाते हैं। लेकिन, इस तथ्य के कारण कि इस मुद्दे पर बहुत कम जानकारी है और कुछ जगहों पर यह विरोधाभासी है, मुझे उम्मीद है कि यह लेख किसी को इस भ्रम से बचने में मदद करेगा जो मुझे सामना करना पड़ा था। परामर्श और उनके लेखों के लिए अलेक्जेंडर वैद्युखिन का धन्यवाद।