.in WHOIS Lookup
.in is the country-code extension of India, administered by NIXI. Look up a .in address and see what the record contains.
- 1.494 extensions
- IANA 1601 ICANN accredited
- 2 protocols — RDAP and WHOIS
Your IP address 216.73.216.31
.in WHOIS Lookup: NIXI Records and Contact Roles
.in is India's country code extension, delegated into the root zone on 8 May 1989 and operated by the National Internet Exchange of India (NIXI). Port 43 queries are answered by whois.nixiregistry.in, and an RDAP endpoint runs at rdap.nixiregistry.in. In our measurement on 12 August 2026 the reply returned fifty-eight field labels, and the zone held a DS record in the root.
That width comes from four contact roles: registrant, admin, technical and billing. Each defines its own lines for name, organisation, street, city, state, postal code, country, phone, fax and email. In the record we measured, however, the values of those lines were closed on privacy grounds — the internal record identifier carried the same phrase. The schema is wide and the content narrow: the fields survive while their values are emptied.
RDAP tells a similar story: the endpoint lists all four roles as entities, yet their name fields do not arrive open. The record we measured carried registration, expiry and last-change events, and the registration had been taken for a ten-year term — so the one-year habit of generic extensions is not a rule here. For an extension with a schema this wide but open content see the .ca WHOIS lookup; for a generic extension using the same privacy phrase, the .biz WHOIS lookup page.
About the .in extension
- Extension
- .in
- WHOIS server
- whois.nixiregistry.in
- RDAP endpoint
- https://rdap.nixiregistry.in/rdap
- Registry
- National Internet Exchange of India (NIXI)
- Delegated
- 8 May 1989
- Fields measured
- 58 field labels (12 August 2026)
- Contact roles
- Registrant, admin, technical and billing; values closed for privacy
- RDAP
- rdap.nixiregistry.in — roles are listed, name fields do not arrive open
WHOIS FAQ
Does a .in WHOIS record show the domain holder?
It does not. Lines for the registrant's name, organisation, address, phone and email are defined in the reply, but in the record we measured their values were closed on privacy grounds. The same held for the admin, technical and billing roles. On the RDAP endpoint the roles are listed as entities, and the name fields still do not arrive open. For contact, the registrar — whose name and abuse details are open in the reply — is the address that works.
Why does a .in record carry fifty-eight fields?
Because the schema defines four contact roles separately and sets aside about ten lines for each. Registrant, admin, technical and billing each appear with an identifier, a name, an organisation, an address, a phone number and an email address. The presence of the fields shows the structure of the record; whether their values are open is a separate matter, and under this extension most are not.
Does a .in record show creation and expiry dates?
It does, and redaction does not touch them. The reply gives the creation date in Creation Date, the last modification in Updated Date and the end of the term in Registry Expiry Date, all in UTC. The record we measured had been taken for a ten-year term — well beyond the one-year habit of generic extensions. Our result screen derives the domain's age and remaining term from those three values.
What does the RDAP endpoint give for .in?
The rdap.nixiregistry.in endpoint returns the same record as JSON and lists all four contact roles as separate entities. Registration, expiry and last change appear among its events. On identity there is no difference: the name fields come back closed on that side too. What differs is form — a structured reply is safer than parsing plain text in automated systems.
What does the privacy phrase in a .in record mean?
It means the registry kept the line in the reply and emptied its value on privacy grounds. In the record we measured, the identity and contact lines carried the phrase, and so did the internal record identifier. A filled-looking field does not mean open data: the phrase is not a value but an explanation of why the value is missing. Tools that miss the distinction store the phrase as if it were an identity.
How are status codes read under .in?
The codes come from ICANN's shared EPP vocabulary, and the prefix tells you who set them. Codes beginning with client are set by the registrar managing the name and lifted by it on request; codes beginning with server are set by the registry and the registrar cannot lift them. Our result screen prints what each code blocks, so you can read why a name cannot be transferred without memorising codes.
Is the .in zone signed with DNSSEC?
It is. A DS record for .in is present in the root zone, which we verified in the 12 August 2026 measurement. That is a fact at the level of the extension; whether an individual address is signed is a separate question and depends on the DS record for that name. We show the two separately on the result screen so a signed zone is never mistaken for a signed address.
How does an available .in name appear in a lookup?
Query a name nobody holds and the registry reports that no match was found, with none of the fifty-eight fields present. That means the name looks free to register. We keep such a result for five minutes only and registered ones for six hours, the short window being there because a name that looks free can be taken quickly.