सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)
जानें कि DNSSEC DNS कैश पॉइज़निंग को कैसे रोकता है और HTTPS तथा TLS पर DNS, मार्ग में मौजूद पर्यवेक्षकों से क्वेरी की गोपनीयता की रक्षा कैसे करते हैं।
सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH), CoddyKit पर Cloud & IT Cert Prep का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Cloud & IT Cert Prep सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
DNS सुरक्षा की चुनौतियाँ
Domain Name System (DNS) मनुष्यों द्वारा पढ़े जा सकने वाले domain नामों को IP पतों में बदलता है। 1980 के दशक में बनाया गया DNS सुरक्षा के बिना तैयार किया गया था — Query और उत्तर UDP/TCP port 53 पर बिना एन्क्रिप्शन और प्रमाणीकरण के भेजे जाते हैं। इससे दो प्रमुख कमज़ोरियाँ पैदा होती हैं: DNS कैश विषाक्तकरण (उपयोगकर्ताओं को दुर्भावनापूर्ण Server पर भेजने के लिए जाली DNS उत्तर डालना) और DNS जासूसी (उपयोगकर्ता किन domain को Query करता है, यह देखकर उसकी ब्राउज़िंग गतिविधि का पता लगाना)। इनसे निपटने के लिए दो मानक हैं: DNSSEC जालसाज़ी रोकता है और DNS over HTTPS (DoH) जासूसी रोकता है।
DNS कैश विषाक्तकरण
DNS कैश विषाक्तकरण (Kaminsky हमला) DNS प्रोटोकॉल में प्रमाणीकरण की कमी का फ़ायदा उठाता है। Resolver किसी authoritative DNS Server को Query भेजता है और उत्तर को TTL अवधि तक कैश करता है। यदि कोई Attacker transaction ID (16-bit, अनुमान लगाने योग्य) और source port (RFC 5452 के बाद अतिरिक्त entropy के रूप में उपयोग किया जाता है) का अनुमान लगा सके, तो वह जाली उत्तर भेज सकता है जिन्हें Resolver कैश कर लेता है। इससे उस Resolver को Query करने वाले सभी उपयोगकर्ता Attacker के Server पर भेजे जाते हैं। कैश विषाक्त हो जाने के बाद, सही domain लिखने पर भी उपयोगकर्ताओं को नकली Server पर भेजा जाता है। DNSSEC DNS उत्तरों पर डिजिटल हस्ताक्षर करके इसे रोकता है।
# DNS cache poisoning simulation
# Attacker floods resolver with forged responses
# for the query 'A example.com?'
# Each response guesses a different transaction ID:
# ID=1234: example.com -> 198.51.100.1 (attacker IP)
# ID=1235: example.com -> 198.51.100.1
# ...
# ID=XXXX: example.com -> 198.51.100.1 (correct guess!)
# Resolver caches poisoned answer (TTL = 3600s)
# All users querying this resolver get attacker IP
# Users are redirected to phishing/malware serverDNSSEC: DNS सुरक्षा एक्सटेंशन
DNSSEC DNS रिकॉर्ड में क्रिप्टोग्राफ़िक हस्ताक्षर जोड़ता है, जिससे Resolver यह सत्यापित कर सकते हैं कि उत्तर वैध zone authority से आए हैं और उनमें छेड़छाड़ नहीं हुई है। DNSSEC नए रिकॉर्ड प्रकार प्रस्तुत करता है: RRSIG (resource record signature, किसी record set पर किया गया वास्तविक हस्ताक्षर), DNSKEY (हस्ताक्षरों को सत्यापित करने के लिए उपयोग की जाने वाली सार्वजनिक कुंजी), DS (delegation signer, parent और child zone की कुंजियों को जोड़ता है) और NSEC/NSEC3 (अस्तित्व न होने का प्रमाणित निषेध — यह सिद्ध करता है कि कोई नाम मौजूद नहीं है)। DNSSEC root zone (ICANN द्वारा हस्ताक्षरित) से लेकर TLD और authoritative zone तक विश्वास की शृंखला बनाता है।
# Verify DNSSEC signature on a domain
dig +dnssec example.com A
# Look for 'ad' (authenticated data) flag in response
# and the RRSIG record alongside the A record
# Query for DNSKEY record
dig DNSKEY example.com
# Query for DS record at parent zone
dig DS example.com @a.iana-servers.net
# Full DNSSEC chain validation check
dig +sigchase +trusted-key=/.../root.key example.com ADNSSEC कुंजी प्रकार: KSK और ZSK
DNSSEC दो प्रकार की हस्ताक्षर कुंजियों का उपयोग करता है। Zone Signing Key (ZSK) अलग-अलग DNS record set (RRSIG) पर हस्ताक्षर करती है और परिचालन में लचीलापन बनाए रखने के लिए इसे बार-बार (मासिक या त्रैमासिक) बदला जाता है। Key Signing Key (KSK) DNSKEY record set पर हस्ताक्षर करती है और zone के लिए विश्वास का आधार प्रदान करती है। KSK को कम बार (वार्षिक रूप से) बदला जाता है, क्योंकि KSK बदलने पर parent zone में नया DS रिकॉर्ड अपडेट करना पड़ता है — इसके लिए समन्वय आवश्यक होता है। KSK, ZSK का सत्यापन करती है; ZSK, डेटा पर हस्ताक्षर करती है। यह दो-स्तरीय संरचना सुरक्षा (ZSK को बार-बार बदलना) और परिचालन बोझ (KSK को कम बार बदलना) के बीच संतुलन बनाती है।
DNSSEC की सीमाएँ
DNSSEC की कुछ महत्वपूर्ण सीमाएँ हैं। यह DNS Query को एन्क्रिप्ट नहीं करता — यह केवल अखंडता के लिए उत्तरों पर हस्ताक्षर करता है। कोई जासूस अब भी सभी DNS Query देख सकता है, लेकिन उत्तरों को जाली नहीं बना सकता। Zone enumeration: NSEC रिकॉर्ड (जो अस्तित्व न होने का प्रमाण देते हैं) Attacker को zone में मौजूद सभी domain नामों की सूची बनाने और zone में आगे बढ़ने देते हैं; NSEC3 hashed नामों से इस जोखिम को कम करता है, लेकिन इसे पूरी तरह समाप्त नहीं करता। परिचालन जटिलता: कुंजी प्रबंधन, हस्ताक्षर की समाप्ति और parent zone के साथ समन्वय से परिचालन बोझ काफ़ी बढ़ जाता है। DNSSEC का अपनाया जाना अभी भी अधूरा है — कई TLD और registrar इसका समर्थन करते हैं, लेकिन कई संगठनों ने इसे लागू नहीं किया है।
DNS पर HTTPS (DoH)
DNS पर HTTPS (DoH) DNS Queries को HTTPS (RFC 8484) के अंदर Encrypt करता है, जिससे Network Observers से Query की सामग्री छिपी रहती है। Queries, मानक HTTPS URL पर DoH-सक्षम Resolver को भेजी जाती हैं, इसलिए DNS Traffic अन्य HTTPS Traffic से अलग पहचान में नहीं आता। इससे ISP, नियोक्ता और On-path Attackers यह नहीं देख पाते कि User किन Domains के लिए Query कर रहा है — इस तरह DNSSEC से बनी Privacy Gap दूर होती है। हालांकि, DoH का उपयोग Trust को Network के DNS Resolver से हटाकर DoH Provider पर केंद्रित कर देता है (आमतौर पर Google 8.8.8.8, Cloudflare 1.1.1.1 या संगठन का अपना DoH Resolver)। अब अधिकांश प्रमुख Browsers में DoH मूल रूप से Supported है।
# DoH query using curl
curl -H 'accept: application/dns-json' \
'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
# DoH query via RFC 8484 (binary format)
curl -s -H 'Content-Type: application/dns-message' \
-H 'Accept: application/dns-message' \
--data-binary @query.bin \
https://dns.google/dns-query
# Configure Firefox to use DoH
# about:config -> network.trr.uri
# Set to: https://mozilla.cloudflare-dns.com/dns-queryDNS पर TLS (DoT)
DNS पर TLS (DoT) (RFC 7858), HTTPS के माध्यम से Tunneling करने के बजाय, समर्पित TCP Port 853 पर TLS का उपयोग करके DNS Queries को Encrypt करता है। DoT, DoH के समान Privacy लाभ देता है — यानी सुनने वाले हमलावरों से Query की सामग्री छिपाता है — लेकिन Network Administrators के लिए इसकी पहचान करना और इसे Filter करना आसान होता है (Port 853 बनाम Port 443)। यह दोधारी तलवार है: Enterprise Firewalls DoT को दिखाई देने और Port 853 के कारण Block कर सकते हैं, जबकि सामान्य HTTPS Traffic को प्रभावित किए बिना DoH को Block करना कठिन है। Stub Resolvers (OS-स्तर) आम तौर पर DoT का अधिक उपयोग करते हैं; Browsers आम तौर पर DoH का अधिक उपयोग करते हैं।
# Test DoT connection using kdig
kdig -d @9.9.9.9 +tls-ca example.com A
# Test DoT using openssl
openssl s_client -connect 1.1.1.1:853
# Then type: query string in DNS wire format
# Configure systemd-resolved to use DoT (Linux)
# /etc/systemd/resolved.conf:
[Resolve]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yesDoH और DoT: Enterprise संबंधी विचार
Encrypted DNS, उन Enterprise Environments के लिए चुनौती पैदा करता है जो DNS-आधारित Filtering और Sinkhole पर निर्भर करते हैं। जब Browsers बाहरी DoH Resolvers का उपयोग करते हैं, तो आंतरिक DNS Controls को Bypass कर दिया जाता है। Enterprise के Countermeasures: आंतरिक DoH/DoT Resolver Deploy करें (Cisco Umbrella, DoH वाला Pi-hole) और सभी Devices को इसका उपयोग करने के लिए Configure करें; Firewall पर बाहरी DoH Resolver IPs को Block करें (Port 443 पर Google 8.8.8.8, Cloudflare 1.1.1.1); Managed Endpoints पर Browser-स्तरीय DoH को Disable करने के लिए Group Policy का उपयोग करें; और Port 853 पर DNS-over-TLS को Intercept करने वाले Transparent Proxy Rules लागू करें। लक्ष्य यह है कि Encrypted DNS को पूरी तरह Block किए बिना, सभी DNS को नियंत्रित Resolver के माध्यम से भेजा जाए।
# Enterprise DoH bypass prevention
# Windows Group Policy:
# Computer Config > Admin Templates > Google Chrome
# 'DNS over HTTPS mode': Disabled
# 'DNS over HTTPS URI templates': <empty>
# Firewall: block known public DoH resolvers
iptables -I FORWARD -d 8.8.8.8 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 1.1.1.1 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 9.9.9.9 -p tcp --dport 443 -j DROP
iptables -I FORWARD -d 149.112.112.112 -p tcp --dport 443 -j DROP
# Redirect all DNS to corporate resolver
iptables -t nat -A PREROUTING -p udp --dport 53 \
-j DNAT --to-destination 10.0.0.53:53व्यवहार में DNS Security
एक संपूर्ण DNS Security Strategy कई Controls को मिलाकर बनाई जाती है। आपके Authoritative Zones के लिए DNSSEC, आपके Domain के Cache Poisoning को रोकने हेतु Cryptographic Signatures जोड़ता है। DNS-आधारित Filtering (Cisco Umbrella, Cloudflare Gateway), Resolver स्तर पर Malicious Domains को Block करती है। नियंत्रित Resolver तक DoH/DoT, Filtering Visibility खोए बिना Query Privacy प्रदान करता है। SIEM में DNS Logging Threat Hunting के लिए सभी Queries को Capture करती है — DNS Logs, C2 Traffic, DNS Tunneling के माध्यम से Data Exfiltration और Malware की Domain Generation Algorithm (DGA) Activity को उजागर करते हैं। DNS Telemetry उपलब्ध सबसे अधिक मूल्यवान Security Data Sources में से एक है।
DNS Tunneling का पता लगाना
DNS Tunneling, Data Exfiltrate करने या ऐसे Networks के माध्यम से C2 Channels स्थापित करने के लिए DNS Queries और Responses के अंदर Data Encode करता है, जहाँ अन्य Outbound Traffic Block होता है। iodine, DNScat और dnscat2 जैसे Tools, Subdomain Labels ( EXFILTRATEDDATA.evil.com के लिए Query) या TXT Records में Payloads Encode करते हैं। Detection के संकेत हैं: असामान्य रूप से लंबे DNS Query Names (>100 Characters), एक ही Host से बहुत अधिक Query Volume, ऐसे Parent Domains के लिए Queries जो मौजूद नहीं हैं, असामान्य Record Types (TXT, NULL), और Domain Labels का Entropy Analysis (Encoded Data में Shannon Entropy अधिक होती है)। DNS Security Analytics Platforms, Tunneling Patterns को अपने-आप Flag करते हैं।
# DNS tunneling detection indicators
# Flag queries with:
# 1. Query name > 100 characters
# 2. More than 50 queries/minute from single host
# 3. High-entropy domain labels (base64/hex patterns)
# 4. TXT or NULL record type queries (unusual)
# 5. Queries to domains with no web presence
# Example tunnel query (encoded payload)
# aGVsbG8gd29ybGQ.vGhpcyBpcyBkYXRh.evil-domain.com
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# Base64 encoded 'hello world this is data'DNS Response Policy Zones (RPZ)
DNS Response Policy Zones (RPZ), DNS Resolvers को DNS Responses पर स्थानीय Override Policies लागू करने की अनुमति देते हैं — यानी Global DNS Infrastructure में बदलाव किए बिना Resolver स्तर पर स्थानीय Sinkhole बनाया जा सकता है। जब कोई Client किसी ज्ञात Malicious Domain के लिए Query करता है, तो RPZ Policy NXDOMAIN, Sinkhole IP पर Redirect, या Passthrough Response लौटाती है। RPZ Feeds Threat Intelligence Providers (Spamhaus, SURBL) से उपलब्ध होती हैं और इन्हें सीधे BIND या Unbound Resolvers में Import किया जा सकता है। RPZ एक शक्तिशाली Defensive Tool है, क्योंकि यह Client-side Configuration के बिना Network के सभी Devices के लिए DNS Layer पर Filtering लागू करता है।
# BIND RPZ configuration snippet
# /etc/named.conf
response-policy {
zone 'rpz.spamhaus.net';
zone 'local-blocklist.internal';
};
# RPZ zone file (local-blocklist.internal)
$ORIGIN local-blocklist.internal.
@ SOA ns1.company.com. admin.company.com. 2024010101 3600 600 86400 300
botnet-c2.evil IN CNAME . # NXDOMAIN response
phishing-site.com IN A 10.0.0.99 # Redirect to sinkholeत्वरित जाँच
इस Lesson से CompTIA Security+ (SY0-701) Concepts की अपनी समझ को परखें।
Lesson का पुनरावलोकन
इस Lesson में आपने सीखा: DNSSEC, Cache Poisoning रोकने के लिए KSK/ZSK Key Pairs का उपयोग करके DNS Records में Cryptographic Signatures जोड़ता है, लेकिन Queries को Encrypt नहीं करता; DNS पर HTTPS (DoH), Eavesdropping रोकने के लिए DNS Queries को HTTPS के अंदर Encrypt करता है, लेकिन Enterprise Filtering को Bypass करने का Risk पैदा करता है; और DNS Tunneling, DNS Queries में Data Encode करता है तथा Query Length, Volume और Entropy Analysis से इसका पता लगाया जा सकता है। आगे हम IPsec, VPN Protocols और Remote Access Security का अध्ययन करेंगे।
एआई शिक्षक के साथ Cloud & IT Cert Prep सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 150
- पाठ
- 600
अक्सर पूछे जाने वाले प्रश्न
क्या “सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)” पाठ निःशुल्क है?
हाँ—“सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Cloud & IT Cert Prep पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)” में मैं क्या सीखूँगा?
जानें कि DNSSEC DNS कैश पॉइज़निंग को कैसे रोकता है और HTTPS तथा TLS पर DNS, मार्ग में मौजूद पर्यवेक्षकों से क्वेरी की गोपनीयता की रक्षा कैसे करते हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Cloud & IT Cert Prep का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Cloud & IT Cert Prep शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Cloud & IT Cert Prep शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Cloud & IT Cert Prep पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Cloud & IT Cert Prep पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- असुरक्षित प्रोटोकॉल बदलना: Telnet बनाम SSH, FTP बनाम SFTP
- TLS संस्करण, सिफ़र सुइट और पूर्ण फ़ॉरवर्ड गोपनीयता
- सुरक्षित DNS: DNSSEC और HTTPS पर DNS (DoH)
- IPsec, VPN प्रोटोकॉल और दूरस्थ पहुँच सुरक्षा