Public Suffix लुकअप — किसी भी होस्ट का eTLD+1 जानें

Public Suffix List क्या है?

Public Suffix List, Mozilla की पहल है जिसे समुदाय संभालता है, और यह हर उस suffix का नाम बताती है जिसके नीचे लोग नाम रजिस्टर कर सकते हैं: टॉप-लेवल डोमेन (com), रजिस्ट्री के दूसरे स्तर (co.uk, com.sa) और PRIVATE सेक्शन में सबडोमेन देने वाले प्लेटफ़ॉर्म (github.io)। रजिस्टर होने लायक़ डोमेन (eTLD+1) public suffix और उससे पहले का एक लेबल है; ब्राउज़र इसी से पूरे suffix के लिए रखी कुकी ठुकराते हैं और तय करते हैं कि कौन-से होस्ट एक ही साइट के हैं।

सुरक्षा नोट: जो कोड आख़िरी दो लेबल को रजिस्टर होने लायक़ डोमेन मान लेता है, वह co.uk और github.io पर ग़लत होता है, और इससे एक टेनेंट की कुकी या अनुमतियाँ दूसरे टेनेंट के होस्ट तक पहुँच सकती हैं।

Public Suffix लुकअप कैसे इस्तेमाल करें

होस्ट नाम या URL पेस्ट करें, हर लाइन में एक; URL अपने होस्ट तक छोटे हो जाते हैं।
ब्राउज़र की नज़र के लिए "सिर्फ़ ICANN सेक्शन" बंद रखें, या रजिस्ट्री की तरह रजिस्टर होने लायक़ नाम देखने के लिए चालू करें।
टेबल पढ़ें: public suffix वह स्तर है जिसके नीचे लोग नाम रजिस्टर करते हैं, और रजिस्टर होने लायक़ डोमेन वह साइट है जिसकी कुकी या रजिस्ट्रेशन होता है।
wildcard, exception, प्राइवेट और बिना सूची वाले suffix के लिए नोट्स देखें, और पहले होस्ट से मेल खाए हर नियम के लिए ब्योरे का पैनल।

Public Suffix लुकअप की खूबियाँ

एक बार में 50 तक होस्ट नाम या URL के लिए public suffix, रजिस्टर होने लायक़ डोमेन (eTLD+1) और सबडोमेन
फ़ैसला करने वाला नियम, उसका प्रकार (सूचीबद्ध, wildcard, exception या implicit "*") और उसका सेक्शन, ICANN या PRIVATE
"सिर्फ़ ICANN सेक्शन" स्विच, ताकि रजिस्ट्री की नज़र से देखें जहाँ github.io जैसे प्राइवेट suffix सामान्य नाम गिने जाते हैं
अंतरराष्ट्रीय नाम Unicode और punycode में, साथ-साथ
पहले होस्ट से मेल खाने वाले सारे नियमों की सूची, ताकि दिखे कि सबसे लंबा या exception नियम क्यों जीता
पूरी तरह आपके ब्राउज़र में, Public Suffix List (Mozilla Foundation, MPL 2.0) की पेज के साथ आई कॉपी पर, जिसका वर्ज़न दिखाया जाता है
लिखते-लिखते नतीजे, और टेबल का CSV डाउनलोड

इनपुट और आउटपुट

इनपुट

होस्ट नाम या URL: हर लाइन में एक (कॉमा और सेमीकोलन से भी अलग होते हैं), अधिकतम 50। URL अपने होस्ट तक छोटा होता है; पोर्ट, पाथ और यूज़र जानकारी छोड़ दी जाती है।
सिर्फ़ ICANN सेक्शन: डिफ़ॉल्ट रूप से बंद (दोनों सेक्शन, जैसे ब्राउज़र इस्तेमाल करते हैं); रजिस्ट्री की नज़र के लिए चालू करें।

आउटपुट

परिणाम: हर इनपुट के लिए public suffix, रजिस्टर होने लायक़ डोमेन, सबडोमेन, लागू नियम और उसका सेक्शन।
पहले होस्ट का ब्योरा: Unicode और ASCII रूप, लेबल, टॉप-लेवल डोमेन, लागू नियम और उसका प्रकार, मेल खाए सारे नियम और अंतरराष्ट्रीय नामों के punycode रूप।
नोट्स: प्राइवेट, wildcard, exception और बिना सूची वाले suffix, ऐसे नाम जो ख़ुद public suffix हैं, और इनपुट की समस्याएँ।
Public Suffix List का डेटा: पेज के साथ आई सूची का वर्ज़न, नियमों की गिनती, स्रोत और लाइसेंस।

Public Suffix लुकअप का उदाहरण

देश का दूसरा स्तर, एक प्राइवेट suffix और एक exception नियम

इनपुट:

www.example.co.uk
shop.example.github.io
www.city.kobe.jp

आउटपुट:

परिणाम:
www.example.co.uk | co.uk | example.co.uk | www | co.uk | ICANN
shop.example.github.io | github.io | example.github.io | shop | github.io | PRIVATE
www.city.kobe.jp | kobe.jp | city.kobe.jp | www | !city.kobe.jp | ICANN
नोट्स: shop.example.github.io: नियम PRIVATE सेक्शन से है: यह suffix किसी रजिस्ट्री का नहीं, बल्कि ऐसी कंपनी का है जो अपने ग्राहकों को सबडोमेन देती है। · www.city.kobe.jp: exception नियम इस नाम को रजिस्टर होने लायक़ बनाता है, भले ही पड़ोसी नाम wildcard में आते हों: !city.kobe.jp
Public Suffix List का डेटा: सूची का वर्ज़न 2026-10-07_07-28-19_UTC · नियम 6949 ICANN + 3387 PRIVATE

Public Suffix लुकअप के नतीजे कैसे पढ़ें

Public suffix: वह स्तर जिसके नीचे लोग नाम रजिस्टर करते हैं (com, co.uk, github.io)। इसके लिए कोई कुकी नहीं रखी जा सकती, और जो नाम ख़ुद public suffix हो उसका रजिस्टर होने लायक़ डोमेन "—" दिखता है।

रजिस्टर होने लायक़ डोमेन (eTLD+1): वह नाम जिसे रजिस्ट्री बेचती है या प्लेटफ़ॉर्म देता है, और वह "साइट" जिसके हिसाब से ब्राउज़र होस्ट को समूह में रखते हैं। www.example.co.uk और shop.example.co.uk दोनों example.co.uk के हैं।

PRIVATE सेक्शन: suffix किसी कंपनी का है जो ग्राहकों को सबडोमेन देती है; ब्राउज़र उन ग्राहकों को अलग रखते हैं। "सूची में नहीं": टॉप-लेवल डोमेन सूची में नहीं है, इसलिए सिर्फ़ उसका आख़िरी लेबल suffix माना जाता है।

"सिर्फ़ ICANN सेक्शन" के साथ प्राइवेट suffix अनदेखा होता है: तब shop.example.github.io का रजिस्टर होने लायक़ डोमेन github.io है, यानी वह नाम जो GitHub ने रजिस्टर किया।

Public Suffix लुकअप कब इस्तेमाल करें

जाँचना कि कोई होस्ट कुकी में कौन-सी Domain वैल्यू रख सकता है, या ब्राउज़र ने किसी को क्यों ठुकराया।
लॉग या एनालिटिक्स के URL को पूरे होस्ट नाम की जगह साइट (eTLD+1) के हिसाब से समूह में रखना।
अपने कोड के "रजिस्टर होने लायक़ डोमेन" वाले लॉजिक को संदर्भ सूची से मिलाकर जाँचना।
समझना कि मल्टी-टेनेंट प्लेटफ़ॉर्म के सबडोमेन अलग-अलग साइट क्यों माने जाते हैं।

समस्या निवारण

"मान्य होस्ट नाम नहीं": लाइन में स्पेस, लगातार दो डॉट, 63 अक्षरों से लंबा लेबल या ऐसे अक्षर हैं जो होस्ट नाम में नहीं हो सकते। टेबल के नीचे का नोट समस्या बताता है।
जो suffix आप चाहते थे वह नहीं है: हो सकता है पेज के साथ आई कॉपी उसके जुड़ने से पुरानी हो। दिखाए गए वर्ज़न को publicsuffix.org से मिलाएँ।
IP एड्रेस के लिए कोई public suffix नहीं दिखता: सूची सिर्फ़ डोमेन नामों के लिए है।
प्राइवेट प्लेटफ़ॉर्म (github.io, blogspot.com) के होस्ट पर प्लेटफ़ॉर्म ही suffix दिखता है: यही अपेक्षित है; रजिस्ट्री की नज़र के लिए "सिर्फ़ ICANN सेक्शन" चुनें।

Public Suffix लुकअप के बारे में अक्सर पूछे जाने वाले सवाल

सूची के ICANN और PRIVATE सेक्शन में क्या फ़र्क़ है?

ICANN सेक्शन में टॉप-लेवल डोमेन और वे नाम हैं जिनके नीचे रजिस्ट्री नाम बेचती हैं (co.uk, com.sa)। PRIVATE सेक्शन में ऐसे डोमेन हैं जिनके मालिक अलग-अलग ग्राहकों को सबडोमेन देते हैं, जैसे github.io या blogspot.com, ताकि ब्राउज़र हर ग्राहक के सबडोमेन को अलग साइट मानें। रजिस्ट्री की नज़र के लिए "सिर्फ़ ICANN सेक्शन" चुनें, जहाँ example.github.io, github.io का हिस्सा है।

कुकी के लिए यह सूची क्यों मायने रखती है?

ब्राउज़र ऐसी कुकी ठुकरा देते हैं जिसका Domain attribute कोई public suffix हो, इसलिए कोई भी साइट पूरे co.uk या github.io के लिए कुकी नहीं रख सकती। रजिस्टर होने लायक़ डोमेन से ही तय होता है कि दो होस्ट SameSite कुकी और ब्राउज़र की कुछ और सीमाओं के लिए "एक ही साइट" हैं या नहीं।

टूल सूची का कौन-सा वर्ज़न इस्तेमाल करता है?

publicsuffix.org से बनी एक कॉपी, जो पेज के साथ आती है; उसका वर्ज़न और नियमों की गिनती "Public Suffix List का डेटा" में दिखती है। उस कॉपी के बनने के बाद सूची में जुड़ा कोई suffix तब तक टूल को पता नहीं होता, जब तक कॉपी अपडेट न हो।

wildcard और exception नियम का क्या मतलब है?

*.kobe.jp जैसा wildcard नियम kobe.jp के ठीक नीचे के हर नाम को अपने-आप में एक public suffix बना देता है। !city.kobe.jp जैसा exception नियम एक नाम को वापस बाहर निकाल देता है, इसलिए city.kobe.jp रजिस्टर होने लायक़ है। टूल फ़ैसला करने वाला नियम बताता है और मेल खाए सारे नियम दिखाता है।

क्या मेरा लिखा कुछ भी किसी सर्वर पर भेजा जाता है?

नहीं। सूची और एल्गोरिद्म आपके ब्राउज़र में चलते हैं, और टूल कोई नेटवर्क अनुरोध नहीं करता।

तकनीकी नोट्स

एल्गोरिद्म वही है जो publicsuffix.org बताता है: जिस नियम के लेबल नाम के दाईं ओर के लेबल से मेल खाएँ, वह उम्मीदवार है ("*" लेबल किसी भी एक लेबल से मेल खाता है); exception नियम (!) बाक़ी सब पर भारी पड़ता है और अपना सबसे बायाँ लेबल हटा देता है; वरना सबसे ज़्यादा लेबल वाला नियम जीतता है; कोई मेल न हो तो implicit नियम "*" टॉप-लेवल डोमेन को public suffix बना देता है। रजिस्टर होने लायक़ डोमेन public suffix और उससे पहले का एक लेबल है।

मिलान से पहले नाम छोटे अक्षरों में बदले जाते हैं, NFC में लाए जाते हैं और punycode (IDNA, RFC 5891) में बदले जाते हैं, क्योंकि सूची ASCII रूप में रखी है; नतीजे उसी रूप में दिखते हैं जिसमें आपने लिखा। ब्राउज़र यही सूची कुकी का दायरा तय करने (RFC 6265 ऐसा Domain attribute ठुकराता है जो public suffix हो) और SameSite कुकी के लिए "साइट" परिभाषित करने में इस्तेमाल करते हैं।

सीमाएँ और कार्यप्रणाली

जवाब उतना ही ताज़ा है जितनी पेज के साथ आई सूची; दिखाए गए वर्ज़न के बाद publicsuffix.org पर जुड़ी चीज़ें टूल को पता नहीं होतीं।

सूची बताती है कि रजिस्ट्रेशन कहाँ होते हैं, यह नहीं कि नाम किसका है या मौजूद भी है या नहीं: उसके लिए WHOIS / RDAP लुकअप या DNS लुकअप इस्तेमाल करें।

हर बार अधिकतम 50 लाइनें; इससे ज़्यादा लाइनें चेतावनी के साथ छोड़ दी जाती हैं।

सुरक्षा और गोपनीयता

सब कुछ आपके ब्राउज़र में, पेज के साथ आई सूची पर चलता है; आपका लिखा कुछ भी Mutqan या किसी और को नहीं भेजा जाता।

संदर्भ

Public Suffix ListMozilla Foundationpublic suffix क्या है (com, co.uk, pvt.k12.ma.us), ब्राउज़र "supercookies" रोकने के लिए सूची का इस्तेमाल क्यों करते हैं, और यह कि सूची Mozilla की पहल है जिसे समुदाय संभालता है।
View the Public Suffix ListMozilla Foundationसूची ख़ुद और उसका फ़ॉर्मेट: ICANN और PRIVATE सेक्शन, wildcard (*) और exception (!) नियम, और वह एल्गोरिद्म जो लागू होने वाला नियम चुनता है।
RFC 6265: HTTP State Management MechanismIETF · 2011कुकी कैसे सेट और भेजी जाती हैं: Set-Cookie के एट्रिब्यूट (Expires, Max-Age, Domain, Path, Secure, HttpOnly) और उनके स्कोप नियम।