DNSSec: क्या और क्यों है

प्रस्तावना

जैसा कि यह निकला, बहुत से लोग नहीं जानते कि DNSSec क्या है, इसकी आवश्यकता क्यों है, क्यों नहीं, और क्या यह घर पर इसे लागू करने के लायक है। चूंकि रूसी में इस विषय पर बहुत कम जानकारी है, इसलिए मैं इन मुद्दों पर प्रकाश डालने की कोशिश करूंगा।

DNSSec क्या है

थोड़ा इतिहास

प्रारंभ में, डोमेन नाम प्रणाली के पास प्रतिक्रिया में स्पूफिंग जानकारी के खिलाफ सुरक्षा के लिए कोई तंत्र नहीं था - सिस्टम आर्किटेक्चर ऐसा है कि अनुरोध और प्रतिक्रिया दोनों स्पष्ट पाठ में प्रेषित होते हैं। उसी समय, रिज़ॉल्वर ने केवल अनुरोध पहचानकर्ता द्वारा प्राप्त जानकारी की निष्ठा का न्याय किया, जिसकी लंबाई केवल 2 बाइट्स है। यही है, कैश को जहर देने के लिए, आपको बस 65,536 मूल्यों को सुलझाना होगा। उन्होंने 90 के दशक में इसके बारे में बात करना शुरू किया। इसी समय, उन्होंने धीरे-धीरे DNSSec के पहले संस्करण का वर्णन करना शुरू किया। उसने 1997 में प्रकाश को देखा, दो साल बाद अगले एक को दिखाई दिया। 2005 में, DNSSec का वर्तमान संस्करण दिखाई दिया, जिसके साथ हर कोई काम करता है। 2008 में एक ऐतिहासिक घटना हुई, जब डैन कमिंसकी ने दुनिया को दिखाया कि आप 10 सेकंड में कैश को जहर दे सकते हैं। DNS सॉफ़्टवेयर के निर्माताओं ने यह कहकर प्रतिक्रिया दी कि अनुरोध पहचानकर्ता के अलावा, वे बेतरतीब ढंग से आउटगोइंग पोर्ट का चयन करने लगे। रास्ते के साथ, DNSSec की शुरुआत से हिस्टीरिया शुरू हुआ।

यह कैसे काम करता है

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

ZSK

इस कुंजी के साथ, ज़ोन (आरआरएसईटी) के सभी रिकॉर्ड सेटों पर हस्ताक्षर किए गए हैं, प्रतिनिधिमंडल बिंदुओं को छोड़कर। यह है, मान लें कि आपके पास example.com ज़ोन है और इसमें ऐसा एक टुकड़ा है:

 $ORGIGIN example.com. @ SOA dns.example.com ns.example.com { Serial Refresh Retry Expire nTTL } NS ns.example.com. NS ns1.example.com. DNSKEY 256 3 5 ( AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5 ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2 HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl zghFU3eQSAnWF0xP/c323rtP0irdY7v5 ) ; key id = 38754 DNSKEY 257 3 5 ( AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/ b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r inl4k8xDTVvaPnmBScxbuBc= ) ; key id = 23179 doo IN A 127.0.0.1 IN A 127.0.0.2 IN MX mail foo NS ns1.test.ru. NS ns2.test.ru. bar NS ns1.test.ru. NS ns2.test.ru. DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11 DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852 
 

$ORGIGIN example.com. @ SOA dns.example.com ns.example.com { Serial Refresh Retry Expire nTTL } NS ns.example.com. NS ns1.example.com. DNSKEY 256 3 5 ( AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5 ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2 HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl zghFU3eQSAnWF0xP/c323rtP0irdY7v5 ) ; key id = 38754 DNSKEY 257 3 5 ( AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/ b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r inl4k8xDTVvaPnmBScxbuBc= ) ; key id = 23179 doo IN A 127.0.0.1 IN A 127.0.0.2 IN MX mail foo NS ns1.test.ru. NS ns2.test.ru. bar NS ns1.test.ru. NS ns2.test.ru. DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11 DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852

और आपने इस क्षेत्र पर हस्ताक्षर करने का निर्णय लिया। निम्नलिखित किया जाएगा:

1. हस्ताक्षरित रिकॉर्ड का एक क्रम बनाया जाएगा;
2. NSEC प्रविष्टियाँ जोड़ी जाएँगी (उस पर और अधिक);
3. SOA रिकॉर्ड, उदाहरण के लिए NS सेट.कॉम, doo के लिए पता और MX रिकॉर्ड, प्रत्येक NSEC RR और प्रत्येक DS सेट को सब्सक्राइब किया जाएगा।
4. सॉफ़्टवेयर सेटिंग्स के आधार पर, DNSKEY सेट पर भी हस्ताक्षर किए जा सकते हैं।

प्रत्यायोजन अंक, अर्थात्। चाइल्ड जोन के लिए एनएस रिकॉर्ड पर हस्ताक्षर नहीं किए जाएंगे।

केएसके

यह कुंजी DNSKEY रिकॉर्ड के सेट पर हस्ताक्षर करती है।
इसके अलावा, KSK के खुले भाग से एक हैश लिया जाता है, जिसे बाद में मूल क्षेत्र में भेज दिया जाता है। उपरोक्त उदाहरण में, ये डीएस रिकॉर्ड (प्रतिनिधि हस्ताक्षरकर्ता) हैं।
रूट ज़ोन के मामले में, यह माना जाता है कि कुंजी के खुले हिस्से को रिवाल्वर से मैन्युअल रूप से संचार किया जाएगा। और कुंजी को बदलते समय हर बार इसे मैन्युअल रूप से अपडेट नहीं करने के लिए, इसके स्वचालित अपडेट के लिए तंत्र हैं, उदाहरण के लिए, BIND के पास प्रबंधित-कुंजी विकल्प है।
जाहिर है, KSK के बंद हिस्से को आंख के सेब के रूप में संग्रहीत किया जाना चाहिए - सबसे पहले, DNSSec का पूरा बिंदु गायब हो जाता है, और दूसरी बात, समझौता के मामले में, केएसके को जल्दी से बदलना संभव नहीं होगा।

अगला सुरक्षित

खैर, यहां हमने ज़ोन पर हस्ताक्षर किए, लेकिन फिर भी कोई बाहरी व्यक्ति इसमें अपनी जानकारी जोड़ सकता है और, यहां तक ​​कि अहस्ताक्षरित, यह सर्वर द्वारा हस्ताक्षरित के साथ दिया जाएगा।

ज़ोन पर हस्ताक्षर करते समय ऐसा होने से रोकने के लिए, डोमेन नामों को वर्णानुक्रम में क्रमबद्ध किया जाता है, उनमें से प्रत्येक में एक NSEC रिकॉर्ड जोड़ा जाता है, जो इंगित करता है कि अगला डोमेन नाम किस क्षेत्र में सुरक्षित है और इसके लिए कौन से रिकॉर्ड ज़ोन में मौजूद हैं। अंतिम NSEC प्रविष्टि SOA की ओर इशारा करती है।
यदि आधिकारिक सर्वर प्रतिक्रिया NXDOMAIN (RCODE = 3) या NODATA (RCODE = 0) देता है, तो NSEC रिकॉर्ड को प्रतिक्रिया में मौजूद होना चाहिए। ऐसे उत्तर का एक उदाहरण:

 ; <<>> DiG 9.7.3 <<>> jhbczxccva.se +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8766 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;jhbczxccva.se. IN A ;; AUTHORITY SECTION: se. 300 IN SOA catcher-in-the-rye.nic.se. registry-default.nic.se. 2011053104 1800 1800 864000 7200 se. 300 IN RRSIG SOA 5 1 172800 20110613123930 20110531090447 24825 se. JJGWAvmcB/Bq7t5z7iTQGLr9c0LzQkdwpNFsrIClJctZUn/Z3YN2EMVQ 0r6DvufTGk1L8JMvTaxkI43ZmvasFeNNzfUFjr+td8Mv9h7FF5kTfEO5 R7JMh4j0Kxl/Gy4j+Ofcm0ZiCZTtcnNdHwCIHaVpz9KA6uIubnlJNSLw YXI= 

चूंकि NXDOMAIN प्रतिक्रिया हमेशा SOA रिकॉर्ड के साथ होती है, इसलिए SOA और हस्ताक्षर इसके लिए हस्ताक्षरित क्षेत्र में वापस आ जाते हैं।

 se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY // Asi9 / 2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ = se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY 

यह NSEC प्रविष्टि इंगित करती है कि निर्दिष्ट नाम मास्क के अंतर्गत नहीं आता है।

 jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk = jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC 

और पहले से ही यह एनएसईसी रिकॉर्ड कहता है कि डोमेन नाम नहीं मिला था।

एनएसईसी का नुकसान स्पष्ट है - किसी को भी प्रत्येक नाम के लिए इस प्रविष्टि को मतदान करके एक जोन की सामग्री मिल सकती है। इस संबंध में, तंत्र को अंतिम रूप दिया गया और NSEC3 प्रविष्टियाँ दिखाई दीं जिनमें डोमेन नाम हैशेड हैं।
NSEC3 नमक का उपयोग हैश की गणना करने के लिए कर सकता है, नमक के अलावा, आप पुनरावृत्तियों की संख्या निर्दिष्ट कर सकते हैं। यह ध्यान देने योग्य है कि पुनरावृत्तियों की संख्या में वृद्धि से रिज़ॉल्वर और आधिकारिक सर्वर दोनों पर भार में वृद्धि होती है, और उत्तरार्द्ध अधिक से अधिक हद तक। यह इस तथ्य के कारण है कि NXDOMAIN को वापस करने के लिए, आधिकारिक सर्वर को हैश की गणना करनी चाहिए, और एक की नहीं। प्रक्रिया RFC 5155 में वर्णित है।

इसके अलावा, NSEC3 प्रविष्टि में एक ध्वज क्षेत्र है जो NSEC के पास नहीं है। फिलहाल, केवल एक ध्वज को परिभाषित किया गया है - OPT-OUT, जिसके कारण पूरे क्षेत्र पर हस्ताक्षर करना संभव नहीं है (जो बड़े आकारों के लिए एक बहुत लंबी प्रक्रिया हो सकती है), लेकिन केवल उन डोमेन नामों के लिए जिनके पास डीएस रिकॉर्ड हैं।
एक ओर, OPT-OUT हस्ताक्षर समय को काफी कम कर सकता है, लेकिन इसका उपयोग करते समय, हमलावर के पास ज़ोन फ़ाइल तक पहुंच होती है जो उसे असुरक्षित प्रविष्टि को जोड़ने की अनुमति देता है, जिससे भविष्य में समस्या हो सकती है।

काम का तंत्र

मान लें कि हम पता test.bar.example.com जानना चाहते हैं:

1. हम रिज़ॉल्वर से एक डोमेन नाम का अनुरोध करते हैं;
2. रिज़ॉल्वर डीओ बिट सेट करता है और रूट सर्वर से test.bar.example.com का अनुरोध करता है;
3. रिज़ॉल्वर जानता है कि रूट डोमेन ज़ोन पर हस्ताक्षर किए गए हैं - इसके लिए एक कुंजी या कुंजी हैश (तथाकथित ट्रस्ट-एंकर) है, इसलिए यह रूट ज़ोन के लिए प्रविष्टियों के लिए रूट DNSKEY सर्वर पर सवाल उठाता है और मौजूदा के साथ तुलना करता है;
4. रूट सर्वर ऐसे डोमेन नाम को नहीं जानता है, और सामान्य तौर पर अधिकतम यह जानता है कि कॉम ज़ोन किन सर्वरों पर स्थित है, यह इन सर्वरों के पते को कॉम ज़ोन के लिए डीएस रिकॉर्ड के साथ हमारे रिज़ॉल्वर को रिपोर्ट करता है;
5. रिज़ॉल्वर प्राप्त और सत्यापित ZSK रूट ज़ोन कुंजी के साथ DS रिकॉर्ड को मान्य करता है;
6. अब रिज़ॉल्वर जानता है कि कॉम ज़ोन पर हस्ताक्षर किए गए हैं, इसलिए यह अपने DNS सर्वर DNSKEY से पूछता है और उन्हें सत्यापित करता है, जिसके बाद यह bar.example.com में रुचि रखता है। स्वाभाविक रूप से, ज़ोन कॉम के सर्वर को इन के बारे में नहीं पता है, यह केवल जानता है कि ज़ोन example.com ns.example.com और ns1.example.com पर रहता है, और यह वही है जो रिज़ॉल्वर को उत्तर देता है, हाँ, हाँ, डीएस रिकॉर्ड;
7. इसलिए रिज़ॉल्वर ने example.com पर विश्वास की एक श्रृंखला बनाई, जहाँ यह bar.example.com ज़ोन के नाम सर्वर और उसके DS को पहचानता है;
8. अंत में, रिज़ॉल्वर iteratively बार.example.com के लिए ज़िम्मेदार सर्वर के DNS पते सीखता है, उनके पास जाता है और अंत में उसे वही मिलता है, जो सभी सूचनाओं को मान्य करता है और हमें प्रतिक्रिया में AD बिट सेट करते हुए एड्रेस रिकॉर्ड देता है।

यदि कुछ को मान्य करना असंभव है, तो रिज़ॉल्वर सर्विफ़ेल लौटा देगा।

गाया प्रभाव

1. एक प्रतिष्ठित DNS सर्वर का आउटगोइंग ट्रैफ़िक लगभग 4 गुना बढ़ जाता है;
2. ज़ोन फ़ाइल का आकार हस्ताक्षर (ऑप्ट-आउट के बिना) 6-7 बार बढ़ता है;
3. कुंजी लंबाई में वृद्धि रिज़ॉल्वर के क्यूपीएस में ध्यान देने योग्य कमी की ओर जाता है, यह आधिकारिक सर्वर को कुछ हद तक प्रभावित करता है;
4. इसके विपरीत, NSEC3 का उपयोग करते समय पुनरावृत्तियों की संख्या में वृद्धि होती है;
5. DNSSec DNS प्रतिक्रिया में एक महत्वपूर्ण वृद्धि की ओर जाता है और इसलिए, यह आवश्यक है कि सभी नेटवर्क उपकरण 512 बाइट से अधिक के DNS पैकेट के साथ सही ढंग से काम करें।

क्यों जरूरी है?

यह एक पेचीदा सवाल है। सबसे पहले, निर्मित प्रभावों को ध्यान में रखा जाना चाहिए; दूसरी बात, चाबियों के लिए एक विश्वसनीय भंडारण को व्यवस्थित करना आवश्यक है; तीसरा, मॉनिटर कुंजी रोटेशन; चौथा, हस्ताक्षर की समाप्ति तिथि की निगरानी करें; पांचवां, DNSSec प्रवर्धित ddos ​​के प्रभाव को बढ़ाता है।
यह सब आधिकारिक डीएनएस सर्वर से प्राप्त जानकारी के बारे में सुनिश्चित करने के लिए मूल्य है। अब, हालांकि, समुदाय सोच रहा है कि DNSSec में और क्या शामिल किया जा सकता है ताकि इसे मुद्रीकृत किया जा सके, और कुछ भी बहुत ही बोल्ड और दिलचस्प सवाल पूछते हैं, उदाहरण के लिए, एएफएनआईसी वैज्ञानिक परिषद के सदस्य फिल रेग्नॉल, जो पूछते हैं कि क्या DNSSEC प्रमाणपत्र उद्योग को नीचे लाएगा? " इस परिषद की कार्यशाला में।

इस विषय पर क्या पढ़ा जाए

• यहां से यह खुदाई शुरू करने के लायक है ;
• एक बहुत विस्तृत कार्यान्वयन गाइड ;
• यह ज़ोन आरयू, एसयू, एक्सएन - पी 1 एआई के बारे में बताता है ;
• और, ज़ाहिर है, rfc 4033-4035।