DNS म्हणजे काय? VPS मालकांसाठी मार्गदर्शक

DNS म्हणजे काय आणि तुमचे domain अद्याप VPS पर्यंत का पोहोचत नाही

DNS (domain name system) example.com सारख्या नावाचे रूपांतर 203.0.113.10 सारख्या IP (internet protocol) address मध्ये करते. Browser नावाशी connect होऊ शकत नाही. तो address शी connect होतो. त्यामुळे प्रत्येक page load ची सुरुवात DNS question आणि answer ने होते. तुम्ही नुकतेच domain आणि तुमचा स्वतःचा VPS घेतला असेल आणि काहीही load होत नसेल, तर दोनपैकी एक कारण असते: नावाला तुमच्या server च्या address शी जोडणारा record अद्याप नाही, किंवा असा record आहे पण मार्गातील काही घटक अजूनही जुना answer देत आहेत.

दोन्ही परिस्थिती सामान्य आहेत. यापैकी कोणत्याही परिस्थितीचा अर्थ काहीतरी बिघडले आहे असा होत नाही. खालील sections तुम्हाला आवश्यक क्रमाने हे भाग समजावतात. सर्वाधिक वेळ वाया घालवणाऱ्या मुद्द्यापासून सुरुवात होते: तुमचे records प्रत्यक्षात कोणत्या control panel मध्ये आहेत.

येथील प्रत्येक तपासणीमध्ये dig वापरले आहे. नवीन Ubuntu किंवा Debian machine वर ते default ने installed नसते.

sudo apt update && sudo apt install -y bind9-dnsutils

रजिस्ट्रार, नेमसर्व्हर, DNS host: यापैकी कोणते संपादित करायचे

ही तीन नावे वेगवेगळी कामे दर्शवतात. त्यांची गल्लत होणे हे केलेला बदल लागू न होण्याचे सर्वात सामान्य कारण आहे.

• registrar म्हणजे तुम्ही domain ज्या कंपनीकडून विकत घेतले ती कंपनी. त्याचे महत्त्वाचे काम delegation करणे आहे: तुमच्या TLD (top-level domain, म्हणजे .com भाग) साठी चालणाऱ्या registry ला तुमच्या domain साठी कोणते nameservers authoritative आहेत हे ते सांगते.
• authoritative nameservers तुमच्या zone मधील वास्तविक records ठेवतात. Zone म्हणजे तुमचा domain आणि त्याखालील names.
• DNS host म्हणजे त्या nameservers चे संचालन करणारा. तो registrar, स्वतंत्र provider किंवा तुमच्या मालकीच्या server वर चालणारे bind9 असू शकते.

खरेदी registrar कडे करा. बदल DNS host कडे करा. तुम्ही तुमचा domain दुसऱ्या provider च्या nameservers वर हलवला असल्यास, registrar च्या स्वतःच्या DNS panel मध्ये zone दिसत राहते आणि तुमचे बदल जतनही होतात; परंतु इंटरनेटवरील कोणीही त्या zone ला विचारत नाही. Records वास्तविक असतात. त्यांचा कधीही संदर्भ घेतला जात नाही.

जग कोणाकडे विचारणा करत आहे ते शोधा:

dig example.com NS +short
dig +trace example.com

पहिली command सध्या domain साठी उत्तर देणारे nameservers दाखवते. दुसरी command root servers पासून सुरू होऊन संपूर्ण chain तपासते आणि TLD servers देत असलेले referral दाखवते. हेच delegation तुमचा registrar नियंत्रित करतो. त्या nameservers ची नावे तुम्हाला अपरिचित provider ची असल्यास, तुम्हाला आवश्यक असलेले panel त्या provider कडे आहे.

एका lookup चा प्रवास

यामध्ये चार पक्ष सहभागी असतात. प्रत्येक पक्षाला त्याने शिकलेल्या माहितीची एक प्रत ठेवता येते.

1. तुमच्या मशीनवरील stub resolver. तो स्वतः शोध घेत नाही. तो कॉन्फिगर केलेल्या एका सर्व्हरला विचारतो आणि मिळालेल्या उत्तरावर विश्वास ठेवतो. Ubuntu वर, /etc/resolv.conf ही साधारणपणे /run/systemd/resolve/stub-resolv.conf ची symbolic link असते आणि ती 127.0.0.53 ला दर्शवते. 127.0.0.53 म्हणजे स्वतःच्या cache सह स्थानिक पातळीवर चालणारे systemd-resolved होय.
2. recursive resolver. हा तुमच्या ISP (internet service provider) कडून चालवला जाणारा resolver असतो. तो 1.1.1.1 सारखा public resolver किंवा तुम्ही स्वतः चालवलेला resolverही असू शकतो. उत्तर शोधण्याचे प्रत्यक्ष काम तो करतो.
3. root आणि TLD servers. Recursive resolver root server ला विचारतो. Root server ला तुमचा address माहीत नसतो; तो मात्र .com servers कडे निर्देश करतो. ते servers पुढे तुमच्या nameservers कडे निर्देश करतात.
4. authoritative nameserver. तो कोणालाही विचारत नाही. तो तुमच्या zone मधून उत्तर देतो आणि त्या उत्तराला authoritative म्हणून चिन्हांकित करतो.

dig +trace example.com ही प्रक्रिया तुम्हाला दाखवते. ते स्वतः root पासून सुरुवात करते आणि cache ला विचारण्याऐवजी प्रत्येक referral छापते. Delegation आणि zone यांच्यात सुसंगती आहे का हे पाहण्याचा हा सर्वात जलद मार्ग आहे.

सर्व्हर चालवताना महत्त्वाच्या ठरणाऱ्या DNS नोंदी

• A: नावाचा IPv4 पत्त्याशी संबंध. example.com. A 203.0.113.10. ही नोंद तुमच्या domain ला VPS कडे निर्देशित करते.
• AAAA: नावाचा IPv6 पत्त्याशी संबंध, उदाहरणार्थ 2001:db8::10. तुमची सेवा त्या पत्त्यावर प्रत्यक्ष listening करत असेल, तेव्हाच ही नोंद प्रकाशित करा. IPv6 network वरील clients प्रथम AAAA उत्तर वापरून पाहतात. त्यामुळे कोणतीही सेवा listening करत नसलेल्या पत्त्यामुळे प्रत्येक भेटीत विलंब होतो.
• CNAME: एका नावाचा दुसऱ्या नावासाठी alias. www.example.com. CNAME example.com. मुळे www ला भेट देणारे visitors bare domain ज्या पत्त्यावर resolve होते, तिथे पाठवले जातात. Apex वर (bare example.com वर) CNAME ठेवता येत नाही. कारण apex वर स्वतःचे SOA (start of authority) आणि NS records असणे आवश्यक असते, आणि CNAME चे नाव इतर कोणत्याही record सोबत समान असू शकत नाही. Providers ALIAS, ANAME किंवा CNAME flattening अशा नावांनी पर्याय उपलब्ध करून देतात.
• MX: domain साठी mail कुठे deliver करायचा ते सांगते. यात hostname आणि preference number असतो. कमी number असलेली नोंद आधी वापरून पाहिली जाते. MX ने अशा नावाकडे निर्देश केले पाहिजे ज्यासाठी address record उपलब्ध आहे. CNAME कडे निर्देश करणे invalid आहे आणि काही sending servers ते reject करतात.
• TXT: proof आणि policy साठी वापरला जाणारा free text. Mail authentication records (SPF, DKIM, DMARC) येथे असतात. Wildcard certificate जारी करणारा ACME (automatic certificate management environment) token देखील येथे असतो.
• NS: zone साठी कोणते nameservers सेवा देतात ते सांगते. जगाने कुठे query करावी हे ठरवणारी प्रत parent zone मध्ये असते. ती तुमच्या registrar च्या delegation मधून येते; तुमच्या स्वतःच्या zone मधील प्रतीमधून नाही.

Record types पेक्षा दोन तपशील अधिक गोंधळ निर्माण करतात. Dot ने संपणारे नाव absolute असते. त्यामुळे www.example.com. याचा अर्थ नेमका तोच असतो आणि त्यापेक्षा अधिक काही नाही. बहुतेक panels relative name अपेक्षित धरतात आणि तुमच्यासाठी domain जोडतात. त्यामुळे name box मध्ये www.example.com टाइप केल्यास www.example.com.example.com तयार होते, जे कोणासाठीही resolve होत नाही. दुसरा तपशील @ हा आहे. जवळजवळ प्रत्येक panel मध्ये याचा अर्थ apex असा होतो: कोणताही subdomain नसलेले, स्वतःचे domain.

VPS कडे A record निर्देशित करा

प्रथम इंटरनेटला तुमच्या सर्व्हरचा दिसणारा पत्ता मिळवा:

curl -4 https://ifconfig.me
ip -brief -4 address show

त्यानंतर तुमच्या DNS host वर एक record तयार करा: type A, name @, value म्हणून तो पत्ता आणि TTL (time to live) 300 ठेवा. www साठी दुसरा record जोडा. त्यासाठी त्याच पत्त्यासह आणखी एक A किंवा apex कडे निर्देश करणारा CNAME वापरा.

आता तो पत्ता योग्य प्रकारे resolve होतो का ते तपासा. शक्य असल्यास ही चाचणी सर्व्हरवरून नव्हे, तर तुमच्या laptop वरून करा:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

पहिली command cache सहित तुमच्या मशीनचा नेहमीचा मार्ग वापरते. दुसरी command तुमचा स्थानिक cache वगळून public recursive resolver ला विचारते. तिसरी command authoritative nameserver ला थेट विचारते. त्यामुळे तिचे उत्तर मार्गातील कोणत्याही cache शिवाय सध्याचे सत्य दर्शवते. तिसरी command तुमचा पत्ता परत करते आणि पहिली करत नाही, तेव्हा तुमची DNS configuration योग्य आहे. जुन्या उत्तराची cached प्रत संपेपर्यंत प्रतीक्षा करावी लागेल.

नावाचे resolving लोड होत नाही

नाव resolve होणे हे DNS कार्यरत असल्याचे सिद्ध करते. त्यावरून तुमचा web server कार्यरत आहे असे सिद्ध होत नाही. dig योग्य address परत करताच connection तपासा:

curl -I http://example.com

curl: (6) Could not resolve host: example.com ही DNS समस्या आहे. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused ही DNS समस्या नाही: नाव resolve झाले आणि packet पोहोचले. त्यामुळे समस्या अशी आहे की त्या port वर काहीही listening करत नव्हते. एखादी request बराच वेळ थांबून शेवटी timeout होत असेल, तर firewall ने packet नाकारण्याऐवजी तो शांतपणे drop केला असण्याची शक्यता असते. येथे DNS चा संबंध संपतो आणि ports आणि listening sockets तसेच तुमच्या VPS वरील ufw firewall rules यांची तपासणी आवश्यक ठरते. Connection पूर्ण झाल्यानंतर page load चा उर्वरित भाग म्हणजे HTTP चे कार्य.

ब्राउझरमध्ये अजूनही जुना host का दिसतो

काहीही आपोआप प्रसारित होत नाही. तुम्ही केलेला बदल कोणताही सर्व्हर इतरांपर्यंत स्वतःहून पाठवत नाही. तुम्ही नवीन मूल्य save करताच authoritative nameserver ते धारण करतो. मागील उत्तराच्या प्रत्येक cached copy ची वैधता तिचा स्वतःचा timer संपेपर्यंत राहते. हा timer म्हणजे TTL. रेकॉर्ड वितरित करताना त्याच्यासोबत दिलेला हा कालावधी seconds मध्ये असतो.

अपेक्षेपेक्षा अधिक ठिकाणी copies साठलेल्या असतात: browser चा स्वतःचा short cache, मशीनवरील stub resolver, त्या network कडून वापरला जाणारा recursive resolver आणि client वर VPN ने स्थापित केलेला कोणताही resolver. प्रत्येक copy मिळालेल्या TTL पर्यंत, म्हणजे जास्तीत जास्त त्या कालावधीसाठी, टिकते. दोन networks वरील दोन व्यक्तींना अनेक तास दोन वेगवेगळी उत्तरे दिसू शकतात. दोन्ही machines योग्य प्रकारे काम करत असतात.

Caching resolver कडे असलेला countdown पाहण्यासाठी:

dig @1.1.1.1 example.com +noall +answer

हे काही seconds च्या अंतराने दोनदा चालवा. उत्तरातील TTL कमी होत जातो. तो zero वर पोहोचल्यावर resolver रेकॉर्ड टाकून देतो आणि तुमच्या nameserver कडे पुन्हा विचारणा करतो.

जवळजवळ कोणीही लक्षात घेत नाही असा दुसरा cache देखील असतो: negative answers. एखादे name अस्तित्वात नाही असे resolver ला सांगितल्यावर तो NXDOMAIN देखील cache करतो. तुमच्या zone च्या SOA record मधील शेवटच्या field ने ठरवलेल्या कालावधीपर्यंत तो cache राहतो.

dig example.com SOA +short

त्या line वरील शेवटची संख्या negative TTL असते. ती अनेकदा 3600 असते. त्यामुळे staging.example.com तयार करण्यापूर्वी त्याची lookup केल्यास, ते तयार केल्यानंतर पूर्ण तासभर record तुम्हाला दिसणार नाही. आधी record तयार करा आणि त्यानंतर query करा.

Nameservers बदलणे हे record बदलण्यापेक्षा धीमे असते. याचे कारण तांत्रिक आहे. .com zone मधील delegation records 172800 seconds या TTL सह वितरित केले जातात. हा कालावधी दोन days इतका आहे. त्यामुळे तुमचे जुने nameservers cache केलेला resolver त्या कालावधीपर्यंत त्यांनाच विचारणा करू शकतो. “allow up to 48 hours” हा सल्ला याच कारणामुळे दिला जातो. तो nameserver changes साठी लागू होतो; सामान्य record edits साठी नाही.

TTL शी संघर्ष करण्याऐवजी त्यानुसार migration चे नियोजन करा:

1. Record चा TTL 300 पर्यंत कमी करून तो save करा.
2. जुन्या TTL पेक्षा जास्त वेळ थांबा, जेणेकरून जुने मूल्य असलेल्या सर्व cached copies ची वैधता संपेल.
3. Address बदला.
4. Traffic नवीन ठिकाणी गेल्यावर TTL पुन्हा 3600 किंवा त्याहून अधिक करा. कमी TTL असल्यास प्रत्येक resolver तुमच्या nameservers कडे अधिक वारंवार विचारणा करतो.

तुमच्या स्वतःच्या machine वर साठलेली माहिती काढण्यासाठी:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics hit आणि miss counters असलेला cache section दाखवते. त्यामुळे flush केल्यानंतरची पुढील lookup miss म्हणून दिसते. Browsers स्वतंत्र cache ठेवतात. म्हणून system cache रिकामा झाल्यानंतरही Chrome जुने उत्तर वापरू शकतो. तो cache chrome://net-internals/#dns येथे clear करा. /etc/hosts देखील तपासा. तेथे उरलेली line त्या machine वर DNS पेक्षा प्राधान्य घेते आणि फक्त त्याच machine वर परिणाम करते. getent hosts example.com system प्रत्यक्षात वापरणार असलेले उत्तर दाखवते; त्यात /etc/hosts देखील समाविष्ट आहे.

Wildcard प्रमाणपत्र TXT record द्वारे सिद्ध केले जातात

CA (certificate authority) प्रमाणपत्र जारी करण्यापूर्वी नावावरील नियंत्रण तपासते. HTTP-01 challenge मध्ये त्या अचूक hostname वर port 80 द्वारे एक file उपलब्ध करून दिली जाते. एका नावासाठी ही पद्धत योग्य आहे. Wildcard प्रमाणपत्र *.example.com व्यापते. हा hostnames चा अमर्याद संच आहे आणि CA त्यातून file fetch करू शकत नाही. त्यामुळे Let's Encrypt wildcard प्रमाणपत्रे केवळ DNS-01 challenge द्वारे जारी करते. तुम्ही _acme-challenge.example.com येथे CA ने दिलेला token असलेला TXT record प्रकाशित करता. Zone वरील नियंत्रण हाच त्याचा पुरावा असतो.

यामुळे तुमचा DNS host प्रमाणपत्र renewal प्रक्रियेचा भाग बनतो. प्रत्येक renewal वेळी Certbot ने तुमच्याशिवाय हा TXT record तयार करून हटवला पाहिजे. त्यामुळे तुमच्या provider साठी API आणि त्याच्याशी जुळणारा plugin आवश्यक असतो. Validation अयशस्वी झाल्यावर नेहमीचा संदेश DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com असा असतो. याचा अर्थ CA ने record दिसण्यापूर्वी तपासणी केली. Record कधीच जतन झाला नसू शकतो किंवा negative answer अजून cache मध्ये असू शकतो. संपूर्ण प्रक्रिया DNS-01 challenge वापरून wildcard प्रमाणपत्रांसाठीच्या मार्गदर्शकात दिली आहे.

VPN ने resolver चा ताबा घेतल्यावर

VPN (virtual private network) client कनेक्ट असताना सामान्यतः system resolver बदलतो. कारण lookup स्थानिक network कडे पाठवल्यास तुम्ही भेट देत असलेल्या प्रत्येक site चे नाव त्या network ला समजू शकते. हे अपेक्षित वर्तन आहे. मात्र, यात दोन प्रकारे अडचण येऊ शकते.

Tunnel सुरू झाल्यानंतर names resolve होणे थांबले, पण addresses अद्याप काम करत असतील, तर client ने स्थापित केलेला resolver tunnel च्या आतून पोहोचण्याजोगा नाही. ping 1.1.1.1 यशस्वी होते आणि curl https://example.com curl: (6) Could not resolve host: example.com परत करते. याउलट, tunnel सुरू झाल्यानंतरही lookups तुम्ही जोडलेल्या network कडेच जात असतील, तर तुमचा traffic tunnel मधून जात असतो; मात्र local resolver तुम्ही विचारत असलेले प्रत्येक name पाहत राहतो.

resolvectl status

यामुळे प्रत्येक link साठी वापरात असलेला resolver दिसतो. त्यामुळे tunnel ने कोणता resolver स्थापित केला आणि तो अपेक्षित resolver आहे का, हे तपासता येते. WireGuard tunnel client config मधील DNS = line मधून ही setting घेतो. WireGuard ने resolver चा ताबा घेतल्यावर DNS दुरुस्त करण्यासाठी WireGuard ने resolver चा ताबा घेतल्यावर DNS दुरुस्त करणे या भागात systemd-resolved आणि resolvconf प्रकरणांचे सविस्तर वर्णन आहे.

प्रत्येक reply code काय सांगतो

• NXDOMAIN: authoritative server सांगतो की हे नाव अस्तित्वात नाही. Spelling तपासा, domain suffix दोनदा जोडला आहे का ते तपासा आणि delegation ज्या zone कडे निर्देश करते तीच zone तुम्ही संपादित केली आहे का ते तपासा.
• NOERROR आणि रिकामा ANSWER SECTION: हे नाव अस्तित्वात आहे, परंतु तुम्ही विचारलेल्या प्रकारचा record त्यात नाही. फक्त A असताना AAAA साठी विचारणा केल्यास नेमके हेच दिसते.
• SERVFAIL: resolver ने प्रयत्न केला, पण तो answer तयार करू शकला नाही. याची दोन सामान्य कारणे आहेत: authoritative servers कडून कोणतेही reply न मिळणे आणि DNSSEC (domain name system security extensions) validation अयशस्वी होणे. Validation बंद करणाऱ्या dig @1.1.1.1 example.com A +cd ने चाचणी करा. त्याशिवाय +cd आणि SERVFAIL सह answer मिळाल्यास समस्या signatures मध्ये आहे. nameserver बदलल्यानंतर parent कडे जुना DS (delegation signer) record प्रकाशित राहिल्यास असे होते.
• REFUSED: तुम्ही विचारलेल्या server कडून त्या प्रश्नाचे उत्तर दिले जाणार नाही. साधारणपणे तुम्ही dig अशा domain साठी authoritative server कडे निर्देशित केलेले असते, जो तो domain serve करत नाही.
• ;; connection timed out; no servers could be reached: dig कोणत्याही resolver पर्यंत पोहोचले नाही. ही तुमच्या बाजूची network किंवा resolver समस्या आहे. त्यामुळे domain हे समस्येचे कारण नाही.

ping: example.com: Temporary failure in name resolution हा dig ऐवजी glibc कडून नोंदवला जाणारा याच प्रकारचा failure आहे.

तुमच्या स्वतःच्या VPS वर nameserver चालवावे का?

तुम्ही तसे करू शकता. bind9, knot किंवा nsd तुमचा zone सर्व्हरवरून serve करतील आणि कोणत्याही panel पेक्षा DNS विषयी तुम्हाला अधिक शिकवतील. मात्र, यामध्ये व्यावहारिक अडचणी आहेत. Domain साठी स्वतंत्र networks वर किमान दोन nameserver असावेत. त्यामुळे एकच VPS domain वरील प्रत्येक सेवेसाठी, mail सहित, एकमेव failure point ठरतो. ज्या domain साठी nameserver सेवा देतात, त्याच domain मध्ये त्यांची नावे असल्यास registrar कडे glue records आवश्यक असतात. Parent zone मध्ये साठवलेला ns1.example.com चा address हा त्या glue record मध्ये असतो. अन्यथा lookup सुरू करण्याचा कोणताही मार्ग राहत नाही. Resolver तुमच्या nameserver पर्यंत पोहोचू शकत नसेल, तर तो तुमच्या website कडे fallback करत नाही. त्या वापरकर्त्यासाठी संपूर्ण domain अदृश्य होतो. API असलेली hosted DNS सेवा बहुतेक लोकांसाठी कमी-जोखमीची निवड आहे. तुमच्या स्वतःच्या machines साठी VPS वर caching resolver चालवणे हे वेगळे काम आहे आणि त्यासाठीची बांधिलकीही खूप कमी आहे.

FAQ

माझ्या DNS बदलाचा अद्याप प्रसार का झालेला नाही?

काहीही प्रसारित होत नाही. तुम्ही बदल जतन करताच authoritative nameservers कडे नवीन मूल्य उपलब्ध होते. आधीच विनंती केलेला प्रत्येक resolver त्याला मिळालेली cached प्रत TTL संपेपर्यंत वापरतो. dig @ns1.your-dns-host.net example.com A +short वापरून authoritative server ला थेट विचारा. त्यातून नवीन address मिळाल्यास बदल लागू झाला आहे आणि उरलेली बाब caching ची आहे. तुम्ही records ऐवजी nameservers बदलले असल्यास, यासाठी अधिक वेळ लागेल. कारण TLD delegations दोन दिवसांच्या TTL सह वितरित केल्या जातात.

माझे domain प्रत्यक्षात कोणते nameservers वापरते हे कसे शोधू?

dig example.com NS +short सध्या त्या domain साठी उत्तर देणारे nameservers दाखवते. dig +trace example.com root पासूनची referral chain दाखवते. त्यात TLD servers कडून दिलेली delegation देखील असते. ही नावे तुम्ही ज्या provider च्या panel मध्ये बदल करत आहात त्या provider ची नसल्यास, हीच समस्या आहे. delegation मध्ये नमूद केलेल्या provider कडे records संपादित करा. किंवा तुमच्या registrar कडील delegation बदलून ती तुम्हाला हव्या असलेल्या ठिकाणी निर्देशित करा.

माझे domain resolve होते, पण site अजूनही load होत नाही. आता काय करावे?

dig example.com A +short तुमच्या server चा address परत करते तेव्हा DNS संबंधी काम पूर्ण झालेले असते. त्यानंतरची समस्या connection ची असते. curl -I http://example.com ने Connection refused परत केल्यास त्या port वर काहीही listening नसते. एखादी request timeout होईपर्यंत अडकत असल्यास firewall ने packet टाकून दिलेला असतो. तुमचा web server चालू आहे आणि public address वर bound आहे याची खात्री करा. त्यानंतर server वरील firewall आणि provider च्या control panel मधील स्वतंत्र network firewall तपासा.

माझ्या root domain वर CNAME का ठेवता येत नाही?

CNAME एखादे name दुसऱ्या name चे alias असल्याचे दर्शवते. CNAME असलेल्या name सोबत इतर कोणताही record ठेवता येत नाही. Zone अस्तित्वात राहण्यासाठी तुमच्या root domain कडे SOA आणि NS records असणे आवश्यक आहे. त्यामुळे ते CNAME देखील असू शकत नाही. Root वर address असलेला A record वापरा. किंवा ALIAS, ANAME किंवा CNAME flattening या नावाने उपलब्ध असलेले provider feature वापरा. हे feature एक name साठवते आणि त्या name चा सध्या resolve होणारा address उत्तर म्हणून देते.