Website hosted on BigRock Windows Shared Hosting does not open on Vodafone mobile network

The symptoms point to a DNS resolution problem that’s specific to Vodafone’s DNS resolvers, not to IIS itself. The error DNS_PROBE_FINISHED_NXDOMAIN means Vodafone’s DNS servers are returning “no such domain” for the hostname, while other ISPs resolve it correctly.

Given the context, focus on DNS and network path rather than IIS configuration.

1. Server-side checks to perform

On the Windows/IIS hosting side:

• Confirm that the site responds correctly by IP from multiple networks (where possible):
  • Use a browser or curl from different networks to hit the site’s IP directly (if the host header is not required or can be tested via curl with Host: header). If IP access works but the hostname fails only on Vodafone, it reinforces a DNS issue.
• Check IIS bindings:
  • Ensure the site has an HTTP/HTTPS binding for the correct host name and IP/port combination.
  • Misconfigured host headers usually cause 400/404, not NXDOMAIN, so this is secondary.
• Review IIS logs:
  • If Vodafone users never appear in IIS logs for the failing attempts, the traffic is not reaching the server at all (DNS or routing issue).
• Check firewall on the server/network edge:
  • Verify that there are no IP-based restrictions that could block Vodafone’s egress IP ranges.
  • If IP restrictions are used (for example to mitigate 403.6 or similar), remember that clients behind mobile networks or proxies may appear with shared IPs. See the note about proxy servers and X-Forwarded-For headers: if restrictions are based on client IP, they may behave differently when traffic comes via a mobile carrier or proxy.

2. Determining whether Vodafone is blocking or failing to route traffic

From the context, the most reliable way is to distinguish DNS failure from routing failure:

• DNS tests from Vodafone network:
  • Use nslookup or a similar tool on a device using Vodafone’s DNS (or a test SIM in a phone with a terminal app) to query the domain.
  • If nslookup returns NXDOMAIN or times out while other public DNS (for example, a non-Vodafone resolver) returns the correct IP, the issue is with Vodafone’s DNS or its upstream.
  • This is similar to the documented scenario where ISP DNS issues prevent access to Microsoft services; the mitigation there is flushing or correcting DNS records on the ISP side.
• Routing tests:
  • If DNS resolves correctly on Vodafone (returns the same IP as other ISPs), but the site still doesn’t load, run ping and tracert/traceroute from a device on Vodafone to the resolved IP.
  • If the trace fails early within Vodafone’s network, it suggests a routing or blocking issue on Vodafone’s side.
  • If the trace reaches the data center edge but not the server, investigate hosting provider firewall or network ACLs.

3. Settings that commonly cause “works on some networks but not others”

From the provided material, the main categories are:

• DNS configuration issues:
  • Missing or incorrect DNS records, or inconsistent propagation, can cause some resolvers (ISPs) to fail while others succeed.
  • Damaged or missing root hints or misconfigured DNS forwarders on an intermediate DNS server can cause failures for some paths. The Windows Server DNS guidance shows how incorrect root hints or DNS configuration can break Internet name resolution while local resolution works.
  • ISP DNS caches can become stale or corrupted; the Windows Update DNS article describes how flushing ISP DNS caches for specific hostnames resolves connectivity issues.
• IP-based restrictions and reverse DNS:
  • If access is restricted by IP or domain name, IIS may perform reverse DNS lookups. If reverse DNS fails or is slow for certain networks, it can cause unexpected access problems or latency.
  • Clients behind proxy servers or carrier NAT (typical for mobile networks) appear with the proxy’s IP, not the original client IP. If any IP allow/deny logic is in place, it may behave differently for Vodafone than for other ISPs.
• Proxy/CDN/SSL offload layers (if used):
  • If there is an ARR or reverse proxy layer in front of IIS, ensure that only the proxy is Internet-facing and that SSL/TLS and host headers are correctly configured. Misconfiguration here usually results in HTTP errors, not NXDOMAIN, but can interact with IP restrictions.

4. Diagnostic tests to run

Use a structured approach:

A. DNS resolution tests

• From multiple networks (including Vodafone):
  • nslookup yourdomain or dig yourdomain and compare results.
  • Confirm that all resolvers return the same A/AAAA records.
• If using private endpoints or custom DNS anywhere in the path (for example, VPN or corporate DNS), follow the pattern used for Azure Migrate private endpoints:
  • Run nslookup against the domain and verify that it resolves to the expected IP.
  • If resolution is incorrect, update DNS records or hosts file (for testing) and validate again.

B. Connectivity tests

• From Vodafone and non-Vodafone networks:
  • ping <resolved IP>
  • tracert <resolved IP> (Windows) or traceroute <resolved IP> (Linux/macOS)
• Compare where the path breaks:
  • If only Vodafone traces fail and they fail inside Vodafone’s network, it is likely a carrier routing/blocking issue.
  • If traces reach the hosting network but not the server, investigate hosting-side firewall or network ACLs.

C. Server-side logging and monitoring

• IIS logs:
  • Check whether any requests from Vodafone IP ranges are recorded during the time users report failures.
  • If there are no entries, the problem is before IIS (DNS or routing).
• Network captures (if possible):
  • Use a tool such as Wireshark on the server to see whether any TCP SYN packets from Vodafone IPs arrive.
  • If DNS resolution is suspected, capture DNS traffic to confirm whether queries reach the server’s DNS and whether responses are sent.

5. Similar issues and practical mitigation

The Windows Update DNS article describes a very similar pattern: some ISPs’ DNS servers had bad entries for specific Microsoft hostnames, causing only those ISPs’ customers to fail to reach Windows Update while others worked. The mitigation was for ISPs to flush or correct DNS records, or for users to temporarily switch to alternate DNS providers.

Applied to this scenario:

• If Vodafone’s DNS is returning NXDOMAIN or wrong IPs, Vodafone must flush or correct their DNS cache or upstream configuration.
• As a temporary workaround (for testing or power users), using an alternate DNS provider on the device or router can bypass the issue, but this cannot be enforced for all visitors.
• Provide Vodafone with:
  • The domain name
  • Evidence from nslookup/dig showing their DNS returns NXDOMAIN while others resolve correctly
  • Traceroute results if routing is also affected

On the hosting side, ensure:

• DNS records at the authoritative DNS provider are correct and have reasonable TTLs.
• No IP-based blocking that might affect carrier NAT ranges.
• IIS bindings and site configuration are correct, and the site responds properly when accessed by IP from multiple networks.

References:

• Troubleshoot DNS client name resolution issues
• Troubleshoot DNS name resolution on the Internet in Windows Server
• Isolated ISP DNS issues preventing connections to Windows Update service
• HTTP error 403.6 when you open an IIS webpage
• Troubleshoot network connectivity