Summary
- Registro.br binds AS269624, CNPJ 32.195.565/0001-68, IPv4 block 45.190.100.0/22 and IPv6 block 2804:6760::/32 to the same truncated DDR FIBRA legal string. A secondary company mirror expands the name, reports active status and uses DDR NET as the trade name, but that mirror is not the originating federal registry.
- RIPEstat observed the IPv4 /22 and two /23 more-specifics during the checked 12-26 July 2026 interval. At 26 July 16:00 UTC it counted 1,024 visible IPv4 addresses, no visible IPv6 prefix and one adjacent ASN. Those observations show routing state, not customers, coverage, contracts, physical diversity or capacity.
- The registered domain ddrnet.com.br redirected to a Muvnet website during the check. That is a useful brand-boundary signal, but it does not prove ownership, merger, asset transfer or corporate control. The public record leaves the relationship between DDR, DDR NET and Muvnet unresolved.
1. The Identity Starts With an Exact Company Record
The name DDR FIBRA OTICA SERVICO E COMERCIO DE TELECOMUNICA appears in more than one public data surface, but exact matching still matters. The BTW directory has a country-suffixed company record for Brazil and a separate plain-slug record with the same visible name. This report binds only the published company Entity cmqk4832m029mt26bicbubevq. The second record is not silently merged merely because its label is similar.
That separation protects every later claim. A route, legal identifier or website observation attached to the wrong directory entity would create a coherent-looking but false profile. The country-suffixed record resolves on a public, indexable directory route and carries the expected legal string. It is the entity against which the network and company evidence is tested.
Registro.br provides the strongest identity anchor in the available material. Its autonomous-system record names DDR FIBRA OTICA SERVICO E COMERCIO DE TELECOMUNICA and CNPJ 32.195.565/0001-68. The related IPv4 and IPv6 entities repeat the same registrant and identifier. Agreement across three resource types reduces the risk that AS269624 or either address block belongs to an unrelated namesake.
The legal string in those registry entities is visibly truncated. A secondary structured CNPJ mirror uses the longer form DDR FIBRA OTICA SERVICO E COMERCIO DE TELECOMUNICACAO LTDA. It also reports the same CNPJ. The matching identifier makes continuity plausible, but the difference should remain visible rather than being normalized away. Legal spelling, display name and brand are separate fields.
The mirror reports the company as active and lists DDR NET as its trade name. Those details are useful context, not a substitute for the authoritative origin record. The mirror is attributed precisely because it can lag, transform or simplify source data. The strongest conclusion is that one CNPJ links the longer company spelling to the network-resource registrant; the public material does not disclose every historical name change or branding decision.
Exact identity is therefore the first operating control. Counterparties can use the CNPJ and ASN together when checking contracts, abuse contacts or route changes. Customers can ask whether the name on an invoice matches the resource holder. None of that establishes service quality, but it makes ambiguity measurable instead of letting a marketing label float free of an accountable legal party.
2. AS269624 Is an Administrative Boundary, Not a Network Diagram
An autonomous system number identifies a party that can originate routes under a distinct routing policy. AS269624 gives DDR a durable control-plane identity that other networks and route collectors can observe. It is more concrete than a general claim to offer connectivity because the number is tied to a named registrant and a legal identifier.
The ASN does not reveal the equipment beneath it. It says nothing about router locations, access technology, fibre ownership, leased transport, radio links, customer-premises equipment or maintenance teams. A small regional operator can combine owned facilities with several wholesale dependencies. The same ASN can remain visible while the physical components behind a customer's connection change.
Nor does the ASN prove that every product sold under DDR NET, Muvnet or another label is delivered through AS269624. A company can use different network arrangements for residential access, enterprise links, hosting or resale. A brand can also direct customers to services operated by another legal party. Product-to-ASN mapping needs evidence at the exact service level.
The registry timestamps should not be treated as commercial milestones. Creation and update dates describe administrative entities. A contact correction can alter an RDAP record without a new route, customer or site. Conversely, a network can change physically while the registration remains untouched. Technical chronology requires route history and operational evidence, not a single registry date.
What AS269624 does offer is a monitoring key. If a prefix changes origin, appears through a different path or disappears from public collectors, observers know which administrative domain normally presents it. If an abuse case arises, the registered contact chain has a starting point. This is accountability value even when the retail business remains opaque.
The disciplined interpretation is narrow: DDR has an assigned autonomous-system identity connected to the same CNPJ as its registered address resources. The number was visible in public routing data during the checked interval. It does not prove the shape, reach, capacity, ownership or resilience of any physical network.
3. One IPv4 Allocation Creates a Clear Responsibility Surface
Registro.br assigns 45.190.100.0/22 to the DDR registrant. The block spans 45.190.100.0 through 45.190.103.255 and contains 1,024 IPv4 addresses. The allocation entity repeats CNPJ 32.195.565/0001-68 and points to AS269624, creating a direct line from legal identity to numbering responsibility.
That arithmetic must not be converted into a subscriber count. Public addresses can be assigned to router interfaces, servers, management systems, customer endpoints, shared translation pools, infrastructure services, tests or reserves. Many users may share one address, while an enterprise can receive several. Utilization cannot be inferred from allocation size.
The block is also not a coverage polygon. Internet addresses do not encode streets, neighbourhoods or municipalities. A registrant based in Carapicuiba can use resources through multiple technical and commercial arrangements. The allocation does not prove where service can be ordered, which access medium is used, or whether a particular premise is on-net.
The value of the /22 lies in attribution. Abuse desks, hosting providers, security teams and peers can identify the registered holder of an address inside the range. Route-origin observations can be compared with the expected ASN. Reverse-DNS or contact changes can be checked against the same baseline. That makes the resource an accountability asset even without retail disclosure.
IPv4 scarcity adds economic context but not a valuation. A directly held /22 may reduce dependence on provider-assigned space and give an operator more control over addressing. Yet the public record does not reveal acquisition terms, current use, transfer restrictions, address policy or revenue generated from the block. A scarce resource is not automatically a large business.
For customers and counterparties, the practical question is whether the contracted service uses resources controlled by the contracting entity and how address assignments are managed. A dedicated-address promise, static service or routed subnet should be stated in the order terms. The registry confirms the pool exists; it does not confirm what any customer receives.
4. The /22 and Two /23s Show Routing Policy, Not Expansion
RIPEstat's announced-prefixes data shows 45.190.100.0/22 and two /23 more-specifics during the checked 12-26 July 2026 interval. At the 26 July 16:00 UTC routing-status snapshot, three IPv4 prefixes and 1,024 announced IPv4 addresses were visible. The parent allocation was therefore not merely dormant administrative space.
The two /23 routes divide the /22 at the control-plane level. Operators often use more-specific announcements to separate policy, influence path selection, stage migration or provide operational flexibility. The public list does not state which reason applies. Prefix length cannot identify a customer segment, city, exchange point or physical circuit.
The presence of both parent and more-specific routes should not be described as growth. A route split can occur without adding a customer, address or kilometre of access plant. Likewise, aggregating the same space into one announcement would not mean contraction. Route count is a configuration signal, not a commercial scale measure.
Time is part of the claim. The data establishes visibility through collectors during a defined interval and at one snapshot. It does not guarantee continuous reachability from every network, universal propagation or persistence after the query. A collector can miss paths, and a route can remain visible while users behind a failed access segment are offline.
The pattern nevertheless creates a useful baseline. A later origin change, unexpected withdrawal or new subdivision can be detected against the known /22 and /23 set. Such a change would justify investigation. It would not, by itself, prove an outage, hijack, expansion or repair.
DDR's visible IPv4 footprint is therefore specific but limited. The registered block and the observed route set align under AS269624. This supports the statement that the resource identity was active in the global routing system. It does not establish traffic, route preference, customer reach, physical diversity or service availability.
5. IPv6 Is Registered but Was Not Visible
Registro.br also assigns 2804:6760::/32 to the same registrant and CNPJ. A /32 is a normal-sized provider allocation in IPv6 terms and can be subdivided across many networks. The registration gives DDR an administrative basis for IPv6 deployment and aligns with the dual-stack identity implied by the resource portfolio.
The dated routing snapshot told a different story. RIPEstat reported no visible IPv6 prefix for AS269624 at 26 July 2026 16:00 UTC. The announced-prefixes response used here did not establish a current IPv6 route. Registration and route visibility therefore diverged at the checked time.
That divergence is material. An allocated block can be held before deployment, used only in a limited environment, announced outside the collector's view, temporarily withdrawn or configured under another arrangement. The available material does not identify which explanation applies. It only prevents a registered /32 from being described as proven customer deployment.
Even a visible IPv6 route would not answer every product question. Customers need to know whether their exact service receives IPv6, what prefix size is delegated, whether assignments are stable, how reverse DNS works, and which equipment is supported. None of those features follows automatically from an allocation or origin announcement.
IPv6 scale is especially easy to exaggerate. The huge numerical address capacity of a /32 reflects IPv6 architecture, not millions of customers or extensive infrastructure. Comparing raw IPv6 and IPv4 address counts produces a dramatic but meaningless business statistic. Deployment practice and supported service boundaries matter more than theoretical space.
The fair conclusion is simple: DDR holds registered IPv6 resources, while the checked route view showed zero visible IPv6 prefixes. That is neither proof of failure nor proof of readiness. It is a dated gap that can be monitored and a concrete question for product-level diligence.
6. RPKI Returned Unknown, Which Is Its Own Category
The RPKI validation query tested AS269624 with 45.190.100.0/22. Routinator returned unknown and no validating route-origin authorization. Unknown is not a synonym for valid, and it is not a synonym for invalid. Keeping that three-way distinction is central to an accurate routing-security description.
A valid result would mean a covering ROA authorizes the tested origin and prefix length. An invalid result would mean a relevant ROA conflicts with the origin or length. Unknown generally indicates that no applicable validating entity was found. The route may still be legitimately originated, but the cryptographic authorization signal is absent from this check.
The absence of a validating ROA does not prove insecurity. DDR or its providers may use filters, monitoring, contact procedures and change controls that are not visible in the RPKI response. Conversely, a future valid ROA would not prove that every routing safeguard or incident process is strong. RPKI is one control within a larger discipline.
For peers and customers, the unknown state creates a concrete diligence question. Does the resource holder intend to create ROAs for the parent and expected more-specifics? What maximum prefix length would match normal routing policy? Who controls changes, and how are accidental origin changes detected? Those questions are more useful than attaching a broad security label.
The current route set makes precision important. If both /23s are intentional, an authorization that covers only the /22 without an appropriate maximum length could create invalid more-specifics. The public material does not disclose a planned policy. Any recommendation should therefore be framed as a verification task, not a configuration prescription.
Future checks can compare the same origin-prefix pair against this baseline. A move from unknown to valid would be a measurable administrative change. A move to invalid would require immediate investigation. Until then, the defensible statement is that the checked parent-origin pair had no validating ROA.
7. One Observed ASN Neighbour Is Not a Contract Map
RIPEstat's neighbour view reported one left-side adjacent autonomous system, AS265475, at the checked query time. That observation means public collectors saw AS269624 next to AS265475 in relevant AS paths. It does not reveal the contract, handoff, traffic direction or physical path behind the adjacency.
Calling the neighbour an upstream or peer would go beyond the evidence. Relationship classifications inferred from route paths can be useful, but they are not the same as signed commercial terms. A route-server context, customer relationship or other arrangement can produce adjacency that looks different from the underlying business.
The single visible neighbour also cannot be described as a sole dependency. Collector visibility is incomplete, and a network can have private paths, backup arrangements or relationships that did not appear in the snapshot. The reverse is also true: several visible neighbours can share one conduit or facility. Logical count is not physical diversity.
This matters because resilience claims often leap from BGP to civil infrastructure. An operator might announce through one ASN while receiving service over redundant circuits, or through several ASNs that converge on one vulnerable route. Proving diversity requires handoff locations, carrier contracts, path separation and failure tests. None is available here.
The observation still has monitoring value. A later snapshot can show whether AS265475 remains adjacent, disappears or is joined by others. Changes can raise questions about routing policy or supplier arrangements. They cannot be labelled as procurement events, migrations or outages without corroboration.
For DDR, the safe account is that one adjacent ASN was publicly observed at a specific time. The public view does not establish commercial status, exclusivity, capacity, redundancy, failover or control. Treating the adjacency as a clue preserves its value without inventing a dependency map.
8. DDR NET Is a Trade Name, but the Brand Surface Is Fragmented
The secondary CNPJ mirror reports DDR NET as the trade name associated with CNPJ 32.195.565/0001-68. That gives the shorter label a legal-context anchor and helps explain why the registered domain uses ddrnet. It does not by itself show how consistently the trade name is used in current contracts, support channels or network operations.
The RIR and address-resource entities retain the longer truncated company string rather than the trade name. This is normal: registries often prioritize the legal holder. But it creates two public surfaces that customers must reconcile. A legal registrant can be clear in RDAP while the brand encountered during a purchase is different.
Brand fragmentation becomes material when responsibility is tested. An invoice, terms of service, privacy notice, network contact and status page should make it possible to identify the contracting entity. If different names appear, the relationship should be explicit. Otherwise, customers may know which brand sold the service but not which company controls the routing resources.
The available record does not show a current DDR NET product catalogue or a verified customer portal. It also does not prove that the trade name has been abandoned. Absence of a reachable first-party brand page at the checked address is an information gap, not evidence that the business is inactive.
This gap affects counterparties as well as consumers. Network operators handling abuse, peering or incidents need a reliable bridge between the ASN holder and the public-facing business. Legal teams need the same bridge when evaluating contracts. A trade name is useful only if it points back to the responsible legal entity and current contacts.
DDR's public identity can therefore be described as coherent at the CNPJ-resource level and fragmented at the brand-delivery level. The trade name DDR NET is supported by a secondary company record. How that label maps to current service operations remains less well documented.
9. The Redirect to Muvnet Raises a Question, Not an Answer
Registro.br lists ddrnet.com.br as active and names Ivane de Andrade Souza as registrant and technical contact, using a masked individual identifier. The ASN record also names Ivane as a legal-representative contact. These repeated contact signals connect the domain and network registration more strongly than a simple name resemblance would.
A current request to ddrnet.com.br redirected to a live Muvnet website. The IPv4 record also contains a technical contact using a Muvnet-domain address. Together, those observations make a relationship plausible enough to investigate. They do not define that relationship.
A redirect can arise from rebranding, shared administration, partnership, outsourced hosting, a product transition, a temporary campaign or a change in domain use. A technical email domain can reflect operational support without corporate ownership. None of the checked pages provides a legal statement of merger, acquisition, asset transfer or control.
It would therefore be wrong to treat Muvnet's public claims as DDR facts. Coverage maps, speed offers, infrastructure descriptions, support promises or customer testimonials on the destination site cannot automatically be assigned to CNPJ 32.195.565/0001-68 or AS269624. Each claim needs an explicit legal or technical bridge.
The redirect is still important because it changes the due-diligence path. A customer reaching the registered DDR domain encounters another brand. The next questions are obvious: which legal entity appears in the terms, who issues invoices, which ASN supports the purchased service, and which party owns support and restoration obligations?
Until those questions are answered, the correct formulation is that the registered DDR domain redirected to a Muvnet web surface during the check. That is a brand-boundary observation, not proof that either company owns or controls the other. Preserving the uncertainty is more informative than forcing a corporate story from two connected web signals.
10. Carapicuiba Is a Legal Location, Not a Service Map
The secondary company mirror places the longer DDR legal name in Carapicuiba, São Paulo. Carapicuiba sits within the dense western part of the São Paulo metropolitan area, where residential, commercial and wholesale connectivity markets overlap. That context makes a regional-access thesis plausible, but the registered address does not establish coverage.
A company address can be a headquarters, office, legal domicile, support point or administrative location. It does not show where fibre is installed, where radio links reach, which buildings are on-net or which municipalities accept new orders. Turning one address into a service polygon would confuse corporate registration with physical infrastructure.
The accompanying image is deliberately generic for the same reason. It shows an unbranded urban street and distribution cabinet as an illustration of the access boundary. It does not depict DDR, DDR NET or Muvnet premises, equipment, customers or plant. A plausible streetscape is not documentary evidence of a named operator.
Metropolitan density also does not guarantee easy deployment. Pole access, building entry, rights of way, wholesale transport and maintenance constraints can vary block by block. Yet those general conditions should not be projected onto DDR without source-specific material. The public record here identifies no pole contract, duct route, tower, exchange or building footprint.
For a prospective customer, address qualification remains the meaningful test. The provider should confirm whether service is available at the exact premise, which access technology is used, who owns the final segment, and what installation work is required. A Carapicuiba registration is useful for identity and jurisdiction, not for technical eligibility.
The bounded description is therefore regional rather than territorial. DDR is a Brazil-registered network-resource holder associated by a secondary company record with Carapicuiba. Its current retail or enterprise service area is unknown. That distinction keeps local context without drawing an unsupported coverage map.
11. SCM Activity Supports a Telecom Context With Attribution
The secondary CNPJ mirror lists Serviços de comunicação multimídia as the primary activity. In Brazil, SCM is the regulatory service category commonly associated with fixed broadband and multimedia communications. The same mirror lists telecommunications-network maintenance and transport-network activities among secondary codes.
Those classifications align with the ASN and address resources. They make it less likely that the network registrations sit beside an unrelated corporate activity. Combined with DDR NET as the trade name, they support a cautious description of the company as a regional connectivity business.
Activity codes are not an operational inventory. Companies can register broad or multiple activities, some central and others occasional, planned or dormant. The mirror does not state revenue by activity, customer mix, current product availability, staff or assets. It cannot prove that every listed line is actively delivered.
SCM wording also should not be presented as a complete licensing check. Confirming current authorization, scope and compliance would require the relevant official regulatory record. The source set here does not include an Anatel licence file or service-area determination. The activity code is contextual support rather than a substitute.
The active-status flag deserves similar restraint. It is evidence that the mirror regarded the registration as active at the checked update. It does not prove that a website, support channel or every network component was operating normally on the same day. Legal status and service availability are different states.
The strongest combined claim is that the same CNPJ appears in a telecommunications-oriented company record and in authoritative Internet-resource entities. That is enough to place DDR within regional ISP economics. It is not enough to quantify the business, define its licence boundary or certify its current products.
12. The Missing Physical Layer Limits Resilience Claims
Public routing data exposes logical reachability, not the physical dependency chain. The source set does not identify DDR-owned fibre, leased strands, poles, ducts, towers, shelters, data-centre space, power systems or field crews. It also does not identify the handoff between any access network and AS269624.
That omission matters during failure. A route can remain visible while a local access segment, aggregation device or customer power supply is down. Conversely, a route withdrawal can reflect maintenance or routing policy without a physical break. Translating one layer into the other requires evidence that connects a specific service to its underlying path.
Capacity cannot be inferred either. A /22, one adjacent ASN and three visible IPv4 routes say nothing about link speed, oversubscription, peak utilization or sold capacity. Marketing speed tiers, if found on another brand's site, would still not prove backbone capacity or performance for DDR customers.
Resilience requires an even higher standard. Two logical routes may traverse the same conduit. A backup circuit may share power or building entry with the primary. A company may have strong restoration procedures without publishing them. The present record supports neither praise nor criticism because the necessary architecture and incident evidence is absent.
The practical diligence questions are concrete: who owns the last-mile segment, where is the handoff, which dependencies are shared, what backup power exists, how is failure detected, and which party coordinates restoration? Enterprise buyers can ask for a responsibility matrix and service-specific commitments. Residential buyers need at least clear installation and escalation ownership.
DDR's route visibility creates a useful administrative starting point for those questions. It does not answer them. The physical layer remains unknown, and that uncertainty should stay explicit rather than being filled with assumptions based on the company name or a generic urban image.
13. Customer Accountability Begins at the Contract Boundary
A customer experiences a service through a brand, bill, installation visit and support channel. Internet registries operate behind that surface. When the brand and resource holder are different or incompletely linked, the contract becomes the place where accountability must be restored.
The first check is legal identity. The name and CNPJ on the order, invoice and terms should reveal whether the contracting party is DDR's registered company, a Muvnet entity or another organization. A trade name can be used legitimately, but it should not obscure the party responsible for performance and consumer obligations.
The second check is technical scope. The contract should identify the access technology, installation boundary, supplied equipment and any public-address or IPv6 features. If a static address, routed subnet or IPv6 delegation matters, those items should be written rather than inferred from AS269624's registrations.
The third check is dependency ownership. Customers should know whether installation and repair are handled directly or through another network. Enterprise buyers may need handoff locations, escalation contacts and restoration commitments. A single support number is not enough if responsibility moves between several suppliers during an incident.
The fourth check is evidence of current service at the exact premise. A regional label, company address or redirected website cannot replace address qualification. Availability and lead time can vary by street and building. The source set contains no current coverage checker that can be safely attributed to the DDR legal entity.
These checks do not presume a problem. They are ordinary controls when public branding is fragmented. DDR's registered resource identity makes it possible to ask whether the service surface and control plane belong to the same accountable chain. The missing public bridge is the reason the contract matters.
14. Counterparties Need Better Contact and Change Evidence
Other networks, hosting providers, security teams and regulators interact with AS269624 differently from retail customers. Their concern is not only whether a connection works, but whether route, abuse and registry changes reach the responsible operator. Exact contacts and a documented escalation path reduce delay when something changes.
Registro.br provides named administrative and technical contacts across the ASN, address and domain entities. Repetition of Ivane de Andrade Souza across the ASN and domain surfaces is a meaningful identity signal. The IPv4 record's Muvnet-domain technical contact adds context while leaving organizational ownership unresolved.
A contact field is not proof of responsiveness. Addresses can age, roles can change and mail can be routed through shared teams. A proper diligence process can test published channels without exposing personal information, record whether the message reaches an accountable function, and distinguish a working escalation mechanism from a stale registry entry.
Route-change evidence should also be timestamped. If the /22 or its /23s changes origin, the observation should be compared with registry status and, where possible, an operator notice. The change itself is a fact; its cause is not. Labeling it a leak, migration or incident requires corroboration.
The unknown RPKI result is another change surface. A later valid authorization would improve origin-verification evidence. A later invalid state would demand attention. Contact quality determines whether such a discrepancy can be resolved quickly. Routing security and organizational accountability meet at that operational handoff.
DDR could reduce uncertainty without disclosing sensitive topology. A clear legal footer, role-based network contacts, a concise status surface and an explanation of the DDR NET/Muvnet relationship would answer many questions. None requires publishing customer lists, router locations, capacities or private contracts.
15. Regional ISP Economics Are Shaped by Hidden Dependencies
Regional operators can create value by reaching customers that larger national networks serve poorly or inflexibly. They may combine local knowledge, smaller service teams and targeted infrastructure with wholesale transport. The commercial result depends not only on assets but on how ownership and supplier boundaries are managed.
The DDR evidence shows why number resources are only one part of that picture. Direct control of an ASN and address blocks can improve portability, routing policy and external accountability. It can reduce dependence on provider-assigned addressing. But those benefits do not reveal the cost or reliability of the underlying access and transport.
Brand ambiguity can add transaction costs. Customers, landlords, suppliers and peers spend time identifying the responsible party. Support cases can move between names. Procurement teams may ask for additional legal documents. Clear mapping between DDR, DDR NET, Muvnet and AS269624 would lower those costs even if the physical network stayed unchanged.
The visible IPv4 route set may also support operational flexibility, but it cannot be priced from outside. The /23 subdivisions could reflect ordinary policy rather than multiple paid paths. One observed neighbour could coexist with private alternatives or represent only the collector's view. Revenue, margins, subscriber count and capacity remain unknown.
IPv6 registration without visible routing illustrates another economic choice. Deployment can require equipment, support training and customer-edge work, while the address resource itself is already available. The snapshot does not reveal whether IPv6 is planned, partially used or temporarily absent. It only separates administrative readiness from observed operation.
DDR is therefore best treated as a bounded regional-network case, not a scale ranking. Its public resources establish a responsible routing identity. The unresolved delivery and brand boundaries determine how much further customers and counterparties must investigate before assigning commercial or operational confidence.
16. A Monitoring Agenda Can Turn Uncertainty Into Evidence
The current record is a baseline, not a final verdict. Future checks can repeat the exact AS269624, 45.190.100.0/22 and 2804:6760::/32 queries. Comparing route visibility, origin, more-specifics and RPKI status over time will show what changed without pretending that every change has an immediately known cause.
The web boundary can be monitored separately. If ddrnet.com.br continues to redirect, a clear legal statement on the destination site could establish the relationship that is currently missing. If the domain changes or returns its own surface, legal footers and support terms can be compared with the CNPJ and registry contacts.
Company identity should be checked against an authoritative federal record when available. That would confirm the longer legal spelling, status, address, trade name and activities now attributed to a secondary mirror. Any difference should be recorded rather than silently reconciled. The CNPJ remains the key that connects the records.
Product-level evidence would close the largest gap. A current address qualification, contract sample, service specification or verified first-party statement could define coverage, access technology, IPv6 availability and support responsibility. Such material should stay tied to its date, product and location instead of becoming a universal company claim.
Physical resilience would require different evidence again: path ownership, handoff sites, power boundaries, diversity, monitoring and restoration performance. Route count cannot substitute for that work. A credible assessment should follow the dependency from the customer premise to the routed network and note where control passes to another party.
Several low-burden disclosures would materially improve the picture. A role-based network contact could replace reliance on personal names. A legal notice could state which company operates the DDR NET brand and why the registered domain leads to Muvnet. A short IPv6 note could distinguish allocation, backbone use and customer availability. Each item would answer a separate question without exposing security-sensitive topology.
Route monitoring should preserve the difference between absence and failure. If IPv6 remains invisible, that may indicate non-deployment, selective deployment, a collector limitation or a temporary state. If the IPv4 more-specifics disappear, aggregation may have improved rather than service having contracted. The observation should be logged first; interpretation should follow only when another source explains the change.
Customer evidence also needs careful sampling. One working connection can prove availability at one address and time, but it cannot establish a whole municipal footprint. One complaint can document an incident, but it cannot establish normal performance. A useful record would combine exact location, product, date, contracting entity, addressing features and restoration outcome while protecting customer privacy.
The same discipline applies to commercial relationships. A neighbour in an AS path can motivate a question to DDR or AS265475, but only an attributable statement or contract-level evidence can define the role. Website redirects and shared technical domains are similarly directional clues. Their value comes from identifying what to verify next, not from allowing a corporate relationship to be inferred.
This layered approach makes the uncertainty productive. Legal identity, number-resource registration, route visibility, brand presentation, customer delivery and physical dependency can each be updated independently. When one layer changes, the others do not automatically inherit that change. The resulting profile may be less dramatic than a map or capacity estimate, but it is far more useful for procurement, incident response and accountable infrastructure reporting.
For now, DDR's strongest public fact is the alignment of one CNPJ, AS269624 and registered address space with dated IPv4 visibility. Its most consequential unknown is the bridge from that routing identity to the DDR NET and Muvnet service surfaces. The network-resource boundary is visible. The delivery boundary remains the work still to be proved.
Sources
- https://btw.media/api/directory/companies?search=DDR%20FIBRA%20OTICA%20SERVICO%20E%20COMERCIO%20DE%20TELECOMUNICA&page=1&pageSize=20&locale=en
- https://btw.media/en/directory/ddr-fibra-otica-servico-e-comercio-de-telecomunica-br
- https://ddrnet.com.br/
- https://milacnic.lacnic.net/lacnic/asociados/publico?locale=EN
- https://publica.cnpj.ws/cnpj/32195565000168
- https://rdap.registro.br/autnum/269624
- https://rdap.registro.br/domain/ddrnet.com.br
- https://rdap.registro.br/ip/2804:6760::/32
- https://rdap.registro.br/ip/45.190.100.0/22
- https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS269624
- https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS269624
- https://stat.ripe.net/data/routing-status/data.json?resource=AS269624
- https://stat.ripe.net/data/rpki-validation/data.json?resource=AS269624&prefix=45.190.100.0/22
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
