How DNS Works: A Practical Guide to Domain Name Resolution
2026-09-05 · undefined min
When you type a domain name into your browser, the internet does not actually know what that name means. Computers talk to each other using IP addresses, not names. The Domain Name System (DNS) is the phone book of the internet: it translates a human-readable name like netchecks.org into a machine-readable address like 203.0.113.10.
This translation happens in milliseconds and usually goes unnoticed. Yet when it fails, the internet seems completely broken: websites stop loading, email bounces, and automated systems report errors. Understanding how DNS works is therefore not just theory - it is the key to diagnosing a large share of network problems.
1983
The domain name system is born
Paul Mockapetris publishes the first DNS specification, replacing the single hosts file that had to be manually updated on every machine on the ARPANET.
1990s
The web makes names essential
The explosion of the web turns human-readable domains into the primary interface of the internet, and registrars open a commercial market for them.
2000s
Security and resilience arrive
DNSSEC is deployed to authenticate answers, while anycast distributes the root servers for speed, reliability and resistance to attacks.
Today
A modern, encrypted DNS
Recursive resolvers adopt DNS over HTTPS and DNS over TLS, protecting privacy and making resolution harder to tamper with.
What DNS does and why it matters
DNS is a distributed database that maps names to records. When you register a domain, you delegate control over its records to an authoritative name server, which stores entries such as A records (IPv4 addresses), AAAA records (IPv6 addresses), MX records (mail servers) and CNAME records (aliases). This delegation is what makes DNS scalable: no single server holds the entire internet.
Because names are the main interface humans use to reach services, DNS is a foundational dependency. Almost every connection starts with a resolution. When a service appears down, the first question should be whether the name even resolves. A basic understanding of the lookup path saves hours of debugging.
The resolution path: from browser to authoritative server
The journey begins on your device, where a resolver is configured - usually your router or your ISP. Your browser asks this recursive resolver for the IP address of netchecks.org. If the resolver has no cached answer, it starts from the top: a root server points to the server responsible for the .org top-level domain, and that TLD server points to the authoritative server for netchecks.org.
The authoritative server finally returns the A record with the IP address. Each step is a separate query, and each answer is cached along the way. This multi-stage dance is why the very first lookup of a name can take a moment, while the next one is almost instant.
The DNS resolution path from your browser through recursive, root, TLD and authoritative servers.
Recursive versus authoritative servers, caching and TTL
The recursive resolver is the worker that does the whole journey for you. It accepts your query, walks the chain of servers and returns the final answer. The authoritative server is the source of truth: it is the only place that knows the definitive records for a domain. Confusing the two is common, but they play very different roles. Most of the resolvers you use day to day are recursive, not authoritative.
To avoid redoing the whole walk for every request, resolvers cache answers for a duration defined by the TTL, the time to live attached to each record. A short TTL means fast propagation of changes, while a long TTL means faster lookups but slower updates. Understanding TTL is essential whenever you change a DNS record.
How to diagnose a resolution problem
When a name does not resolve, the fastest diagnostic is a lookup tool. A good tool can query any of the server types directly, showing you the root, TLD and authoritative answers step by step, or interrogate a specific recursive resolver. If a lookup returns the expected record but your browser still fails, the problem is likely elsewhere: your local cache, your resolver, or a firewall.
Start by testing several resolvers. If public resolvers return a correct answer while your local resolver does not, your resolver or router is at fault. If every resolver fails, the problem sits on the authoritative side. Comparing results isolates the broken layer quickly.
सार में
DNS is a layered system of caches, resolvers and authoritative servers. Knowing who answers which query, and how caching and TTL affect propagation, lets you isolate a failing layer in minutes instead of hours.
आपका सार्वजनिक IP पता और नेटवर्क स्थान, स्वचालित रूप से पता लगाया गया।
NetChecks खोलते ही यह स्वतः लोड हो जाता है — किसी इनपुट की आवश्यकता नहीं। नेटवर्क या VPN बदलने के बाद रीफ़्रेश बटन का उपयोग करें।
आपका ब्राउज़र
ऑल-इन-वन स्कैन
एक ही पास में एक IP या होस्टनेम पर सभी प्रासंगिक जांच चलाता है: DNS, whois, ping, traceroute, सुविज्ञात पोर्ट स्कैन (1-1024), HTTP हेडर और SSL प्रमाणपत्र।
एक डोमेन या IP पता दर्ज करें और चलाएँ ताकि DNS, whois, ping, traceroute, सामान्य पोर्ट, HTTP हेडर और SSL प्रमाणपत्र एक साथ जांचे जा सकें।
अधिकांश जांचें समानांतर में चलती हैं - आमतौर पर लगभग 30 सेकंड में पूरी हो जाती हैं, यदि लक्ष्य धीमा या अनुपलब्ध है तो अधिक समय लग सकता है।
पोर्ट स्कैन चरण तभी चलता है जब ऊपर दिया गया सहमति चेकबॉक्स चेक किया गया हो - बाकी सभी जांचें वैसे भी चलती हैं।
पिंग (Ping)
किसी होस्ट की पहुंच और विलंबता जांचने के लिए ICMP echo अनुरोध भेजें।
एक होस्टनाम या IP पता दर्ज करें और ICMP इको अनुरोध भेजकर राउंड-ट्रिप विलंबता मापने के लिए Ping दबाएँ।
अधिक जानें: पिंग (Ping)
परिभाषा
Ping किसी होस्ट को ICMP Echo Request पैकेट भेजता है और मापता है कि ICMP Echo Reply वापस आने में कितना समय लगता है। यह सबसे बुनियादी नेटवर्क कनेक्टिविटी टेस्ट है: यह सिर्फ एक सवाल का जवाब देता है, "क्या यह मशीन पहुंच योग्य है, और कितनी जल्दी?" ICMP प्रोटोकॉल (RFC 792) को 1981 में खासतौर पर IP नेटवर्क पर कंट्रोल और डायग्नोस्टिक मैसेज ले जाने के लिए डिज़ाइन किया गया था, किसी भी एप्लिकेशन ट्रैफिक से अलग - Ping इसका सबसे जाना-पहचाना और सबसे ज़्यादा उपलब्ध implementation है, जो लगभग हर ऑपरेटिंग सिस्टम और नेटवर्क डिवाइस में शुरुआत से ही मौजूद है।
यह कैसे काम करता है
हर ICMP पैकेट में एक TTL (Time To Live) फ़ील्ड होता है जो हर राउटर से गुज़रने पर एक-एक करके घटता है; अगर टारगेट तक पहुंचने से पहले यह शून्य पर पहुंच जाए, तो पैकेट ड्रॉप कर दिया जाता है और भेजने वाले को एक एरर वापस भेजा जाता है। मिलीसेकंड में मापा गया राउंड-ट्रिप टाइम (RTT) पूरे राउंड-ट्रिप में जमा हुई कुल नेटवर्क लेटेंसी दर्शाता है, न कि सिर्फ टारगेट के पास वाले आखिरी हिस्से की - यह बात अक्सर गलत समझी जाती है, क्योंकि धीमे ping नतीजों की असली वजह रास्ते में कहीं भी हो सकती है, ज़रूरी नहीं कि टेस्ट किए जा रहे सर्वर के पास ही हो। Ping आमतौर पर एक की बजाय लगातार कई पैकेट भेजता है, जिससे एक बार की लेटेंसी स्पाइक और बार-बार होने वाली समस्या के बीच फर्क किया जा सकता है, और उस सैंपल पर पैकेट लॉस रेट भी निकाला जा सकता है।
नतीजों को समझें
एक स्थिर, कम RTT - लोकल नेटवर्क पर कुछ मिलीसेकंड, एक ही देश के भीतर किसी डेस्टिनेशन के लिए 10 से 50 मिलीसेकंड, और इंटरकॉन्टिनेंटल लिंक के लिए काफी ज़्यादा - एक स्वस्थ कनेक्शन दिखाता है। थोड़ा सा भी पैकेट लॉस (1-2% से ऊपर) VoIP या इंटरैक्टिव रिमोट सेशन जैसे लेटेंसी-सेंसिटिव इस्तेमाल के लिए खासतौर पर नुकसानदेह होता है, जहां हर ड्रॉप हुआ पैकेट किसी गड़बड़ी या सुनाई देने वाले कट के रूप में सामने आता है। एक पैकेट से दूसरे पैकेट के बीच बहुत ज़्यादा बदलती लेटेंसी (jitter) अक्सर इन्हीं इस्तेमालों के लिए ऊंची लेकिन बिल्कुल स्थिर लेटेंसी से भी बड़ी समस्या होती है। "Request timed out" का मतलब है कि तय समय में कोई जवाब नहीं आया - हो सकता है होस्ट सच में डाउन हो, फायरवॉल चुपचाप ICMP ब्लॉक कर रहा हो, या रास्ते में कहीं कोई रूट टूटा हो; "Destination unreachable" इससे अलग और ज़्यादा जानकारी देने वाला है: इसका मतलब है कि रास्ते के बीच के किसी राउटर ने साफ तौर पर बता दिया कि वह पैकेट को आगे नहीं भेज सका, जिससे समस्या की जगह पहचानने में मदद मिलती है।
आम गलतियां
सबसे आम गलतफहमी यह है कि ping फेल होते ही होस्ट को "डाउन" मान लिया जाए, जबकि बहुत से सर्वर और डिवाइस - खासकर सख्त फायरवॉल के पीछे या बड़े क्लाउड प्रोवाइडर्स के यहां होस्ट किए गए - जानबूझकर नीति के तहत इनबाउंड ICMP ब्लॉक करते हैं, जबकि उनकी असली सेवाएं (HTTP, डेटाबेस, वगैरह) पूरी तरह काम कर रही होती हैं और पहुंच योग्य होती हैं। इसलिए ping का जवाब न मिलना सिर्फ तभी डाउनटाइम का सबूत माना जा सकता है जब इसे दूसरे संकेतों के साथ मिलाकर देखा जाए, जैसे कि एप्लिकेशन का खुद भी जवाब न देना। इसके उलट, ping सफल होना इस बात की कोई गारंटी नहीं देता कि उस मशीन पर चल रही एप्लिकेशन सर्विस सही से काम कर रही है - ये नेटवर्क स्टैक की दो बिल्कुल अलग परतें हैं।
कब उपयोग करें
किसी टिकट को आगे बढ़ाने से पहले सबसे पहले जांचने वाली बात: गहराई में जाने से पहले क्या मशीन बिल्कुल भी जवाब दे रही है? फायरवॉल रूल या रूटिंग टेबल में बदलाव के बाद कनेक्टिविटी की पुष्टि करना, ताकि यह तय हो सके कि बदलाव से एक्सेस टूटा नहीं है। VoIP रोलआउट या कैरियर लिंक फेलओवर से पहले एक बेसलाइन लेटेंसी माप स्थापित करना, ताकि बाद में कॉल क्वालिटी की शिकायत आने पर तुलना के लिए कोई ठोस आधार मौजूद हो। एक साथ कई क्लाइंट साइट्स पर नज़र रखने वाले MSP के लिए एक हल्की, कम ओवरहेड वाली नियमित हेल्थ चेक, लेकिन हमेशा गहरी एप्लिकेशन-लेवल मॉनिटरिंग के पूरक के तौर पर, कभी उसके विकल्प के तौर पर नहीं।
Traceroute
किसी गंतव्य होस्ट तक नेटवर्क पथ (हॉप दर हॉप) का पता लगाएं।
एक होस्टनाम या IP पता दर्ज करें और चलाएँ ताकि इस सर्वर और गंतव्य के बीच हर नेटवर्क हॉप, प्रत्येक हॉप की विलंबता के साथ, देखा जा सके।
DNS लुकअप (Nslookup)
DNS रिकॉर्ड क्वेरी करें: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA।
एक डोमेन दर्ज करें, एक रिकॉर्ड प्रकार चुनें (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, या CAA), फिर खोजें।
Whois
किसी डोमेन या IP पते की पंजीकरण जानकारी देखें।
किसी डोमेन या IP पते की पंजीकरण जानकारी देखने के लिए उसे दर्ज करें — रजिस्ट्रार, स्वामी संगठन और महत्वपूर्ण तिथियाँ।
ब्लैकलिस्ट जांच
जांचें कि कोई IP पता या डोमेन सार्वजनिक स्पैम/दुरुपयोग ब्लैकलिस्ट (DNSBL) में सूचीबद्ध है या नहीं।
एक IPv4 पता या डोमेन दर्ज करें और चलाएं ताकि एक साथ 7 सार्वजनिक DNSBL/RBL ब्लैकलिस्ट जांची जा सकें - प्रत्येक को सूचीबद्ध, असूचीबद्ध या जांच विफल के रूप में दिखाया जाता है।
TCP पोर्ट स्कैन
जांचें कि किसी होस्ट या IP पर TCP पोर्ट खुले हैं: सामान्य पोर्ट, कस्टम सूची, या पूरी 1-65535 रेंज।
एक होस्ट या IP दर्ज करें, सामान्य पोर्ट, कस्टम सूची, या पूरी रेंज चुनें, फिर स्कैन करें कि कौन से TCP पोर्ट प्रतिक्रिया देते हैं।
पूर्ण रेंज स्कैन में लगभग 100 सेकंड तक लग सकते हैं। बड़े स्कैन (100 से अधिक पोर्ट, कस्टम रेंज/सूचियाँ सहित) प्रति विज़िटर प्रति मिनट 1 बार तक सीमित हैं।
खुले पोर्ट (0)
HTTP हेडर इंस्पेक्टर
किसी URL के लिए HTTP प्रतिक्रिया स्थिति और हेडर प्राप्त करें।
किसी URL की HTTP प्रतिक्रिया स्थिति कोड और सर्वर द्वारा भेजे गए सभी प्रतिक्रिया हेडर प्राप्त करने के लिए उसे दर्ज करें।
SSL / TLS प्रमाणपत्र जांचकर्ता
किसी होस्ट के TLS प्रमाणपत्र की जांच करें: जारीकर्ता, वैधता तिथियां और शेष दिन।
किसी होस्टनाम का TLS प्रमाणपत्र जांचने के लिए उसे दर्ज करें — जारीकर्ता, वैधता तिथियाँ, और समाप्ति तक शेष दिन।
Geo-IP लुकअप
किसी IP पते का भौगोलिक स्थान और नेटवर्क जानकारी देखें। अपना सार्वजनिक IP देखने के लिए खाली छोड़ें।
कोई भी IP पता दर्ज करें, या अपना खुद का पता देखने के लिए खाली छोड़ें, ताकि उसका अनुमानित स्थान और नेटवर्क/ISP जानकारी देखी जा सके।
पूरी तरह से आपके ब्राउज़र में गणना की जाती है — सर्वर को कोई डेटा नहीं भेजा जाता।
तुरंत नेटवर्क रेंज, ब्रॉडकास्ट पता, और उपयोग योग्य होस्ट संख्या की गणना करने के लिए एक IP पता और CIDR प्रीफ़िक्स (जैसे 192.168.1.0/24) दर्ज करें।
स्पीड टेस्ट
इस सर्वर के साथ बुनियादी डाउनलोड/अपलोड थ्रूपुट परीक्षण (सटीकता सर्वर के अपने कनेक्शन पर निर्भर करती है)।
इस सर्वर के विरुद्ध डाउनलोड और अपलोड गति मापने के लिए स्टार्ट दबाएँ। सटीकता इस सर्वर के अपने कनेक्शन पर निर्भर करती है।
देश कोड शब्दकोश
ISO 3166-1 alpha-2 देश कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
ISO 3166-1 alpha-2 देश कोड की सूची खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजी जाती है।
देश
ISO कोड
फ़ोन डायलिंग कोड शब्दकोश
देश के अनुसार अंतरराष्ट्रीय कॉलिंग कोड — पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
देश के अनुसार अंतरराष्ट्रीय डायलिंग कोड खोजें या ब्राउज़ करें, जो पूरी तरह से आपके ब्राउज़र में खोजे जाते हैं।
देश
डायलिंग कोड
विश्व घड़ी
वर्तमान समय देखने के लिए एक टाइम ज़ोन चुनें — ग्लोब को घुमाने के लिए खींचें।
सूची से एक समय क्षेत्र चुनें, या ग्लोब को घुमाएँ, ताकि वहाँ का वर्तमान समय देखा जा सके।
आपका समय
--:--:--
—
—
चयनित समय
--:--:--
—
—UTC±00:00
आपसे समय का अंतर—
—
ग्लोब घुमाने के लिए खींचें।
फ्रांस मोबाइल नेटवर्क स्थिति
फ्रांस में ऑपरेटर (Orange, Free, SFR, Bouygues Telecom) के अनुसार खराब या रखरखाव में मोबाइल एंटीना साइटें, Arcep के सार्वजनिक डेटा से। दिन में एक बार अपडेट होने वाला स्नैपशॉट - मिनट-दर-मिनट फीड नहीं।
फ्रांसीसी ऑपरेटर के अनुसार मोबाइल एंटीना और फाइबर आउटेज डेटा ब्राउज़ करें — किसी इनपुट की आवश्यकता नहीं, ARCEP के सार्वजनिक डेटा से स्वतः अपडेट होता है।
स्रोत: Arcep, "Sites indisponibles" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है, पहले इस्तेमाल किए गए IODA/CAIDA डेटा के विपरीत। Normal/Watch/Alert बैज एक अनुमानित संकेतक है (आज की गड़बड़ियों की संख्या बनाम पिछले दिनों का औसत), Arcep का आधिकारिक वर्गीकरण नहीं। स्रोत लिंक नीचे।
सबसे अधिक प्रभावित विभाग
वर्तमान में खराब या रखरखाव में साइटों की संख्या, विभाग अनुसार। फ़िल्टर के लिए ऐपर किसी ऑपरेटर पर क्लिक करें।
ऑपरेटर अनुसार फ़ाइबर (FTTH) नेटवर्क गुणवत्ता: रिपोर्ट की गई खराबी दर और कनेक्शन विफलता दर, Arcep के सार्वजनिक डेटा से। मासिक संकेतक, 6 महीने का औसत - मोबाइल सेक्शन की तरह लाइव फीड नहीं।
स्रोत: Arcep, "Qualité des réseaux en fibre optique" डेटासेट, Licence Ouverte / Etalab 2.0 के तहत प्रकाशित - व्यावसायिक पुन:उपयोग की स्पष्ट रूप से अनुमति है। स्रोत लिंक नीचे।
ऑपरेटर अनुसार (मूल कंपनी)
पिछले 6 उपलब्ध महीनों का औसत, इन्फ्रास्ट्रक्चर ऑपरेटर की मूल कंपनी अनुसार।
NetChecks केवल वैध नेटवर्क डायग्नोस्टिक्स और शैक्षणिक उद्देश्यों के लिए प्रदान किया गया है, केवल उन सिस्टम, डोमेन और IP पतों पर जिनके आप स्वामी हैं या जिन्हें परीक्षण के लिए स्पष्ट रूप से अधिकृत किया गया है।
बिना अनुमति के तीसरे पक्ष के सिस्टम के खिलाफ पोर्ट स्कैन, DNS/whois लुकअप, traceroute या अन्य जांच चलाना आपके क्षेत्राधिकार में कंप्यूटर दुरुपयोग कानूनों का उल्लंघन कर सकता है (उदाहरण के लिए अमेरिका में Computer Fraud and Abuse Act, फ्रांस में "Loi Godfrain", या समकक्ष स्थानीय कानून)। यह सुनिश्चित करना पूरी तरह से आपकी ज़िम्मेदारी है कि आपके पास यहां दर्ज किए गए किसी भी लक्ष्य का परीक्षण करने का अधिकार है।
यह साइट और इसके परिणाम "जैसे हैं वैसे" उपलब्ध कराए गए हैं, बिना किसी प्रकार की वारंटी के। इस साइट का संचालक इस साइट के उपयोग से उत्पन्न किसी भी प्रत्यक्ष, अप्रत्यक्ष या परिणामी नुकसान, कानूनी परिणाम, या दुरुपयोग के लिए कोई ज़िम्मेदारी स्वीकार नहीं करता।
दुरुपयोग रोकने के लिए अनुरोधों की दर सीमित की जाती है। इस इंस्टेंस का संचालक वैकल्पिक रूप से अनुरोध-गतिविधि लॉगिंग सक्षम कर सकता है - यदि ऐसा हो, तो प्रत्येक टूल अनुरोध (आपका आईपी पता, समय-मुह्र, उपयोग किया गया टूल, और दर्ज किया गया लक्ष्य/क्वेरी) सुरक्षा, दुरुपयोग-रोकथाम और उपयोग-विश्लेषण के उद्देश्यों के लिए डेटाबेस में दर्ज किया जा सकता है। यह डिफ़ॉल्ट रूप से अक्षम है। इस साइट का उपयोग करके आप इन शर्तों से सहमत होते हैं; यदि आप सहमत नहीं हैं, तो कृपया इस साइट का उपयोग न करें।
इस साइट का प्रोग्रामैटिक (एपीआई) उपयोग भी इन्हीं शर्तों के अधीन है, जिसमें उपरोक्त प्राधिकरण आवश्यकता भी शामिल है।
प्रतिक्रिया भेजें
समस्या बताएं, टिप्पणी करें, या नई सुविधा का सुझाव दें।
यह साइट विज्ञापन दिखाती है और यदि आप सहमत हों, तो होस्टिंग को वित्तपोषित करने में मदद के लिए विज्ञापन-भागीदार कुकीज़ का उपयोग करती है। आप मना कर सकते हैं और सभी टूल्स का विज्ञापन-मुक्त उपयोग जारी रख सकते हैं।