डोमेन पंजीयक के साथ व्यवहार में DNSSEC

इस लेख में, Webnames.Ru , रूस में सबसे बड़े डोमेन नाम रजिस्ट्रारों में से एक, DNSSEC सुरक्षा प्रोटोकॉल का अभ्यास करने के तरीके के बारे में बात करेगा, एक तकनीक जो डोमेन नाम प्रणाली की कमजोरियों की रक्षा करती है, जो DNS प्रश्नों के डिजिटल रूप से हस्ताक्षरित प्रतिक्रियाओं की विधि पर आधारित है।



ऐतिहासिक पृष्ठभूमि

डोमेन नाम प्रणाली (डीएनएस) इंटरनेट के सबसे महत्वपूर्ण घटकों में से एक है, हालांकि, इसके विकास के समय, सुरक्षा मुद्दों पर अपर्याप्त ध्यान दिया गया था। इंटरनेट के विकास के साथ, DNS सिस्टम में कमजोरियों का पता चला है। DNS सर्वर प्रतिक्रिया की विश्वसनीयता की जांच नहीं की जाती है, जो उपयोगकर्ता के अनुरोध को एक मनमाने आईपी पते पर पुनर्निर्देशित करके सर्वर प्रतिक्रिया को बदलने की अनुमति देता है। इंटरनेट सर्वर प्रदाताओं के कैशिंग डीएनएस सर्वर भी कमजोर थे क्योंकि एक आधिकारिक डीएनएस स्रोत (कमिंसकी हमले) से आने वाले डेटा के साथ डीएनएस सर्वर कैश को भरने की संभावना नहीं थी।

हालाँकि, यह नहीं कहा जा सकता है कि DNS सुरक्षा के बारे में अब तक सोचा नहीं गया है। इस प्रणाली में गंभीर सुरक्षा खामियों की पहचान 1990 में स्टीव बेल्लोविन ने की थी। 1995 में रिपोर्ट के प्रकाशन के बाद से इस क्षेत्र में अनुसंधान शुरू हुआ और 1997 में IETF (इंटरनेट इंजीनियरिंग टास्क फोर्स) ने इस विषय पर पहला विनिर्देशों (RFC 2065) प्रकाशित किया। इस विनिर्देश को लागू करने के पहले प्रयासों ने 1999 में एक नए विनिर्देशन (RFC 2535) का उदय किया। IETF RFC 2535 विनिर्देश के अनुसार, DNSSEC के कार्यान्वयन की योजना बनाई गई थी, हालांकि, पूरे इंटरनेट पर फैलने के साथ इसमें बहुत गंभीर समस्याएं थीं। 2001 तक, यह स्पष्ट था कि यह विनिर्देश बड़े नेटवर्क के लिए उपयुक्त नहीं था। इसके परिणामस्वरूप, DNSSEC (DNSSEC-bis) में मूलभूत परिवर्तनों के साथ नए विनिर्देशों (RFC 4033, 4034 4035) की उपस्थिति हुई, जिसका नया संस्करण पिछले कार्यान्वयन की मुख्य समस्या को समाप्त करता है और, हालांकि नए विनिर्देश में, ग्राहकों को कुंजियों को सत्यापित करने के लिए अतिरिक्त कदम उठाने की आवश्यकता होती है। , यह व्यावहारिक उपयोग के लिए काफी उपयुक्त है।

दुर्भाग्य से, जैसा कि आमतौर पर होता है, DNSSEC की कमियां इसकी खूबियों का एक सिलसिला हैं। DNS डेटा को साइन और सत्यापित करने से अतिरिक्त लागत पैदा होती है, जो नेटवर्क और सर्वर के प्रदर्शन पर प्रतिकूल प्रभाव डालती है। उदाहरण के लिए, औसतन, DNSSEC ज़ोन DNS सिस्टम के आकार का 7-10 गुना है। हस्ताक्षर बनाने और सत्यापित करने में बहुत अधिक CPU समय लगता है। हस्ताक्षर और चाबियां डिस्क पर और रैम में डेटा की तुलना में अधिक स्थान का क्रम लेते हैं।

हालांकि DNSSEC पर काम अभी तक पूरा नहीं हुआ है, जो भी संगठन इंटरनेट का सक्रिय रूप से उपयोग करता है, उसे पहले से ही DNSSEC को अपने सुरक्षा ढांचे का एक अनिवार्य घटक मानना ​​चाहिए। DNS प्रोटोकॉल अभी भी साइबर हमलों के लिए असुरक्षित है।

हमारे दिन

यह रनेट में इस तकनीक की अलोकप्रियता को ध्यान देने योग्य है। स्मरण करें कि .SU DNSSEC ज़ोन अक्टूबर 2011 में, .RF ज़ोन - नवंबर 2012 में और इन .RU ज़ोन - दिसंबर 2012 में पेश किया गया था।

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

फिर तार्किक सवाल उठता है: परिचय क्यों? तथ्य यह है कि Webnames.Ru हमेशा रहा है और कई DNS मुद्दों में अग्रणी और खोजकर्ता बना हुआ है। DNSSEC की शुरूआत हमारा अगला कदम है। और न केवल घरेलू डोमेन ज़ोन के लिए, बल्कि कई अन्य लोगों के लिए भी।

इस पर मैं सिद्धांत और दर्शन के साथ समाप्त करने का प्रस्ताव करता हूं। अब अपने स्वयं के नाम सर्वर पर DNSSEC के व्यावहारिक उपयोग पर विचार करें।

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

DNSSEC द्वारा अपने लेखकों के अनुसार काम शुरू करने के लिए, निम्नलिखित घटकों की आवश्यकता है:

- पहले स्तर का एक हस्ताक्षरित क्षेत्र (हमारे पास घरेलू .RU .SU और . the) है
- इस क्षेत्र में डोमेन (हमारे पास webnames.ru है)
- हमारे डोमेन के लिए आधिकारिक DNS सर्वर (उपलब्ध)
- रिज़ॉल्वर (DNS सर्वर कैशिंग)

डेबियन का वर्तमान स्थिर संस्करण निचोड़ 6.0.7 है। हम इसे आधार के रूप में उपयोग करेंगे। हमारे पास DNS सर्वर के रूप में bind9 है।

हम स्वयं bind9 को स्थापित और कॉन्फ़िगर करने के विवरण को छोड़ देते हैं। यह बस रखा जाता है:

aptitude install bind9 

DNSSEC के साथ काम करने के लिए घटक:

 aptitude install dnssec-tools libcrypt-openssl-random-perl 

सभी कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से / etc / bind / में हैं
यहां हम name.conf.options में विकल्पों में रुचि रखते हैं। उनमें आपको जोड़ना होगा:

 dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; 

उसके बाद आपको कॉन्फ़िगरेशन को फिर से पढ़ने या बाइंड करने की आवश्यकता है। दो विकल्प हैं: rndc reconfig या /etc/init.d/bind9 पुनरारंभ

कार्यान्वयन में आसानी के लिए, हम ज़ोनिग्नर का उपयोग करेंगे। यह एक व्यापक उपयोगिता है जो एक बार में क्षेत्र पर हस्ताक्षर करता है। अधिक जटिल तरीका है, लेकिन इसकी आवश्यकता क्यों है?

आगे देखते हुए, मैं यह कहूंगा कि अपने काम के दौरान, ज़ोनसिग्नर एक दर्जन फाइलें बनाता है और इसे अलग से लगाने के लिए अधिक तर्कसंगत है, और जोनों के साथ एक सामान्य निर्देशिका में नहीं। और ज़ोन को एक निर्देशिका में नहीं रखना बेहतर है। यह कोई समस्या नहीं है। आपके पास केवल कुछ डोमेन हैं। लेकिन अगर हमारे पास प्रत्येक सर्वर पर 150 हजार से अधिक क्षेत्र हैं, तो हमें किसी तरह उनके भंडारण का अनुकूलन करने की आवश्यकता है, अन्यथा भारी ओवरहेड्स उत्पन्न होते हैं।

विकास की प्रक्रिया में, हमें ज़ोन के निम्नलिखित पदानुक्रम प्राप्त हुए: ऑटो / आरयू / डब्ल्यू / ई / बी / एन / वेबनामेस। एक समान समानांतर शाखा जोनिगर के लिए बनाई गई थी: dnssec / ru / w / e / b / n / webnamesroom /

हस्ताक्षरित क्षेत्र की प्रारंभिक पीढ़ी इस तरह दिखती है:

 mkdir -p /var/named/dnssec/ru/w/e/b/n/webnames.ru/ cd /var/named/dnssec/ru/w/e/b/n/webnames.ru/ zonesigner -genkeys -usensec3 -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru 

आउटपुट पर, हमें कुछ ऐसा मिलता है:

  if zonesigner appears hung, strike keys until the program completes (see the "Entropy" section in the man page for details) Generating key pair.....++++++ .........................................................................++++++ Generating key pair..++++++ ...++++++ Generating key pair....+++ .........+++ Verifying the zone using the following algorithms: RSASHA256. Zone signing complete: Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 1 stand-by, 0 revoked zone signed successfully webnames.ru: KSK (cur) 02110 -b 2048 02/22/13 (webnames.ru-signset-00003) ZSK (cur) 21834 -b 1024 02/22/13 (webnames.ru-signset-00001) ZSK (pub) 51069 -b 1024 02/22/13 (webnames.ru-signset-00002) zone will expire in 4 weeks, 2 days, 0 seconds DO NOT delete the keys until this time has passed. 

अब सुनिश्चित करें कि बहुत सारी फाइलें बनी हैं:

 $ls -1 dsset-webnames.ru. Kwebnames.ru.+008+02110.key Kwebnames.ru.+008+02110.private Kwebnames.ru.+008+21834.key Kwebnames.ru.+008+21834.private Kwebnames.ru.+008+51069.key Kwebnames.ru.+008+51069.private webnames.ru.krf 

और नियमित ज़ोन फ़ाइल के बगल में, दूसरी webnames.ru.sign फ़ाइल दिखाई दी, और यह 1369 के खिलाफ मूल - 32669 बाइट्स से 20 गुना बड़ा है। और ऊपर उल्लेखित सेवा फ़ाइलों के लिए एक और 7520 बाइट्स। यानी हमें 30 गुना अधिक जानकारी मिली है। सच है, webnames.ru ज़ोन बहुत छोटा है, और इस तरह की वृद्धि भारी वजन नहीं करती है।

बस, त्रुटियों के लिए नई ज़ोन फ़ाइल की जाँच करें:

 $ donuts --level 8 webnames.ru.signed webnames.ru 0 errors found in webnames.ru.signed 

"-Level" त्रुटि दर है। जब कोई त्रुटि नहीं होती है, तो इसमें कोई विशेष अर्थ नहीं होता है। वैसे, इन त्रुटियों को चलाने का एक बहुत ही सरल तरीका है। उदाहरण के लिए, एक तृतीय-पक्ष DNS सर्वर के साथ एक NS रिकॉर्ड जोड़ना।
ज़ोन में खराब NS ns1.gde-to-tam-daleko.ru प्रविष्टि जोड़ें और अपडेट करें:

 zonesigner -zone webnames.ru /var/named/auto/ru/w/e/b/n/webnames.ru 

कृपया ध्यान दें कि आपको हमेशा नियमित क्षेत्र को संपादित करने की आवश्यकता है, और हस्ताक्षरित DNSSEC को उस तरह से अपडेट करने की आवश्यकता है।

अब त्रुटियों की जाँच करें:

 $ donuts --level 8 webnames.ru.signed webnames.ru bad.webnames.ru: Warning: Only 1 NS record(s) for bad.webnames.ru found, but at least 2 are suggested/required bad.webnames.ru: Error: sub-domain bad.webnames.ru is not securely delegated. It is missing a DS record. 2 errors found in webnames.ru.signed 

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

लेकिन ये डीएस कहां से आते हैं? ऊपर हमने dsset-webnames.ru फ़ाइल दिखाई है। इसकी सामग्री इस प्रकार है:

 webnames.ru. IN DS 2110 8 1 4F38DB26A26DDFFB0A84052472D1AF70DAA595D7 webnames.ru. IN DS 2110 8 2 0CC3937FE64FD4BF3B8282748F93C566870F4FCD254BCF0D91DBCF50 23D6D28C 

यह इन अभिलेखों को डोमेन पंजीयक को हस्तांतरित किया जाना चाहिए ताकि वह उन्हें ज़ोन की रजिस्ट्री में भेज दे। और डोनट्स के लिए एनएस रिकॉर्ड के लिए त्रुटियों को जारी करने से रोकने के लिए उनकी आवश्यकता भी होती है।

विभिन्न रजिस्ट्रारों के लिए स्थानांतरण प्रक्रिया अलग है। Webnames.Ru पर , उदाहरण के लिए, आपके खाते में अनुभाग "डोमेन प्रबंधन" में एक विशेष आइटम "DNSSEC" है जहां आप DNSSEC समर्थन को चालू और बंद कर सकते हैं, साथ ही मौजूदा डीएस रिकॉर्ड भी देख सकते हैं और यदि आवश्यक हो, तो नए बना सकते हैं।

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

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

 rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf-admin support@webnames.ru webnames.ru >> /var/named/dnssec/rollrec 

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

उसके बाद आपको रोलर शुरू करने की आवश्यकता है। यहाँ वादा किया गया init स्क्रिप्ट है: /etc/init.d/rollerd

 #!/bin/bash ### BEGIN INIT INFO # Provides: rollerd # Required-Start: $remote_fs $network $syslog # Required-Stop: $remote_fs $network $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO PATH=/bin:/usr/bin:/sbin:/usr/sbin DESC="DNSSEC-Tools daemon to manage DNSSEC key rollover" NAME=rollerd DAEMON=/usr/sbin/$NAME SCRIPTNAME=/etc/init.d/$NAME CONF=/var/named/dnssec/rollrec PIDFILE=/var/run/rollerd.pid [ -x "$DAEMON" ] || exit 0 . /lib/init/vars.sh . /lib/lsb/init-functions [ -f $CONF ] || exit 0 start_rollerd () { [ -f $PIDFILE ] && return 1 $DAEMON -rrfile $CONF -directory /etc/bind -pidfile $PIDFILE } stop_rollerd () { if [ -s $PIDFILE ]; then PID=`cat $PIDFILE` kill $PID && rm -f $PIDFILE sleep 3 [ -d "/proc/$PID" ] && return 1 return 0 fi PID=`ps xa | grep -v grep | grep $DAEMON | awk '{print $1}'` [ -z "$PID" ] && return 0 kill $PID sleep 3 [ -d "/proc/$PID" ] && return 1 return 0 } case "$1" in start) log_daemon_msg "Starting $DESC" "$NAME"; start_rollerd; log_end_msg $?; ;; stop|force-stop) log_daemon_msg "Stopping $DESC" "$NAME"; stop_rollerd; log_end_msg $?; ;; restart) log_daemon_msg "Restarting $DESC" "$NAME"; stop_rollerd; start_rollerd; log_end_msg $?; ;; *) echo "Usage: $0 "; exit 1; ;; esac; exit 0; 

हम इसे लॉन्च, ऑटोरन के लिए तैयार करते हैं और इसे शुरू करते हैं।

 chmod 755 /etc/init.d/rollerd update-rc.d rollerd defaults /etc/init.d/rollerd start 

मेल डेमॉन का उपयोग करके, आप कुंजियों के पूर्ण रोटेशन को स्वचालित कर सकते हैं। हम इसके लिए Sendmail का उपयोग करते हैं। तो smrsh से आप लगभग कुछ भी कर सकते हैं। यह काफी सरलता से किया जाता है। /Etc/mail/sendmail.mc में, पहले मेलर से पहले निम्न पंक्तियाँ जोड़ें:

 FEATURE(`virtusertable', `hash /etc/mail/virtusertable')dnl VIRTUSER_DOMAIN_FILE(`/etc/mail/local-host-names')dnl 

में / आदि / मेल / पुण्य जोड़ने:
dnssec @ लोकलहोस्ट dnssec

इस प्रकार, हमने एक वर्चुअल मेलबॉक्स dnssec @ localhost बनाया और सिस्टम उपयोगकर्ता dnssec को सभी आने वाले मेल भेजे।

/ Etc / उपनामों में जोड़ें:
dnssec: "| / etc / mail / smrsh / dnssec"

इसलिए हमने सभी आवक मेल को स्क्रिप्ट (आदि / उसकी STDIN में पाइप) के माध्यम से उपयोगकर्ता के पास भेजा / स्क्रिप्ट / आदि / smrsh / dnssec

और स्क्रिप्ट / etc / mail / smrsh / dnssec में हम जो चाहें वो कर सकते हैं।
यह ध्यान देने योग्य है कि इसे सशर्त रूप से स्क्रिप्ट कहा जाता है। यह एक बाइनरी हो सकता है।

अब Sendmail को पुनः आरंभ करें और सभी परिवर्तन प्रभावी होंगे:
/etc/init.d/sendmail पुनः आरंभ करें

उसी समय, यह मत भूलो कि smrsh का उपयोग करते समय आपको पता dnssec @ localhost पते के साथ / var / नाम / dnssec / rollrec को पुन: व्यवस्थित करने की आवश्यकता होती है। यानी कुछ इस तरह:

 rollinit -zonefile /var/named/auto/ru/w/e/b/n/webnames.ru.signed -keyrec /var/named/dnssec/ru/w/e/b/n/webnames.ru/webnames.ru.krf -admin dnssec@localhost webnames.ru >> /var/named/dnssec/rollrec 

स्क्रिप्ट / etc / mail / smrsh / dnssec का कोई मतलब नहीं है, इसलिए हम कार्यक्षमता के बिना अपने आप को बैश पर एक आवरण के लिए प्रतिबंधित करते हैं।
पत्र ही कुछ इस तरह दिखता है:

 From: root To: dnssec@localhost Subject: assistance needed with KSK rollover of zone webnames.ru The zone "webnames.ru" is in the middle of KSK rollover. In order for rollover to continue, its keyset must be transferred to its parent. 

उदाहरण के लिए, आप इसे पार्स कर सकते हैं:

 #!/bin/bash while read L; do if [ "${L:0:9}" == "Subject: " ]; then for W in $L ; do echo -n '' ; done echo "Domain $W" fi done 

यानी सब्जेक्ट फील्ड को शब्दों के अनुसार पार्स करने के बाद, हमें डोमेन नेम (डब्ल्यू वेरिएबल में) मिलता है, जिसके लिए हमें अपडेटेड डीएस एंट्रीज को रजिस्ट्री में भेजना होगा।

अब हम अंतिम DNSSEC घटक - रिज़ॉल्वर को कॉन्फ़िगर करेंगे, जो एक कैशिंग DNS सर्वर भी है। और यहाँ सब कुछ बहुत सरल भी है। यदि हम समान bind9 लेते हैं, तो उसी फ़ाइल /etc/bind/onym.conf.options में आपको समान विकल्प जोड़ने और बाइंड को पुनः लोड करने की आवश्यकता है:

 dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; 

/etc/init.d/bind9 पुनरारंभ करें

अब एक कामकाजी कंप्यूटर पर आपको हमारी रिज़ॉल्वर को DNS सर्वर के रूप में पंजीकृत करना होगा और DNSSEC का आनंद लेना होगा।

वह सब है।