Summary

  • RIPE registry records bind AS209874 to specific objects: admin-c/tech-c role NA8939-RIPE ("novacloud-hosting"), abuse-c NA8940-RIPE ("novacloud-abuse") with a registered abuse mailbox, organisation ORG-MWUL2-RIPE (Tech Tide Portugal Unipessoal LDA, registration number 517354420), and maintainer novacloud-mnt. The display handle "novacloud-admin" matches no registry object.
  • The operator's own properties split the contact surface across two domains and three mailboxes: a Network Operations Center mailbox on the ASN microsite domain, a registered abuse mailbox on the imprint domain, and a DSA Article 11 legal contact that explicitly states abuse reports will not be processed there.
  • RPKI discipline is present — rpki-client mirrors show ROAs for many prefixes — but closure between registry paperwork and the live routing table is uneven: 5.83.150.0/24 carries an inetnum, geofeed and route object yet is reported absent from the global routing table.
  • No captured source names an individual responsible for the network. Accountability is object-bound, not person-bound; published contact routes do not demonstrate monitoring or responsiveness.

The registry chain: complete, but object-bound

Start with what the RIPE database holds for AS209874. Third-party RDAP mirrors of the registry show an aut-num created on 24 April 2025 with as-name TECHTIDE, last modified 26 February 2026, tied to organisation ORG-MWUL2-RIPE — Tech Tide Portugal Unipessoal LDA, registration number 517354420. Administrative and technical contact is consolidated in one role object, NA8939-RIPE, named "novacloud-hosting" and created on 13 September 2024. Abuse contact is a separate role object, NA8940-RIPE, named "novacloud-abuse", listing a dedicated abuse mailbox. Three maintainers protect the objects: RIPE-NCC-END-MNT, SBL-MNT and novacloud-mnt (IP.sb RDAP mirror; bgp.tools).

This is, formally, a complete accountability chain. Every query a downstream network or an abuse reporter might run — RDAP for the AS number, a WHOIS lookup on an announced prefix — terminates in objects that name a legal entity and provide two mailboxes. The chain is machine-readable, which is precisely what registry accountability is supposed to be.

The gap is between this chain and the brand. The name under which the operator is publicly discussed and directory-tracked is "novacloud-admin". That handle appears in no RIPE role, person or mailbox object. The closest registry match is the maintainer novacloud-mnt, which authorises changes to objects but is not an administrative contact and does not answer mail. A customer searching the registry for the name they know finds nothing; a reporter following the registry finds role objects whose names differ from the brand. Prior BTW analysis of this gap concluded that accountability for this operator is object-bound: what answers is a chain of registry entities, not the display name (BTW: who holds administrative authority).

Three mailboxes, two domains, one routing failure surface

The registry names one abuse mailbox. The operator's own web properties name more, and they do not agree on where questions go.

The ASN microsite, as209874.net, presents AS209874 as "NovaCloud-Hosting Network", advertising IP transit across Europe with three points of presence in Germany and the Netherlands, GRE, GRETAP, VXLAN and WireGuard tunnels, and "always-on" DDoS mitigation. Its published operations contact is a Network Operations Center mailbox (as209874.net).

The imprint on the main commercial domain, novacloud-hosting.com, tells a different routing story. It designates a Digital Services Act Article 11 contact point in English — and states explicitly that messages unrelated to Article 11, "such as abuse reports, copyright complaints, or user support inquiries, will not be processed via this address". Abuse reports and copyright complaints are redirected to a separate abuse mailbox (Imprint & Legal Notice).

So a reporter with a routing security issue, a customer with an outage, and a competent authority with a legal notice each have a different destination, and two of the three mailboxes live on different domains. The NOC address on the ASN microsite is not referenced by the registry; the registered abuse mailbox is not referenced by the ASN microsite. Nothing in the captured sources establishes that any of these mailboxes is monitored, how quickly they respond, or who reads them. That is not an accusation — it is the absence of any evidence either way, which for a network selling transit and hosting is itself a measurable property.

There is also a divergence inside the registry's own picture. bgp.tools' rendered copy of the aut-num shows placeholder contacts, DUMY-RIPE, while RDAP mirrors show the named role objects NA8939-RIPE and NA8940-RIPE. This is most likely a presentation difference between mirrors rather than a data conflict, but it illustrates how thin the visible layer is: even the party responsible for answering abuse appears differently depending on which mirror a reporter consults (bgp.tools; IP.sb).

RPKI hygiene and the paperwork-to-routing gap

The operator is not without technical discipline. rpki-client console mirrors — Amsterdam and Frankfurt — show AS209874 publishing ROAs for a long list of IPv4 /24 prefixes, including 5.83.142.0/24, 5.83.150.0/24, 5.175.174.0/24, 94.249.197.0/24 and 194.62.122.0/24, and for IPv6 blocks including 2a09:54c3:a000::/40 with a maximum length of 128 (rpki-client console). ROAs are the signed authorisation layer that lets relying parties validate route origins; publishing them is a baseline hygiene signal.

But a ROA proves authorisation, not announcement. The same /24 that appears fully paperworked in RIPE — 5.83.150.0/24, registered to the operator with an inetnum, a geofeed and a route object — is reported by bgp.tools as not visible in the global routing table. Prior BTW reporting on the registry-versus-routing gap documented this precisely: the prefix exists in every registry layer yet carries no live route (BTW: registry gaps that refuse to close). Separately, three public routing mirrors — bgp.tools, bgp.he.net and Qrator Radar — disagreed with each other on 4 October 2026 about how many IPv4 prefixes AS209874 announces at all (BTW: route mirroring briefing).

The composite picture is an operator that can perform the auditable rituals — ROAs, route objects, role objects — without the underlying system converging: routes that exist on paper but not in the table, mirrors that cannot agree on the footprint, and a contact layer split across surfaces. Hygiene is performable; accountable convergence is not yet demonstrated.

The FFM2 aftermath and the unanswered accountability question

The July 2026 Frankfurt incident gives the contact-surface question practical weight. The operator's own status page labels FFM2 a major outage running from 20 July to 8 August 2026 — nineteen days — resolved on 8 August, attributing tunnel and TCP failures to "false filtering of PletX, which dropped TCP connections". Affected items included the FFM2 VPS hypervisor, the NBG datacenter and Gen-3 VHOST instances. The incident record is duplicated across two Instatus subdomains under the same brand, with contradictory coexisting states — a resolved July incident alongside a still-displayed potential-disruption banner (Instatus incident record; novacloud-hosting status; BTW: catalog vs network).

During nineteen days of degraded service, the question "who do I reach" becomes the customer's primary one. The registry chain answers it with a role object and an abuse mailbox; the operator's own surfaces answer it three different ways. Prior BTW coverage documented the service-by-service restore pattern and the incident narrative's upstream naming; what no coverage had assembled is how these contact surfaces fit together as a system — and they do not.

What a reader should conclude

None of this establishes wrongdoing, and the evidence carries real limits: all registry and routing data in this report are third-party mirrors with unknown lag; published contact routes do not demonstrate responsiveness; and first-party claims about datacenters and DDoS mitigation are unverified. What the evidence does establish is a specific, structural observation: Novacloud's accountability layer is complete in the registry's grammar but fragmented across the operator's own surfaces, and the brand name that carries its public reputation exists in none of the objects that carry its obligations.

For a customer evaluating the operator, or a downstream network deciding how to route abuse reports, the practical question is no longer whether contact objects exist — they do — but which one, on which domain, answers, and no public record currently answers that.

Sources