.in WHOIS Abfrage
.in ist die Länderendung Indiens und wird von NIXI verwaltet. Fragen Sie eine .in-Adresse ab und sehen Sie, was der Eintrag enthält.
- 1.494 Endungen
- IANA 1601 ICANN-akkreditiert
- 2 Protokolle — RDAP und WHOIS
Ihre IP-Adresse 216.73.216.31
.in WHOIS-Abfrage: NIXI-Einträge und Kontaktrollen
.in ist die Länderendung Indiens, am 8. Mai 1989 in die Root-Zone delegiert und vom National Internet Exchange of India (NIXI) betrieben. Abfragen über Port 43 beantwortet whois.nixiregistry.in, zusätzlich läuft unter rdap.nixiregistry.in ein RDAP-Endpunkt. Bei unserer Messung am 12. August 2026 lieferte die Antwort achtundfünfzig Feldbezeichner, und die Zone trug einen DS-Eintrag in der Root.
Diese Breite stammt von vier Kontaktrollen: Inhaber, Admin, Technik und Rechnung. Jede definiert eigene Zeilen für Name, Organisation, Straße, Ort, Bundesstaat, Postleitzahl, Land, Telefon, Fax und E-Mail. Im gemessenen Eintrag waren deren Werte jedoch aus Datenschutzgründen geschlossen — dieselbe Formel trug auch die interne Kennung des Eintrags. Das Schema ist breit, der Inhalt schmal: Die Felder bleiben, ihre Werte werden geleert.
Im RDAP zeigt sich dasselbe Bild: Der Endpunkt listet alle vier Rollen als Entitäten, ihre Namensfelder kommen jedoch nicht offen. Der gemessene Eintrag führte Registrierung, Ablauf und letzte Änderung als Ereignisse, und die Registrierung war für zehn Jahre erfolgt — die Einjahresgewohnheit generischer Endungen ist hier also keine Regel. Eine Endung mit ebenso breitem Schema, aber offenem Inhalt zeigt die .ca WHOIS-Abfrage, eine generische Endung mit derselben Datenschutzformel die .biz WHOIS-Abfrage.
Über die Endung .in
- Endung
- .in
- WHOIS-Server
- whois.nixiregistry.in
- RDAP-Endpunkt
- https://rdap.nixiregistry.in/rdap
- Registry
- National Internet Exchange of India (NIXI)
- Delegiert seit
- 8. Mai 1989
- Gemessene Felder
- 58 Feldbezeichner (12. August 2026)
- Kontaktrollen
- Inhaber, Admin, Technik und Rechnung; Werte aus Datenschutzgründen geschlossen
- RDAP
- rdap.nixiregistry.in — Rollen werden gelistet, Namensfelder bleiben geschlossen
WHOIS FAQ
Zeigt der .in WHOIS-Eintrag den Inhaber der Domain?
Nein. Zeilen für Name, Organisation, Adresse, Telefon und E-Mail des Inhabers sind in der Antwort definiert, im gemessenen Eintrag waren ihre Werte jedoch aus Datenschutzgründen geschlossen. Dasselbe galt für Admin-, Technik- und Rechnungsrolle. Im RDAP-Endpunkt sind die Rollen als Entitäten gelistet, die Namensfelder kommen auch dort nicht offen. Für Kontakt ist der Registrar die richtige Adresse, dessen Name und Abuse-Angaben offen in der Antwort stehen.
Warum führt ein .in-Eintrag achtundfünfzig Felder?
Weil das Schema vier Kontaktrollen getrennt definiert und für jede rund zehn Zeilen vorsieht. Inhaber, Admin, Technik und Rechnung erscheinen jeweils mit Kennung, Name, Organisation, Adresse, Telefon und E-Mail. Das Vorhandensein der Felder zeigt den Aufbau des Eintrags; ob ihre Werte offen sind, ist eine andere Frage — und bei dieser Endung sind die meisten es nicht.
Enthält ein .in-Eintrag Erstellungs- und Ablaufdatum?
Ja, und die Schwärzung berührt sie nicht. Die Antwort nennt die Erstellung in Creation Date, die letzte Änderung in Updated Date und das Laufzeitende in Registry Expiry Date, jeweils in UTC. Der gemessene Eintrag war für zehn Jahre registriert — weit über der Einjahresgewohnheit generischer Endungen. Unsere Ergebnisanzeige errechnet aus diesen Werten Alter und Restlaufzeit.
Was liefert der RDAP-Endpunkt bei .in?
Der Endpunkt rdap.nixiregistry.in gibt denselben Eintrag als JSON zurück und listet alle vier Kontaktrollen als getrennte Entitäten. Unter den Ereignissen stehen Registrierung, Ablauf und letzte Änderung. Bei der Identität gibt es keinen Unterschied: Die Namensfelder kommen auch dort geschlossen. Was sich unterscheidet, ist die Form — eine strukturierte Antwort ist in automatisierten Systemen sicherer als das Parsen von Klartext.
Was bedeutet die Datenschutzformel im .in-Eintrag?
Sie bedeutet, dass die Registry die Zeile in der Antwort belassen und ihren Wert aus Datenschutzgründen geleert hat. Im gemessenen Eintrag trugen die Identitäts- und Kontaktzeilen die Formel, ebenso die interne Kennung des Eintrags. Ein gefüllt wirkendes Feld bedeutet also keine offenen Daten: Die Formel ist kein Wert, sondern die Begründung für dessen Fehlen. Werkzeuge, die das übersehen, speichern die Formel wie eine Identität.
Wie liest man Statuscodes bei .in?
Die Codes stammen aus dem gemeinsamen EPP-Vokabular der ICANN, das Präfix nennt den Urheber. Codes mit client setzt der verwaltende Registrar und hebt sie auf Wunsch auf; Codes mit server setzt die Registry, und der Registrar kann sie nicht aufheben. Unsere Ergebnisanzeige nennt zu jedem Code den gesperrten Vorgang, sodass Sie ohne Auswendiglernen erkennen, warum ein Name nicht transferiert werden kann.
Ist die Zone .in per DNSSEC signiert?
Ja. In der Root-Zone liegt ein DS-Eintrag für .in vor, den wir bei der Messung am 12. August 2026 geprüft haben. Das ist eine Angabe auf Ebene der Endung; ob eine einzelne Adresse signiert ist, hängt vom DS-Eintrag dieses Namens ab. In der Ergebnisanzeige führen wir beides getrennt, damit eine signierte Zone nie mit einer signierten Adresse verwechselt wird.
Wie erscheint ein freier .in-Name in der Abfrage?
Fragen Sie einen nicht vergebenen Namen ab, meldet die Registry, dass kein Treffer gefunden wurde, und keines der achtundfünfzig Felder erscheint. Das bedeutet, dass der Name zur Registrierung frei wirkt. Ein solches Ergebnis halten wir nur fünf Minuten vor, registrierte sechs Stunden — das kurze Fenster, weil ein frei wirkender Name schnell vergeben sein kann.