Summary

  • The official Nethouse.Domains contact page and RIPE organisation object ORG-RL491-RIPE publish the same legal registration number for REGISTRANT LLC, strongly reconciling the registrar and LIR identities.
  • AS210494 and four registered IPv4 allocations describe a network-resource surface; the .RU registrar identifier NETHOUSE-RU describes a domain-custody surface. Neither record proves live routing, common operations, service availability or one recovery path.

One number closes the identity gap

Nethouse.Domains' official contact page names ООО «Регистрант», publishes OGRN 1077847553420 and gives its Saint Petersburg address on Torfyanaya doroga. ORG-RL491-RIPE names REGISTRANT LLC, records reg-nr 1077847553420, classifies the organisation as an LIR and lists the same street, building and office 1319. The RIPE member page identifies the membership as ru.nethouse and the service area as Russia.

This is stronger than a similarity of brand names or email domains. The published state number supplies a common legal anchor. It prevents an analyst from treating the registrar business and the LIR record as unrelated merely because one surface uses the Nethouse name and the other uses the English legal name.

Identity reconciliation is valuable precisely because it lets the next question become more exact: which authority is being exercised when a customer changes a registrant, updates nameservers, restores hosted data or troubleshoots reachability?

A registrar record and an AS record answer different questions

The .RU Coordination Center WHOIS output identifies NETHOUSE-RU as registrar and REGISTRANT LLC as the registrar organisation. The company's own WHOIS guide explains fields for the domain, nameservers, object state, administrator, registrar, a pending transfer destination, creation date and paid-through date. These fields describe custody and change authority around a domain registration.

AS210494, by contrast, is an assigned autonomous-system record using the name NETHOUSE. It references ORG-RL491-RIPE and declares import and export policy with AS35000 and AS29076. The record gives an engineer specific relationships to observe. It is not a transaction log for a nameserver change, evidence that a website's files can be restored, or a measurement of a customer's current path.

The difference is operational, not semantic. A domain can remain registered while its authoritative DNS fails. DNS can answer while a hosting service is unavailable. A host can run while one route becomes unreachable. Conversely, a registrar-account compromise can redirect a working service without a network outage. One supplier name does not turn those incidents into one event.

Four allocations define scope, not service health

RIPE associates four ALLOCATED PA objects with ORG-RL491-RIPE: 185.182.104.0/24, 185.84.110.0/23, 78.108.81.0/24 and 78.108.84.0/23. They establish a registered resource footprint and provide concrete prefixes for investigation.

They do not say which products use which addresses, whether every prefix is currently announced, which origin is visible from a particular vantage point, or whether two declared external relationships are active and physically independent. No availability, latency, capacity, failover or restoration result follows from the allocation status.

A disciplined service map therefore starts with the customer's actual domain and contract. It records the registrar of record and account authority; the authoritative nameserver set and change path; the hosting account, backups and restoration owner; the addresses assigned to the service; observed origins and paths; and the remedy owed when any layer fails.

One supplier needs several receipts

Consolidating domain registration, site tools, hosting and network functions can reduce hand-offs in ordinary operations. It can also hide where responsibility changes inside the same legal entity. A support ticket saying “the site is down” is insufficient when the action required might be restoring account access, reversing a nameserver change, recovering data, withdrawing a bad route or escalating to an external network.

The useful evidence is a chain of separate receipts: who authorised a domain change, what registry state resulted, when DNS changed, which backup was restored, what origin and path were observed, which team accepted the incident, and what contractual clock or remedy applied. The company need not be assumed unreliable. The matched legal number strongly supports attributing both public records to the same legal identity; it does not prove that every technical dependency shares one control room, one failure domain or one recovery promise.

Sources