When you visit a site (like ldaws.com) in the browser, there are a lot of moving parts that you may need to debug, and a lot of tools to do that. Here are some ways to answer questions when you’re debugging, approximately in order.

For the examples that use dig, you may prefer to use the friendlier doggo utility (which also has a web version).

Is My Site/Server Answering?

ping is a good starting point, it checks the quality of the connection from your machine:

$ ping ldaws.com -c10
PING ldaws.com (104.21.89.191): 56 data bytes
64 bytes from 104.21.89.191: icmp_seq=0 ttl=58 time=4.568 ms
64 bytes from 104.21.89.191: icmp_seq=1 ttl=58 time=3.889 ms
64 bytes from 104.21.89.191: icmp_seq=2 ttl=58 time=3.080 ms
64 bytes from 104.21.89.191: icmp_seq=3 ttl=58 time=4.924 ms
64 bytes from 104.21.89.191: icmp_seq=4 ttl=58 time=4.892 ms
64 bytes from 104.21.89.191: icmp_seq=5 ttl=58 time=3.785 ms
64 bytes from 104.21.89.191: icmp_seq=6 ttl=58 time=4.469 ms
64 bytes from 104.21.89.191: icmp_seq=7 ttl=58 time=4.463 ms
64 bytes from 104.21.89.191: icmp_seq=8 ttl=58 time=4.375 ms
64 bytes from 104.21.89.191: icmp_seq=9 ttl=58 time=4.835 ms

--- ldaws.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.080/4.328/4.924/0.554 ms

This tests the connection between your computer and the thing that “terminates” your connection. This might be your server, or it might be something else like a load balancer. In the output above, it says PING ldaws.com (104.21.89.191) - that IP address is a Cloudflare IP address, as Cloudflare is “proxying” the request. This means that Cloudflare receives your request, processes it, and then often asks another server (the “origin server”) for a response1.

Not all working hosts respond to pings, though:

$ ping microsoft.com -c10
PING microsoft.com (20.84.181.62): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8

--- microsoft.com ping statistics ---
10 packets transmitted, 0 packets received, 100.0% packet loss

# but a HTTP HEAD request works, issuing a redirect in this case:
$ curl -I https://microsoft.com
HTTP/2 301
location: https://www.microsoft.com/
# ...

As another example, Amazon Web Services load balancers will not respond to pings unless it’s permitted by network/security configuration - it’s not permitted by default.

Where is the Request Going?

You can use the dig utility (which is available by default on most machines):

$ dig ldaws.com +short
172.67.191.9
104.21.89.191

$ doggo ldaws.com
NAME       TYPE CLASS TTL  ADDRESS       NAMESERVER
ldaws.com. A    IN    300s 172.67.191.9  172.16.195.78:53
ldaws.com. A    IN    300s 104.21.89.191 172.16.195.78:53
# same results again, but asking the secondary nameserver:
ldaws.com. A    IN    300s 172.67.191.9  172.16.195.86:53
ldaws.com. A    IN    300s 104.21.89.191 172.16.195.86:53

Just like the previous section, this points us to the host that will “terminate” the connection — it’s probably not the machine that will actually prepare the response.

How Do I Check for CNAMEs?

DNS has the concept of a “CNAME” (Canonical NAME) record, which acts a bit like a redirect. dig will automatically list these if it encounters them - here you can see that my blog is currently hosted on Netlify:

$ dig blog.ldaws.com +short
ldaws-blog.netlify.com.
54.253.175.63
54.206.231.79

How Can I Tell Which DNS Nameserver Answered the Query?

It depends how deep you want to go. A zone (domain/subdomain) is represented by a “nameserver”, which answers DNS queries “authoritatively”. This nameserver is named by the “start of authority” (SOA) for that zone. Almost all DNS lookups will go through two nameservers, at minimum:

  • The “top level domain” (TLD) nameserver (which is ignored in the output of most tools, as it’s rarely useful to note)
  • The nameserver which answers requests for the domain (or “zone”)

Sometimes there are more nameservers - subzone.ldaws.com could actually be a separate “zone” from ldaws.com, answered by entirely different nameservers. Finding the “start of authority” (SOA) for a zone will indicate which servers are allowed to answer queries for a zone.

# double-check whether the record is a CNAME - see the next section if it is
$ dig www.ldaws.com CNAME +short

# no output means it's not a CNAME, so we can continue
$ dig www.ldaws.com SOA +short

# no output means that this isn't the root of the zone — go "up" a level by dropping the first section:
$ dig ldaws.com SOA +short
alex.ns.cloudflare.com. dns.cloudflare.com. 2280931444 10000 2400 604800 3600

# ldaws.com is a "zone", and is managed by Cloudflare nameservers.
#
# out of interest, what about the ".com" TLD?
$ dig com. SOA +short
a.gtld-servers.net. nstld.verisign-grs.com. 1660631968 1800 900 604800 86400

If the record you’re asking about is a CNAME record, it can give you a misleading answer if the “target” of the CNAME is a zone itself:

$ dig example.ldaws.com CNAME +short
example.com.

# example.ldaws.com *is* a CNAME
$ dig example.ldaws.com SOA +short
example.com.
ns.icann.org. noc.dns.icann.org. 2022072113 7200 3600 1209600 3600

# dig does point out that it followed a CNAME (the "example.com." line), but ultimately gives the same results as:
$ dig example.com SOA +short
ns.icann.org. noc.dns.icann.org. 2022072113 7200 3600 1209600 3600

What’s Actually Answering My Web Request?

If you want to know what’s answering a request beyond the host that’s “terminating” the connection, you can only find out if:

  • The request returns information you can use to deduce that answer (but this could be cached by a caching proxy or CDN, which might lead you to the wrong conclusion!)
  • You can look at some of the system internals (like the access logs of the server, load balancer logs, Cloudflare logs)

Services like Cloudflare aim to hide the “origin server” from the client. Cloudflare can only apply its protection features for requests that go through its servers, so exposing details about the “origin server” may allow bad actors to attack it directly and bypass those protections.

  1. Or it might deny access due to security configuration, or it might answer the request immediately using a cached response. This means you can’t assume that a request to ldaws.com will appear in the logs for the server you run, as the request may never have reached it! ↩