How to Use .in Registry WHOIS Data and India Domain Lists

India runs one of the largest national domain spaces in the world, and the registry behind it publishes a WHOIS service anyone can query. What that service will and will not tell you has changed considerably in recent years, and most guides still describe it as it worked a decade ago. This article explains how .in registry WHOIS actually works today, what fields survive redaction, why bulk collection through WHOIS is impractical, and how to assemble a workable dataset of Indian domains from zone-level files instead.

TL;DR / KEY TAKEAWAYS

• NIXI operates the .in namespace: The National Internet Exchange of India runs .in and its second-level spaces — .co.in, .net.in, .org.in, .firm.in, .gen.in, .ind.in — plus a set of internationalised TLDs for Indian scripts.
• WHOIS is a per-domain protocol: One query returns one record. It is rate-limited, sometimes CAPTCHA-gated, and returns free-text that varies by registrar.
• Registrant fields are largely redacted: Name, email, phone and postal address are withheld for most domains. India's Digital Personal Data Protection Act, 2023 reinforces that direction rather than reversing it.
• What still comes back reliably: creation, update and expiry dates, registrar, domain status codes, and name servers.
• Zone-level files answer the questions WHOIS cannot: which domains exist, what name servers and mail servers they use, where they resolve, and which CMS is detectable.
• WebTrackly distributes those files: 1,538 packages — 716 TLD zone files, 716 enriched zone sets (NS, MX, IP, CMS), 79 technology site lists, 27 curated datasets — covering 279,944,703 domains in total.
• No contact data: the packages contain domain and infrastructure attributes only. No email addresses, no phone numbers, no registrant identities.

TABLE OF CONTENTS

• How .in Registry WHOIS Works, and What It Returns Today
• Five Research Questions .in Domain Data Can Answer
• What a Zone Data File Contains
• Bulk Files vs. WHOIS Lookups
• Working With .in Domain Data in Practice
• Common Mistakes When Working With .in WHOIS Data
• FAQ: .in Registry WHOIS
• Conclusion
• Related Resources

How .in Registry WHOIS Works, and What It Returns Today

The .in namespace is administered by the National Internet Exchange of India (NIXI) through its registry operation. It covers the open second level (example.in) and a set of structured second-level spaces with intended purposes: .co.in for commercial entities, .net.in for network providers, .org.in for organisations, and .firm.in, .gen.in, .ind.in for narrower categories. NIXI also administers internationalised ccTLDs for Indian scripts, so a complete picture of India's domain space is not limited to the ASCII string ".in".

The registry publishes a WHOIS service, and it follows the thin/thick pattern common to ccTLDs: the registry record carries the authoritative technical facts, while the registrar holds whatever contact data was collected. When you query it, you can rely on a small set of fields being present and accurate: the creation date, the last update date, the expiry date, the sponsoring registrar, the domain status codes (clientTransferProhibited, pendingDelete and so on), and the delegated name servers.

What you can no longer rely on is the contact block. Since GDPR reshaped registry disclosure practice globally, registrant name, organisation, email, telephone and postal address are redacted from public responses for the large majority of domains, replaced by a placeholder or a registrar-operated relay address. India's own Digital Personal Data Protection Act, 2023 pushes in the same direction: personal data of a registrant is personal data regardless of the fact that a domain record contains it. Any workflow that assumes public WHOIS will yield a person to contact is built on an assumption that no longer holds.

The second constraint is mechanical. WHOIS answers one domain per query. To profile 10,000 domains you make 10,000 queries, and registries throttle exactly that behaviour — port 43 access is rate-limited by IP, and the web interface adds a CAPTCHA. Response formatting varies by registrar, so a parser that works on one record breaks on the next. Nothing about the protocol was designed for population-scale collection, and no amount of engineering around it changes that.

This leads to a straightforward division of labour. Use WHOIS when you have a specific domain and need its authoritative registration status — that is what it is good at. When the question is about the population — how many domains exist, what they run, where they resolve, how that changes over time — the answer comes from zone-level data, distributed as files rather than queried one record at a time.

Need the domain list, not one lookup?
Browse the zone file catalog — 716 TLDs with row counts published before purchase.
Browse Zones → | View Pricing →

Five Research Questions .in Domain Data Can Answer

Zone-level data is population data. It supports counting, grouping and comparing over time. It does not identify individuals, and none of the workflows below depend on doing so.

1. Measuring CMS and Platform Adoption in a National Namespace

Published figures on which platforms dominate a given country are usually extrapolated from a top-N sample of popular sites, which skews heavily toward large organisations. A zone-level file with a CMS detection column lets you count directly against a known denominator instead. Across the full WebTrackly catalog, WordPress is detected on 21,639,326 domains and Joomla on 607,765; the same computation restricted to a single zone gives that zone's distribution.

Report the denominator and the detection rate every time. "X domains out of Y covered, with Z% of rows carrying a CMS value" is a claim that survives scrutiny. A bare percentage does not.

2. Mapping DNS and Hosting Providers

Name server records are the most reliable provider signal in the dataset. Grouping the NS column by suffix shows which DNS operators — global platforms, regional hosts, individual registrars — carry the zone, and the distribution is usually far more concentrated than expected. Resolved IPs add a second view, though one to interpret carefully: a site behind a CDN publishes the CDN's address, so IP-derived shares measure the edge rather than the origin.

3. Analysing Mail Infrastructure

MX records in the enriched sets show where a domain routes mail. Classify MX hostnames by provider pattern and you get the split between hosted mail platforms, regional providers and self-managed servers across the whole zone. Comparing two snapshots taken months apart shows migration between them, which is the actual question behind most "who is winning in email" discussions. An MX record is a routing target, not a mailbox — there are no addresses in these files.

4. Tracking Growth and Churn

Registration volume is a widely cited proxy for digital activity, and it is one of the few things you can measure yourself rather than take from a press release. Buy the same zone package at two points in time, diff the domain columns, and you have new registrations and drops for the interval, with no dependence on anyone's reported statistics. Keep and date every file you download; a snapshot you discarded is a comparison you can no longer make.

5. Security and Attack-Surface Research

Reconnaissance that starts from WHOIS lookups stops almost immediately at rate limits. Starting from a zone file removes that ceiling: filter locally to the subset that matters — a CMS, a name server, an IP range — and feed that list into your own verification tooling. The file supplies the population; the analysis is still yours to run. Active testing must stay within scope you are authorised to test, and a downloadable list of domains is not authorisation.

What a Zone Data File Contains

Each package is a CSV inside a ZIP. Zone-file packages contain the domain list. Enriched zone packages add name servers, MX records, resolved IPs and detected CMS, populated where they could be determined and empty otherwise.

That is the whole schema. There is no registrant column, no organisation column and no contact column, because that data is redacted at the registry and is not reconstructed here. Registration dates appear only where the source zone publishes them; for many ccTLDs they do not, and the column is absent rather than estimated.

Bulk Files vs. WHOIS Lookups

The two are complements. WHOIS remains the authority on the status of a domain you have already identified. Bulk files are how you identify the population in the first place.

Working With .in Domain Data in Practice

There is no search interface and no server-side filtering. You choose a package, buy it, download the ZIP, and do the analysis on your own machine.

Step 1 — Find the package. /zones/ lists the 716 TLD zone files and their enriched counterparts, with the row count shown before purchase so you know the size. /datasets/ holds the 27 curated cross-zone collections, the largest being all registered domains at 272,614,863 rows. /packages/ is the full catalog including the 79 technology site lists.

Step 2 — Purchase and download. Packages start at $3.50 and download immediately; the file is exported fresh at purchase rather than served from an old build. For recurring use, Pro is $29/month (50 packages, 10 datasets, 30,000 API calls) and Enterprise is $99/month (200 packages, 50 datasets, 300,000 API calls). See /pricing/.

Step 3 — Unpack and inspect.

unzip in-enriched.zip
head -3 in-enriched.csv
wc -l in-enriched.csv

Step 4 — Quick cuts with command-line tools.

# second-level space breakdown
grep -oE '\.(co|net|org|firm|gen|ind)\.in$' in-enriched.csv | sort | uniq -c | sort -rn

# rows where the detected CMS is WordPress
awk -F',' '$5 == "WordPress"' in-enriched.csv > in-wordpress.csv

# top name servers
cut -d',' -f2 in-enriched.csv | sort | uniq -c | sort -rn | head -20

Step 5 — Analytical work in a columnar engine. DuckDB reads the CSV directly, with no import step:

-- mail provider distribution
SELECT
  CASE
    WHEN mx ILIKE '%google%'    THEN 'Google'
    WHEN mx ILIKE '%outlook%'   THEN 'Microsoft'
    WHEN mx ILIKE '%zoho%'      THEN 'Zoho'
    WHEN mx IS NULL OR mx = ''  THEN 'none'
    ELSE 'other'
  END AS provider,
  count(*) AS domains
FROM read_csv_auto('in-enriched.csv')
GROUP BY provider ORDER BY domains DESC;

-- new domains between two snapshots
SELECT n.domain
FROM read_csv_auto('in-2026-07.csv') n
LEFT JOIN read_csv_auto('in-2026-04.csv') o USING (domain)
WHERE o.domain IS NULL;

Step 6 — Script catalog access through the API. The API exposes the package catalog, not a domain lookup. Authentication is a bearer token.

# list zone-file packages
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

# details for a single package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/in-zone/"

Endpoint reference is at /api/. A typical automation lists the packages you track, checks for a newer build, downloads it and loads it into the warehouse beside the previous snapshot.

Common Mistakes When Working With .in WHOIS Data

1. Treating WHOIS as a bulk source.

   • What goes wrong: Rate limits and CAPTCHAs stall the job after a few thousand queries, and you are left with partial coverage that cannot support a percentage claim.
   • The fix: Take the population from a zone-level file and reserve lookups for the small subset where authoritative per-domain status genuinely matters.

2. Expecting registrant contact details.

   • What goes wrong: A pipeline is built around a contact column that is redacted at the source and never arrives.
   • The fix: Design for what the record actually contains — dates, registrar, status, name servers — and treat contact acquisition as a separate problem with its own legal footing under the DPDP Act and GDPR.

3. Ignoring the second-level structure of .in.

   • What goes wrong: Counting only *.in and missing .co.in, .net.in, .org.in and the rest understates the namespace, sometimes substantially.
   • The fix: Enumerate the second-level spaces explicitly and report them separately; they attract different registrant types and behave differently over time.

4. Forgetting the internationalised TLDs.

   • What goes wrong: An analysis claiming to cover "India's domain space" silently excludes the script-based ccTLDs NIXI administers.
   • The fix: State your scope precisely. If you measured only the ASCII .in tree, say so rather than generalising to the country.

5. Reading a creation date as a company's founding date.

   • What goes wrong: A domain registered in 2019 is presented as a business founded in 2019, when it may be a rebrand, a defensive registration or a transfer where the date was reset.
   • The fix: Treat the creation date as the age of the registration record and corroborate before making claims about the organisation.

6. Working from a single snapshot.

   • What goes wrong: You can describe the current state but not the trend, which is usually the question being asked.
   • The fix: Archive and date every download. Growth, churn and provider migration all require two observations.

7. Overstating CMS detection.

   • What goes wrong: A precise-sounding market-share figure collapses when someone with a different detection method disagrees.
   • The fix: An empty CMS field means "not detected," not "no CMS." Report detection rate alongside every share and describe figures as detected installations.

FAQ: .in Registry WHOIS

Q: What is .in registry WHOIS?
A: The public registration database for the .in namespace, operated by NIXI. A query returns the record for a single domain: creation, update and expiry dates, the sponsoring registrar, domain status codes and delegated name servers. Contact fields are redacted for most domains.

Q: Why is the registrant information hidden?
A: Registry disclosure practice changed globally after GDPR, and personal data in registration records is now withheld from public responses by default. India's Digital Personal Data Protection Act, 2023 points the same way. Disclosure typically requires a documented legal basis submitted to the registrar.

Q: Can I query .in WHOIS in bulk?
A: Not practically. Port 43 access is rate-limited by IP and the web interface is CAPTCHA-protected. The protocol is built for occasional per-domain lookups.

Q: Does WebTrackly perform WHOIS lookups for me?
A: No. WebTrackly distributes prepared bulk files. You buy a package, download a ZIP containing CSV, and process it yourself. There is no lookup service and no per-domain query endpoint.

Q: What is in a package?
A: Zone-file packages contain the domain list for a TLD. Enriched zone packages add name servers, MX records, resolved IPs and detected CMS where determinable. Technology packages list sites where a given CMS or technology was detected. Curated datasets are cross-zone compilations.

Q: Are email addresses or phone numbers included?
A: No. The files contain domain and infrastructure attributes only, with no personal or company contact details.

Q: How large is the catalog?
A: 1,538 packages: 716 zone files, 716 enriched zone sets, 79 technology site lists and 27 curated datasets, covering 279,944,703 domains across the zone packages. The all-registered-domains dataset holds 272,614,863 rows.

Q: How current is the data?
A: Each package is exported at the moment of purchase, so you get the current build. To track change, purchase the same package again later and diff the two files.

Q: What does the API do?
A: It exposes the catalog. GET /api/v1/packages/?type=zone lists zone packages, ?type=technology&q=wordpress filters technology packages, and /api/v1/packages/{slug}/ returns details for one package. Bearer token authentication. It does not accept a domain name and return facts about it.

Q: What does it cost?
A: Individual packages from $3.50 as one-time purchases. Pro is $29/month (50 packages, 10 datasets, 30,000 API calls); Enterprise is $99/month (200 packages, 50 datasets, 300,000 API calls). See /pricing/.

Conclusion

.in registry WHOIS is a reliable source for the registration facts of a domain you already have in hand: when it was created, who sponsors it, what status it carries, where it delegates DNS. It is not a discovery tool, it is not a contact database, and no amount of scripting will make it behave as either.

Population-level questions about India's domain space — how many domains, on which platforms, behind which DNS and mail providers, growing or shrinking — are answered with zone-level files you download and analyse locally. The schema is deliberately narrow: domain, name servers, MX, resolved IP, detected CMS, and registration dates only where the source publishes them. Knowing that boundary in advance is what keeps a project from failing at the last step.

Browse the zone file catalog →

Related Resources

• Package Catalog — 1,538 downloadable domain databases
• Zone Files by TLD — .com, .net, .de and 700+ more
• Curated Datasets — all registered domains, MX servers, e-commerce
• API Documentation — catalog access with a bearer token
• Pricing — one-time purchases from $3.50