WWW records, IP information and ping latency

1. Overview of root and WWW hostnames

Most sites expose at least two hostnames: the bare domain (example.com) and the WWW hostname (www.example.com). DNSprobe checks both.

Why these hostnames matter

Inconsistent records between root and WWW can cause browser warnings, SEO issues and confusing redirects. Ensuring they both resolve correctly is a basic yet critical step for reliability.

How DNSprobe analyses them

DNSprobe queries A and CNAME records for each hostname, shows the IPs that are returned, and flags missing or private IPs so that you can fix them quickly.

2. A records and WWW CNAME

There are two common patterns for the WWW hostname: either it has its own A record pointing directly to an IP, or it is a CNAME that simply points back to another hostname.

Root A record(s)

For the root domain (example.com), DNSprobe lists all A records it finds. Typically, you will see one or more IPv4 addresses belonging to your web or reverse-proxy servers.

WWW A / CNAME record(s)

For the WWW hostname, DNSprobe shows whether a CNAME is present (for example www.example.com → example.com) or if WWW has its own A record. Having both a CNAME and A records on the same name is not allowed in DNS.

Best practices for root and WWW records

• Choose a single canonical hostname (with or without WWW) at the web and HTTPS level.
• Use either a CNAME for WWW pointing to the canonical host, or dedicated A records, but never both at the same time.
• Keep the set of IPs consistent between root and WWW unless there is a specific reason to route them differently.

3. Public vs private IP addresses

The WWW section also checks whether the IP addresses returned by your A records are public or private.

Why your website must use public IPs

Private ranges such as 10.x.x.x, 192.168.x.x or 172.16–31.x are not reachable from the public internet. If your DNS points to a private IP, visitors outside your internal network will not be able to reach your site.

How DNSprobe reports private IPs

If any private IP is detected in your root or WWW records, DNSprobe marks the test as a failure and lists the offending addresses so that you can correct them at your DNS provider or hosting panel.

4. Reverse DNS and ASN information

Beyond the raw IPs, it is often useful to know which provider or network owns those addresses.

Reverse DNS (PTR)

For each IP, DNSprobe performs a reverse DNS lookup (PTR). A meaningful hostname such as server.example.net can help with debugging, deliverability and general hygiene, although it is not strictly required for web hosting.

ASN (network) details

Using Team Cymru’s whois service, DNSprobe retrieves the Autonomous System Number (ASN), IP prefix, country and organisation that announce the address. This is helpful to verify that the IP truly belongs to your provider or to spot unexpected routing.

5. Ping test and latency score

To give you a rough idea of network performance, DNSprobe runs a short ping test (3 attempts) to one of your WWW IP addresses.

How the ping test works

The tool sends three ICMP echo requests, measures each reply time in milliseconds and computes the average latency. The result is shown together with a qualitative score.

Ping score legend

• 🔥 Excellent: average latency < 25 ms (very low latency network).
• ✅ Good: average latency < 100 ms (comfortable for most websites).
• ⚠️ Fair: average latency < 250 ms (acceptable but can feel slower on dynamic sites).
• ❌ Bad: average latency ≥ 250 ms or no reply (high latency or unreachable).

These measurements are taken from the DNSprobe server’s point of view and may differ from what end-users experience in other regions, but they are still a useful indicator of network quality.

6. Best practices and quick checklist

Use the WWW section as a quick health check for the public face of your domain.

• Make sure both the root domain and WWW resolve to valid public IPs and eventually serve the same website.
• Verify that reverse DNS and ASN information match the provider you expect (your hosting, CDN or load balancer).
• Investigate high ping times or packet loss with your hosting provider or network team, especially for latency-sensitive applications.

7. Test WWW manually from your own terminal

To be fully transparent, DNSprobe runs the same kind of WWW checks that you can reproduce yourself. Here are a few example commands you can run locally to inspect the A records, CNAME, public IPs, reverse DNS and latency for your website.

Linux: using dig and ping

On most Linux distributions, the dig command is provided by the BIND utilities package. The following commands query the root and www hostnames and then send a few ICMP echo requests (ping) to measure latency:

                dig example.com A
                dig www.example.com A
                dig www.example.com A +short
    
                ping -c 4 www.example.com
        

macOS: using dig from the built-in tools

macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to see the A records and test basic latency:

                dig example.com A
                dig www.example.com A
                dig www.example.com A +short
    
                ping -c 4 www.example.com
        

Windows: using nslookup and ping

On Windows, you can use the legacy nslookup tool to inspect DNS records and the ping command to test responsiveness. Run the following from a Command Prompt or PowerShell window:

                nslookup example.com
                nslookup www.example.com
    
                ping www.example.com
        

Important: only test your own domains or domains that you are authorised to analyse. Repeated network and latency tests may be interpreted as suspicious activity by some providers.