How to Verify a Hosting Provider’s Infrastructure Claims (ASN, Peering, Certification)

Last reviewed: 30 July 2026. Hosting infrastructure is unusually easy to market and unusually difficult for a buyer to inspect. A provider can publish carrier logos, Tier badges, “owned network” claims and impressive mitigation numbers without explaining which legal entity, site, prefix or product the claim covers. The solution is not to distrust every provider. It is to verify each layer with the correct evidence.

Core principle: Verify the exact service endpoint, not only the provider’s homepage. The ASN serving the marketing site may differ from the ASN carrying your VPS or dedicated server.

Step 1: identify the legal and brand entities

Start with the quotation, invoice, terms of service, privacy policy and support address. Record the trading brand, invoicing entity, network entity, facility operator and any managed-service entity. These names may legitimately differ, but the provider should explain why.

• Who accepts payment and issues the tax invoice?
• Who owns or controls the customer contract?
• Who is the data processor or service provider under privacy terms?
• Who operates the network and appears in RIR records?
• Who owns the facility certificates?
• Who pays service credits under the SLA?

Step 2: resolve and record the service IP

Ask for a test IPv4 and, where offered, IPv6 address in the exact city and product network. Then resolve the endpoint and record the result. Useful commands include:

dig +short example.com A
dig +short example.com AAAA
nslookup example.com

For a service that has not yet been provisioned, ask for a looking-glass target or test IP from the same product range. A generic corporate website IP is insufficient because it may sit behind a CDN.

Step 3: verify the ASN and RIR record

Look up the IP in an RIR or RDAP service and identify the origin ASN. For Indian resources, APNIC and IRINN-related records are common. An ASN page such as APNIC RDAP for AS135682 should show the registered organization, status and contact or maintainer data.

Check whether the organization name matches one of the legal or operating names disclosed by the provider. A mismatch is not automatically a problem—providers can use upstream IP space—but it changes the question. Ask whether your service is on provider-originated space, upstream-assigned space or customer-owned space.

Step 4: inspect prefixes and RPKI

Use more than one BGP visibility source, such as BGP.Tools, Hurricane Electric BGP Toolkit and a route collector. Confirm which prefixes the ASN originates and whether the origin is RPKI-valid. RPKI helps networks reject unauthorized route origins, but it does not prove that the service is secure, available or well operated.

• Valid: the observed origin matches a covering Route Origin Authorization.
• Invalid: the origin ASN or prefix length conflicts with the ROA and may be filtered.
• Not found: no covering ROA is visible; the route may still work but lacks origin validation.

Step 5: check upstreams, peers and exchanges

An upstream provides transit to the global Internet. A peer exchanges selected traffic directly. An Internet exchange supplies the interconnection fabric but does not by itself guarantee a session with every member. Provider websites often blur these terms.

Compare observed routing with the network’s self-published PeeringDB record. For AS135682, public sources currently show connectivity involving Cloudflare, Tata Communications and Bharti Airtel, while broader peer observations include additional networks. Treat counts as a current snapshot: BGP relationships, route visibility and data-source classification change.

Questions to ask

• Which carriers are direct paid transit providers?
• Which networks are direct bilateral peers, route-server peers or mitigation paths?
• At which exchanges and facilities are sessions active?
• Is traffic engineering automated, manually controlled or delegated to an upstream?
• What happens when one carrier or exchange path fails?

Step 6: run latency and path tests

Perform tests from the user networks that matter. For an India-facing workload, test from several broadband and mobile ISPs and from the regions where customers are concentrated. Use multiple times of day and retain the raw results.

ping -c 20 TEST_IP
traceroute TEST_IP
mtr -rwzc 100 TEST_IP

Latency is not a single provider score. A route can differ by source ISP, destination prefix, time, congestion, peering policy and mitigation state. Do not compare two providers using one screenshot from one connection.

Step 7: verify facility claims

Ask for the facility operator, site name and city. Determine whether the provider owns the building, operates the site, leases a suite or cage, colocates individual racks, or rents server capacity. Then check whether the exact product is provisioned at that site.

A credible answer names both responsibility and dependency: who supplies utility and generator power, UPS, cooling, physical access, fire systems, remote hands, cross-connects and hardware replacement. “Tier III” without a certificate holder, facility name and certification type is not enough.

Step 8: inspect certificates as documents, not logos

Open the full certificate. Record the holder, certification body, standard, certificate number, named sites, scope, effective date and expiry date. Confirm that the site you are buying is listed and that the document is still valid.

Advika’s current site links facility documents held by Yotta. The linked ISO 9001 certificate names Yotta Data Services Private Limited and lists multiple Yotta sites. It expires on 21 August 2026. The linked ISO/IEC 27001 copy expires on 31 October 2025, and the linked MeitY empanelment letter states an expiry of 4 December 2025. This does not prove that Yotta has no renewed certifications; it proves that the linked copies are not sufficient current evidence for those claims. Request renewed documents.

Step 9: test DDoS claims

Do not attempt an unauthorized load or attack test. Instead, verify architecture and contract terms. Ask which platform protects the prefix, whether traffic is routed through scrubbing continuously, what attack layers are covered, whether clean-traffic capacity is limited, how false positives are handled, and which services are excluded.

External case studies can provide corroboration. For example, StormWall’s Advika case study describes BGP-integrated protection and a documented attack day. Treat it as evidence for the described deployment and event—not as a universal guarantee for every future product or network segment.

Step 10: verify the SLA and backup boundary

A technical architecture is not a commercial remedy. Read the availability percentage, measurement method, exclusions, maintenance rules, incident-notification process, claim window and credit cap. Confirm whether the SLA applies to power, network, VM availability, hardware replacement or only one component.

Separately verify backups. A provider can maintain infrastructure availability while a customer loses data through deletion, compromise, application failure or an unusable backup. Ask where backups are stored, whether they are isolated from the source, how restores are tested, what retention applies, and who is responsible for initiating recovery.

Why public tools sometimes disagree

• BGP collectors see the Internet from different vantage points.
• A relationship can be classified as transit by one source and peer by another.
• PeeringDB is maintained by network operators and may lag or omit private sessions.
• A route may be visible in some regions but not others.
• Prefix counts differ when sources count exact routes, aggregates, customer routes or address equivalents.
• Web crawlers and certificate pages can cache old copies.

Disagreement is a reason to ask a narrower question, not to choose the largest number. Capture the date and source of every observation.

Worked example: AS135682

A procurement evidence pack

1. Signed quotation with legal entity, facility city and product specification.
2. Test IP or looking-glass endpoint for the exact network.
3. ASN/RDAP and BGP snapshots captured on the procurement date.
4. Current facility certificates with holder, site, scope and expiry.
5. Network and DDoS protection scope for the assigned prefix.
6. SLA, backup policy, acceptable-use policy and incident contacts.
7. Migration, cancellation, data export and secure-erasure process.
8. A small pilot with monitoring before the production cutover.

Bottom line

Infrastructure claims become trustworthy when each claim maps to a verifiable layer and a current document. ASN data verifies routing identity. BGP views verify route visibility. PeeringDB helps explain interconnection. Certificates verify only their named holder, sites and scope. Traceroutes measure a path from a specific vantage point. The contract determines what the provider actually owes you.

For the ownership vocabulary, read What “Owned Datacenter” Actually Means. For the StreamData and Advika network map, read Inside Advika AS135682.