DNS सीखना अब भी कठिन क्यों है?

 (jvns.ca)
3 पॉइंट द्वारा GN⁺ 2023-07-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • DNS 1980 के दशक से 35 साल से ज्यादा समय से इस्तेमाल हो रहा है और इसकी संरचना भी स्थिर है, फिर भी कई programmers को बुनियादी समस्याओं को आत्मविश्वास से debug करने तक पहुंचने में लंबा समय लगता है
  • कठिनाई DNS की अपनी complexity से ज्यादा resolver cache, local DNS libraries, authoritative nameserver से बातचीत जैसे कई अदृश्य components में है
  • dig शक्तिशाली है, लेकिन इसका output structure और terminology अपरिचित लगते हैं, और +norecurse जैसी सुविधाएं उपयोगी होने पर भी परिणामों की व्याख्या intuitive नहीं होती
  • negative caching, musl में TCP DNS support न होने का पुराना इतिहास, TTL को ignore करने वाले resolvers, nginx की permanent caching, Kubernetes ndots जैसे आम traps तब तक सीखना मुश्किल है जब तक कोई इनके बारे में न बताए
  • जो लोग DNS से कम ही काम करते हैं, उनके लिए cheatsheet मददगार होती है, और जिन समस्याओं पर experiment करना जोखिम भरा लगता है, उन्हें Mess With DNS जैसे सुरक्षित experiment environment से आसान बनाया जा सकता है

पुरानी technology होने के बावजूद कठिन DNS

  • DNS RFC 1034 के समय से 35 साल से अधिक समय से इस्तेमाल हो रहा है, internet की हर website में इस्तेमाल होता है, और कई मायनों में 30 साल पहले जैसा ही काम करता है
  • फिर भी “domain सही तरह से set किया है, लेकिन resolve नहीं हो रहा” या “dig और browser के DNS results अलग हैं” जैसी बुनियादी समस्याओं को debug करने में काफी समय लग सकता है
  • DNS को कठिन मानने वाले लोग आम तौर पर इन जगहों पर अटकते हैं
    • website में simple DNS change करने में भी सहज महसूस नहीं करते
    • यह बात confuse करती है कि DNS records push नहीं किए जाते, बल्कि pull किए जाते हैं
    • basic concepts पता होने पर भी negative caching, dig और browser की DNS query के फर्क जैसे detailed behavior में confusion होता है

अदृश्य resolver और nameserver

  • computer से DNS request भेजते समय basic flow सरल दिखता है
    • computer resolver नाम के server से request करता है
    • resolver cache check करता है, और जरूरत पड़ने पर authoritative nameserver से फिर request करता है
  • वास्तविक debugging में महत्वपूर्ण कई चीजें default रूप से दिखाई नहीं देतीं
    • resolver के cache में क्या है, यह जानना कठिन होता है
    • local पर कौन-सी DNS library request handle कर रही है, यह स्पष्ट नहीं होता
      • libc getaddrinfo, glibc, musl, Apple implementation, browser का अपना DNS code, अलग custom implementation आदि हो सकते हैं
      • हर implementation में settings, caching method, feature support थोड़ा अलग होता है
      • musl DNS ने 2023 की शुरुआत तक TCP support नहीं किया था
    • resolver और authoritative nameserver के बीच की बातचीत दिखाई नहीं देती
      • अगर यह trace किया जा सके कि किस authoritative nameserver से query की गई और उसने क्या response दिया, तो कई DNS समस्याएं ज्यादा आसानी से समझी जा सकती हैं

छिपे हुए systems को सामने लाने वाला approach

  • सिर्फ यह बताना भी सीखने में बहुत मदद करता है कि छिपे हुए components कौन-से हैं
    • अगर यह नहीं पता कि एक ही computer में स्थिति के हिसाब से कई DNS libraries इस्तेमाल हो सकती हैं, तो लंबे समय तक confusion बना रह सकता है
  • Mess With DNS आम तौर पर दिखाई न देने वाले हिस्सों को दिखाने के लिए fishbowl style का experiment करने की कोशिश करता है
    • यह resolver और authoritative nameserver के बीच की बातचीत का कुछ हिस्सा देखने देता है
  • DNS responses में debugging information डालने का तरीका भी है
    • Extended DNS Errors या EDE नाम का feature पहले से मौजूद है
    • tools धीरे-धीरे EDE support जोड़ रहे हैं

Extended DNS Errors से मिलने वाले clues

  • Extended DNS Errors एक नया तरीका है जिससे DNS server response में अतिरिक्त debugging information दे सकता है
  • अगर non-existent domain xjwudh.com को dig @8.8.8.8 xjwudh.com से query करें, तो ऐसा additional error आ सकता है
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
  • यह example DNSSEC से जुड़ा item लगता है, और महत्वपूर्ण बात यह है कि response के अंदर additional debug message साथ आता है
  • ऊपर वाला example देखने के लिए dig का ज्यादा नया version चाहिए था

शक्तिशाली लेकिन पढ़ने में कठिन dig

  • DNS की internal state check करने के लिए dig उपयोगी है
  • dig +norecurse इस्तेमाल करके देखा जा सकता है कि किसी खास DNS resolver के cache में कौन-से records हैं
    • 8.8.8.8 response cache में न होने पर SERVFAIL return करता हुआ लगता है
    • google.com cache में था, इसलिए NOERROR और A record return हुआ
    • homestarrunner.com cache में नहीं था, इसलिए SERVFAIL return हुआ, लेकिन इसका मतलब यह नहीं कि DNS record मौजूद नहीं है
  • dig output की आदत न हो तो इसे पढ़ना कठिन है
    • ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: जैसे titles अपरिचित लगते हैं
    • sections के बीच line breaks और spacing consistent नहीं लगती
    • MSG SIZE rcvd: 47 में rcvd के अलावा कोई और field है या नहीं, यह जानना मुश्किल है
    • ADDITIONAL section में 1 record होने की बात कही जाती है, जबकि असल में OPT PSEUDOSECTION वही role निभाता है—यह जानना पड़ता है
  • dig output शुरू से जानबूझकर design किया गया format होने के बजाय समय के साथ organically बढ़ी हुई script जैसा लगता है

DNS tools को ज्यादा readable बनाने के तरीके

  • dig output को समझाने वाली documentation मददगार होती है
    • how to use dig dig output structure और default output को छोटा set करने का तरीका समझाता है
  • ज्यादा friendly tools भी बनाए जा सकते हैं
    • dog, doggo, DNS lookup tool जैसे alternatives हैं
    • हालांकि +norecurse जैसी advanced feature की जरूरत होने पर सिर्फ dig से काम करना बेहतर हो सकता है
    • dig की व्यापक feature range को replace करना बड़ा काम है
  • dig output में +human जैसा option जोड़कर वही information ज्यादा structured तरीके से दिखाना भी संभव है
    • header, query, response, additional section, time, server, protocol, response size को साफ-साफ अलग किया जा सकता है
    • यह information की मात्रा घटाने का नहीं, बल्कि उसी information को ज्यादा readable तरीके से present करने का approach है
  • नए dig में +yaml output format है
    • यह ज्यादा स्पष्ट लग सकता है, लेकिन simple DNS response भी इतना लंबा हो सकता है कि screen में पूरा न आए

अक्सर सामने आने वाले लेकिन सीखने में कठिन DNS traps

  • DNS में कुछ traps ऐसे हैं जो अपेक्षाकृत अक्सर सामने आते हैं, लेकिन जब तक कोई बताए नहीं, उन्हें जानना मुश्किल है

  • negative caching

    • अगर किसी ऐसे domain पर जाएं जिसके लिए अभी DNS record नहीं है, तो उस record की “मौजूद नहीं” वाली state cache हो सकती है
    • अगर यह state कई घंटों तक cache हो जाए, तो यह बहुत परेशानी पैदा करता है

  • getaddrinfo implementations में फर्क

  • TTL ignore करने वाले resolver

    • DNS record TTL को 5 मिनट set करने पर भी कुछ resolvers उसे ignore करके 24 घंटे जैसी ज्यादा लंबी अवधि तक cache कर सकते हैं

  • nginx configuration problem

    • nginx गलत configure होने पर DNS records को हमेशा के लिए cache कर सकता है

  • Kubernetes ndots

    • ndots Kubernetes DNS को धीमा बना सकता है

traps को share और document करने का तरीका

  • अजीब traps के बारे में knowledge पाना कठिन है, और लोगों को वही समस्याएं बार-बार दोबारा discover करनी पड़ें, यह inefficient है
  • किसी topic को समझाते समय common traps को साथ में बताना बहुत मददगार होता है
    • DNS के अलावा उदाहरण के तौर पर, Josh Comeau का Flexbox introduction minimum size gotcha समझाता है
  • community द्वारा common traps को एक जगह इकट्ठा करना भी उपयोगी है
    • Bash में shellcheck bash traps के collection के रूप में बहुत उपयोगी है
  • DNS traps को document करना इसलिए भी कठिन है क्योंकि हर user को अलग तरह की समस्याएं मिलती हैं
    • जो व्यक्ति 3 साल में एक बार personal domain DNS set करता है और जो व्यक्ति high-traffic domain का DNS operate करता है, वे अलग-अलग traps का सामना कर सकते हैं

कम इस्तेमाल और experiment की कठिनाई

  • कई लोग DNS से बहुत कम काम करते हैं
    • अगर आप 3 साल में सिर्फ एक बार DNS छूते हैं, तो इसे सीखना कठिन होना स्वाभाविक है
    • “nameserver change procedure” जैसी cheatsheet मदद कर सकती है
  • DNS ऐसी technology भी है जिस पर experiment करने से लोग डरते हैं, क्योंकि इससे उनका अपना domain टूट सकता है
    • Mess With DNS इसी experiment burden को कम करने के लिए बनाया गया था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-07-29
Hacker News की राय

  • मैं इस लेख से सहमत नहीं हूँ। मुझे लगता है कि DNS को सीखने में समय लगाने वाले लोग कम हैं; असल में इसे सीखना मुश्किल नहीं है।
    DNS की अच्छी बात यह है कि किसी query के जवाब में सिस्टम अपनी internal state बता देता है। किसी ज्ञात zone के लिए DNS server को देखना और उसका व्यवहार समझना आसान है, और dig जैसे free tools भी व्यापक रूप से उपलब्ध हैं।
    अपने पूरे करियर में जिन लोगों के साथ काम किया, वे हमेशा मेरे DNS ज्ञान को सबसे ज़्यादा याद रखते हैं—यह मुझे चौंकाता था, क्योंकि मुझे नहीं लगता कि मैं कोई रहस्यमय या खास चीज़ जानता हूँ। DNS बहुत अच्छी तरह standardized है, आम server और client implementations भी standard का सख्ती से पालन करते हैं, और free tools से इसे observe करना भी आसान है। बस मेहनत और समय चाहिए; यह सचमुच मुश्किल नहीं है।

    • इस लेख के लेखक के तौर पर, DNS सच में मुश्किल नहीं है वाले नज़रिए पर मैं कुछ बातें कहना चाहता हूँ। DNS समस्याओं को पूरी सहजता से debug कर पाने में मुझे कई साल लगे, और यह लेख मैंने यह समझाने के लिए लिखा कि यह मेरे लिए कठिन क्यों था।
      पहले मुझे लगता था कि “नहीं, असल में यह आसान है!” कहना “इसे सीखना मुश्किल है” के जवाब में एक तरह का प्रोत्साहन है। मुझे DNS पसंद है, और कई मायनों में यह आश्चर्यजनक रूप से सरल भी लगता है। उदाहरण के लिए https://implement-dns.wizardzines.com में simple Python code से scratch से एक toy DNS resolver implement करने का तरीका दिखाया गया है।
      लेकिन समय के साथ मैंने सीखा कि “नहीं, इसे सीखना आसान है!” अक्सर “आप कर सकते हैं!” जैसे प्रोत्साहन से ज़्यादा “यह मुश्किल नहीं है, तुम ही बेवकूफ हो” जैसा सुनाई देता है। जिस विषय पर मैं कई सालों तक confused रहा, उसके बारे में “दरअसल यह तो आसान है” सुनना ज़्यादा मददगार नहीं होता।
      इसलिए अब मैं ऐसा नहीं कहता, और यह समझने में बहुत मेहनत लगाता हूँ कि लोगों को कोई खास चीज़ मुश्किल क्यों लगती है और उन बाधाओं को कैसे कम किया जाए।
    • DNS सीखने के tools के लिहाज़ से देखें तो मुझे लगता है कि इसे सीखना मुश्किल है।
      BIND अपना काम शानदार करता है, लेकिन इसकी config files अच्छी नहीं हैं, manual लंबा और रूखा है, और कभी-कभी बेवजह जटिल है। dig powerful है, लेकिन सब कुछ ऐसे abbreviate करता है जैसे 80-column terminal के दौर का हो। DNS problems debug करते समय कई बार Wireshark, dig से बेहतर tool रहा है।
      PowerDNS या कोई दूसरा modern DNS server इस्तेमाल करवाएँ तो शायद working DNS server set up करना कहीं ज़्यादा आसान हो। कोई अच्छा modern DNS client मुझे ठीक से नहीं पता, इसलिए आखिरकार dig की आदत डाल ली। ip command में --color flag इस्तेमाल करने वाले के तौर पर, मैं चाहूँगा कि dig जैसे tools भी ज़्यादा modern output दें। command-line flags को मैं alias में बाँध लूँगा, बस feature जोड़ दें।
      सच में, MSG SIZE rcvd: 71 को abbreviate करने की कोई ज़रूरत नहीं थी। flags: qr rd ra भी पूरा लिखा जा सकता था। लाइनों की शुरुआत में semicolon क्या बताना चाहता है, यह भी समझ नहीं आता; उल्टा confusion बढ़ाता है।
      दिए गए resources से DNS सीखते हुए लोग confuse हो जाते हैं, इसमें हैरानी की बात नहीं है।
    • आपने “मैं इस लेख से सहमत नहीं हूँ” कहा, लेकिन लगता है कि आपने लेख के तर्क का जवाब लगभग नहीं दिया और सिर्फ title से असहमति जताई। ऊपर से आप DNS मुश्किल है और DNS सीखना मुश्किल है को मिलाकर बोल रहे लगते हैं।
      अगर “बस थोड़ी मेहनत और समय चाहिए”, तो कितनी मेहनत और कितना समय? इस thread में कई लोग कह रहे हैं कि उन्होंने server implement करते हुए सीखा, कुछ महीने लगाकर समझा, और फिर “एक बार समझ आ जाए तो काफी आसान है” दोहराते हैं। तो क्या हम यह मान सकते हैं कि इतनी common और conceptually simple चीज़ के लिए इसे सीखना वास्तव में मुश्किल है?
    • लेख पढ़ें तो बताया गया है कि इसे सीखना मुश्किल क्यों है। concept आसान है, लेकिन concept सिखाते समय modern Internet की सारी details शामिल नहीं की जातीं।
      उदाहरण के लिए browser DNS entries को cache और expire करने के कौन-से rules follow करता है? क्या वे rules हर browser में consistent हैं?
    • मुझे लगता है DNS उन technologies में से है जिनके बारे में आप पूरे करियर में इधर-उधर से टुकड़े उठाकर आगे बढ़ सकते हैं। अगर बहुत-से लोगों को इसे सीधे tackle करना पड़ा होता, तो यह असल से कम complex लगता; लेकिन industry में ऐसी चीज़ों के चारों ओर एक तरह का रहस्य बन जाता है।

  • मुझे लगता है लेख ने core बात सही पकड़ी है। DNS अपने-आप में मुश्किल नहीं है, लेकिन real-world DNS सीखना मुश्किल है। किसी lookup को intend करके expected result पाने तक बीच के बहुत-से हिस्से छिपे रहते हैं।
    पहले default Internet connection model एक interface, एक gateway और एक DNS server provider वाला था। अब LTE और WiFi जैसे कई WAN से एक साथ जुड़े रहना भी आम है, और user के लिए यह जानना मुश्किल है कि असल में कौन-सा resolution path इस्तेमाल हुआ। यह browser था, system C library का standard interface था, बीच का local resolver या recursive resolver था, local cache था या नहीं, या default रूप से कोई special options जोड़े जाते हैं—सब अस्पष्ट रहता है।
    सब कुछ काम कर रहा हो, तब भी आप आँख बंद करके भरोसा नहीं कर सकते कि एक application की query और response ने दूसरे application जैसा ही path लिया। तीन browsers तीन अलग तरीके इस्तेमाल कर सकते हैं, operating system फिर अलग तरह से behave कर सकता है, और mDNS पाँचवाँ विकल्प जोड़ सकता है।

  • Computer Science में एक joke है कि मुश्किल problems सिर्फ तीन हैं: cache invalidation और naming।
    और DNS चीज़ों के नामों के लिए caching system है।
    https://reddit.com/comments/15c2ul2/comment/jtty9dy

    • निष्पक्ष रूप से कहें तो DNS naming को सही ढंग से करने के उदाहरणों में से एक है।
      यह globally managed (IANA), hierarchical, federated है, और इसे modify करना भी आसान है।

  • DNS ऐसी तकनीक है जिसमें यह जितना आसान दिखता है और असल में जितना कठिन निकलता है, उसके बीच असंगति होती है
    हम हर दिन DNS इस्तेमाल करते हैं, और यह बहुत आसान लगता है। रोज़मर्रा की DNS भाषा है domain name, lookup, IP address। यह भाषा browser में सीधे दिखती है, और उसी exposure के आधार पर हम इसके काम करने का mental model बना लेते हैं
    लेकिन अंदर zones, resolvers, delegated authority, top-level domain के बाद आने वाला अजीब-सा dot जैसी बिल्कुल अलग भाषा है

    • उस अजीब dot को root कहते हैं। dot न हो तो name complete नहीं होता, dot हो तो name पूरी तरह defined होता है। यानी context ही सब कुछ है। dot न हो तो resolver अपना domain या उसका कोई हिस्सा बार-बार जोड़ सकता है
      उदाहरण के लिए host.example.co.uk का क्या मतलब है, यह हम दोनों जानते हैं, लेकिन पीछे dot न हो तो resolver host.example.co.uk.example.co.uk lookup करने की कोशिश कर सकता है
      Windows की default settings में ऐसे मामले में host.example.co.uk.example.co, host.example.co.uk.example, फिर host.example.co.uk.example, और host.example.co.uk. कोशिश करके result मिल सकता है। हालांकि मैंने असल में Windows को पहली कोशिश करते नहीं देखा है, और यह behavior शायद इसलिए design किया गया लगता है ताकि DNS बड़े enterprise environments को handle कर सके, जिनमें federation वाला राक्षसी Active Directory होता है
      आजकल browsers user की consent के बिना चुपके से DNS over HTTPS(DoH) server पर जाने और तरह-तरह के संदिग्ध parties से मेलजोल करने की काफी संभावना रखते हैं। DNS lookup basic data है, इसलिए ISP को यह देखना पसंद था कि user कहाँ जा रहा है। Operating system vendors भी बेशक “telemetry” भेज सकते हैं। Google desktop का मालिक नहीं है, लेकिन browser का मालिक है, इसलिए अगर वे user द्वारा set किए गए DNS की जगह “safe” DNS server इस्तेमाल करवाएँ तो यह उनके लिए अच्छा है। इन चालों की वजह से IT troubleshooting पहले से कहीं ज्यादा रोमांचक हो गई है
      पीछे वाले dot की बहुत चिंता करने की जरूरत नहीं है। वैसे भी आप लगभग निश्चित रूप से वह DNS server इस्तेमाल नहीं कर रहे होंगे जिसके बारे में आप सोचते हैं। DoH क्यों बनाया गया, यह समझ आता है, और कुछ आम users के लिए इसे इस्तेमाल करने की वजह भी है। उदाहरण के लिए, अगर कोई non-IT professional किसी malicious WiFi hotspot का इस्तेमाल कर रहा है, तो browser अगर सुरक्षित तरीके से अपने home base पर वापस जाकर DNS lookup करे तो कुछ हद तक सुरक्षा मिलती है। लेकिन browser vendor को user की endpoint security choices को रौंदने की अनुमति होनी चाहिए या नहीं, यह अलग बात है
      DNS सिर्फ address lookup करने से कहीं ज्यादा complex है। आजकल यह पैसे का मामला है, और सच कहें तो लगभग 2000 से हमेशा से ऐसा ही रहा है। अब बहुत-सी बेहद जिद्दी बड़ी कंपनियाँ हैं जो यह तय करना चाहती हैं कि user के जरिए किसे फायदा मिले
    • मेरे हिसाब से कठिन हिस्सा distributed वाला है। individual node के atomic level से ऊपर बहुत भारी black magic चलता है, और वही complexity का बड़ा हिस्सा और opacity का बड़ा हिस्सा पैदा करता है
      DNS खुद आसान है। किसी organization पर निर्भर न रहने वाली information distribution सच में मुश्किल है

  • कुछ साल पहले मुझे एहसास हुआ कि मैं DNS को केवल टुकड़ों-टुकड़ों में समझता हूँ। dig(1), BIND, recursive DNS resolution कैसे काम करता है—इनका CS101 level concept मुझे पता था, लेकिन non-trivial system design/implement करने या न चलने वाले system को debug करने के लिए जरूरी practical knowledge की कमी थी
    इसलिए मैंने “DNS and BIND” लगभग शुरू से अंत तक पढ़ी, और कुछ कम-महत्वपूर्ण personal websites के लिए actual BIND server भी set up किए। यह मुश्किल नहीं था, लेकिन समय का निवेश काफी चाहिए था। BIND बहुत सारे use cases के लिए सही जवाब नहीं है, लेकिन DNS के कई concepts और terms अब भी BIND से आते हैं, इसलिए यह बहुत valuable था
    मुझे लगता है कि ऐसी चीजें सीखने में books को कम आंका जाता है। web पर मिलने वाला material अक्सर high-level theory होता है, जैसे recursive lookup block diagram; या task-oriented material होता है, जैसे dig से recursive lookup कैसे करें; या local DNS client की retry policy समझने के लिए source पढ़ने जैसा low-level material होता है। हर piece और वे एक-दूसरे से कैसे जुड़ते हैं, वे क्या achieve करना चाहते हैं, से लेकर cache कहाँ है जैसी implementation तक समझने के लिए books में आम तौर पर मिलने वाले holistic approach का लगभग कोई substitute नहीं है। web पर बिल्कुल नहीं है ऐसा नहीं, लेकिन rare है

  • हर IT person के पास DNS problem debugging का practical knowledge होना अच्छा है
    DNS historically महत्वपूर्ण security vulnerabilities का रास्ता रहा है, और आगे भी ऐसा रहने की काफी संभावना है। ऐसी vulnerabilities SMTP जैसे लगभग हर दूसरे protocol के attack paths तक ले जाती हैं। HTTPS में इस्तेमाल होने वाला certificate authority system भी मूल रूप से insecure protocol पर बहुत निर्भर करता है। अगर किसी bank ने OV की जगह DV certificate खरीदा हो तो क्या आप notice कर पाएँगे? शायद नहीं
    इसलिए जिन लोगों में interest कम है, उनके लिए DNS का सीखने में कठिन लगना जरूरी नहीं कि बुरा ही हो। क्योंकि आज भी मुझे ऐसे लोग दिखते हैं जो port randomization, cache poisoning, AXFR जैसी चीजों का history ठीक से समझने में समय लगाए बिना DNS-related features बनाते हैं

    • network के किसी भी layer पर routing decisions को broadcast या claim करने वाली हर चीज सतह पर जितनी simple दिखती है, उससे कहीं ज्यादा potentially dangerous लगती है

  • थोड़ी शर्मनाक side-project promotion करूँ तो, लेख में कहा गया था कि DNS resolution में “debug” mode हो तो अच्छा होगा, और ComfyDNS web UI में वह feature है :3
    https://comfydns.com/
    ऊपर TRACE google.com A IN लिखा हुआ जो image है, वही feature है
    ComfyDNS मेरे अपने itch को scratch करने वाला project भी है। bind9 zone files को हाथ से edit करते-करते मैं थक गया था, और यह भी जानना चाहता था कि DNS कैसे काम करता है। surface-level बातें पता थीं, लेकिन details नहीं जानता था, इसलिए RFC को “from scratch” implement किया। netty इस्तेमाल किया, लेकिन DNS library नहीं इस्तेमाल की। काफी मजेदार था
    अगर site traffic झेल न पाए और down हो जाए तो माफ करें। यह Oracle Cloud free tier पर चलने वाला Rails app है

  • हमेशा सुना हुआ joke यह है कि DNS computer science की दो सबसे मुश्किल problems, naming और cache invalidation, को जोड़ देता है

    • DNS में seconds में validity counter होता है, और उन seconds को count करने में काफी loose होना acceptable है
      यह cache invalidation की कठिन वाली किस्म नहीं है। असल में “invalidation” करने की जरूरत बहुत कम पड़ती है
      server side पर भी कुछ समय तक old version और new version को mix करके भेजना पूरी तरह allowed है
    • यह joke नहीं, सही बात है

  • फिर वही एहसास कि ऐसी एक और पोस्ट आ गई। 1990 के दशक में इंटरनेट छोटा था और कंप्यूटर बहुत धीमे व कमज़ोर थे, लेकिन हमने इसे बहुत आसानी से सीखा था
    उस समय ISP के लिए DNS, LDAP, SMTP, IMAP जैसी चीज़ें बिल्कुल बुनियादी थीं, और लोग सच में RFC जैसे आधिकारिक दस्तावेज़ पढ़ते थे। इंटरनेट पर server चलाना हो तो सीखना पड़ता था, और थोड़ा समय लगाकर—यानी काम के दौरान मिलने वाला paid time इस्तेमाल करके—सीखा जा सकता था
    आज के developers और DevOps पीढ़ी में धैर्य या पहल नहीं है; वे उम्मीद करते हैं कि सब कुछ चम्मच से खिलाया जाए, और StackOverflow व कम-मूल्य वाले blogs से कुछ भी copy-paste कर देते हैं। इंटरनेट जिस आधार पर बना है उसे सीखने के बजाय, उस हफ़्ते के latest trendy wrapper tool उठा लेते हैं, घटिया blog instructions follow करते हैं, और जब सब ढह जाता है और कंपनी का बड़ा पैसा डूबता है तो खुद को पीड़ित बताते हैं। क्योंकि उन्होंने यह सीखने में समय नहीं लगाया कि इंटरनेट पर चीज़ें सच में कैसे चलती हैं
    ऐसी चीज़ें बार-बार देखी हैं। असल में यह इतना कठिन नहीं है। बस अपना homework करना होता है

  • कठिन नहीं है। DNS उन गिनी-चुनी technologies में से है जो बहुत ज़्यादा नहीं बदली हैं, और इसका काम करना भी काफ़ी intuitive है
    dig थोड़ा confusing हो सकता है। पुराने nslookup से ज़्यादा features हैं, लेकिन कम intuitive है। वैसे nslookup आज भी अच्छे से काम करता है
    मुझे लगता है कि industry के युवा लोग DNS और core protocols को लेकर इसलिए confuse होते हैं क्योंकि अब बहुत सारी चीज़ें “बस चल जाती हैं”
    उदाहरण के लिए, आजकल WiFi router डिब्बे से निकालते ही “बस चल जाता” है। 2000 के शुरुआती दौर में ऐसी चीज़ setup करने के लिए एक network engineer चाहिए होता था जिसे DNS, IP, Ethernet, RFC1918, असली routing protocols और बहुत कुछ पता हो, और वह यह भी अच्छी तरह जानता कि setup ऐसा क्यों किया गया है
    अगर आपको client-side DNS confusing लगता है, तो BIND configure करके देखिए ;-)
    /बूढ़े गले-दाढ़ी वाले की बड़बड़ाहट

    • 14 साल की उम्र में, DNS या DHCP समझे बिना, मैंने एक restaurant का Active Directory environment—mail, web और CIFS सहित—बहुत ढीले-ढाले तरीके से manage किया था
      WRT54G के DHCP server को सही name resolution के लिए domain controller का static IP DNS server के रूप में बांटना चाहिए था, लेकिन मैंने बस IP addresses और hosts file entries से सब कुछ चला दिया। Domain का MX record भी router के WAN IP पर set किया था और PTR record नहीं था। पीछे मुड़कर देखता हूँ तो email delivery का इतना smoothly चलना किसी चमत्कार से कम नहीं था
      कुछ साल बाद समझ आया कि DNS सच में कैसे काम करता है, और शुरुआती 20s में मुझे एक internal intranet विरासत में मिला जिसमें सभी external corporate domain zones के nameserver के रूप में BIND इस्तेमाल होता था। Reliability बढ़ाने के लिए इस setup को VPS पर move करते हुए मैंने zone transfers, SOA वगैरह के बारे में बहुत कुछ सीखा। उस अनुभव के लिए आभारी हूँ, लेकिन आजकल लगभग सब कुछ आपकी जगह संभाल लिया जाता है, इसलिए यह low-value activity बन गई है। अच्छा हो या बुरा, “IT” को “software engineering” जैसी तरह value नहीं दी जाती
    • यह सही है कि काम करने का तरीका अपेक्षाकृत intuitive है, लेकिन यह तब की बात है जब हम TTL को ignore करने वाले servers जैसी तरह-तरह की अजीब behavior possibilities को नज़रअंदाज़ कर दें
      Firefox ने जब DNS-over-HTTPS को default on करने वाला update निकाला था, वह मैं भूल नहीं सकता। हम DHCP के ज़रिए workstations को internal DNS server दे रहे थे, और अचानक “email गायब हो गया! सब कुछ टूट गया!” जैसी शिकायतों की बाढ़ आ गई। Internal webmail और intranet web servers ऐसे दिख रहे थे जैसे वे गायब हो गए हों
      क्या हुआ है यह समझने में ज़रूरत से ज़्यादा समय लगा। आंशिक वजह यह सोच थी कि “DNS है, अचानक क्यों टूटेगा?” लेकिन यह काफ़ी साफ़ है कि Mozilla ने ऐसी आसानी से अनुमान लगाई जा सकने वाली समस्या की उम्मीद नहीं की थी
    • यहाँ जिन बातों का ज़िक्र है, वे DNS का सिर्फ़ छोटा हिस्सा हैं
      उदाहरण के लिए, thing.behind.cdn.it lookup करने पर मुझे एक जवाब मिलता है, और किसी दूसरे व्यक्ति को उसी नाम के लिए दूसरा जवाब मिलता है। अपने-आप में यह काफ़ी स्पष्ट है, लेकिन जब कोई reasonable तरीके से पूछता है, “क्या आप thing.behind.cdn.it के लिए firewall में hole खोल सकते हैं?” तो मामला जटिल हो जाता है
      कुछ servers requests forward करते हैं, कुछ delegation करते हैं, कुछ आपकी ओर से lookup करते हैं और कुछ नहीं करते। Client का search domain magic भी है, और यह भी uncertain है कि client या internal resolver library TTL का पालन करेगी या नहीं
      Record types भी अनगिनत हैं, और कभी-कभी server UDP के बजाय TCP से फिर से connect करने को कहता है
      इसलिए DNS काफ़ी complex है। यह बहुत अच्छी तरह काम करता है और ज़्यादातर मुश्किल हिस्से “आम तौर पर बस चलने वाली” चीज़ों में abstract हो गए हैं, इसलिए इसके simple दिखने का एक भ्रम पैदा होता है
    • पुराने protocols जानने के संदर्भ में, पिछले कुछ हफ़्तों में मैंने Networking for System Administrators पढ़ी और बहुत सारे Anki card notes बनाए व revise किए
      DNS और उसके नीचे की चीज़ें—जैसे ethtool, Ethernet frames—समेत networking को high level पर समझने में मेरा confidence काफी बढ़ा है, यह देखकर आश्चर्य हुआ
      मुझे चीज़ें बुनियाद से समझना पसंद है, इसलिए university में computer science के बजाय electrical engineering चुना था; शायद इसलिए यह इतना आश्चर्यजनक भी नहीं है
    • सही है, BIND configuration कठिन है। Unbound/nsd कहीं ज़्यादा संभालने में आसान हैं। हालांकि सही documentation ढूँढने की प्रक्रिया अपने-आप में एक परेशान करने वाली exercise है
      DNS का principle recursive है, यह समझ लें तो वह इतना कठिन नहीं है। लेकिन security को ध्यान में रखकर configure करना, सही infrastructure रखना, और आख़िरी detail तक सब सही करना हो तो सीखने के लिए बहुत कुछ है। BIND को हटाकर बात करें तो यह इतना कठिन नहीं है