IP addresses and DNS records explained, with a measured look at how 24 real domains set theirs up

Most explanations of IP addresses and DNS describe how things are supposed to work. We wanted to see how real, well-run sites actually set them up, so on 21 October 2026 we looked up the public DNS records of 24 well-known domains, plus our own, and counted. The results give practical answers to questions people ask, such as how long a DNS change really takes, whether IPv6 and DNSSEC are common, and which email records matter. They also showed three gaps on our own domain, which we list below.

IPv4, IPv6 and the private ranges

An IPv4 address is 32 bits, written as four numbers such as 203.0.113.9, which allows 2³² = 4,294,967,296 addresses. That is fewer than the number of people on Earth, so most networks share addresses. An IPv6 address is 128 bits, written in hexadecimal such as 2001:db8::1, giving 2¹²⁸ addresses, about 3.4 × 10³⁸. The shortage is why IPv6 exists.

Some IPv4 ranges are reserved for use inside a network and are never routed on the public internet:

The practical consequence: the address your My IP Address page shows is your public address, the one the internet sees. At home that is normally your router's, shared by every device on your network. If it begins with 100.64 to 100.127, your provider is sharing one public address between many customers. An IP lookup of a public address returns the network owner and an approximate location, which is often only as precise as the provider's regional hub, so do not read it as a street address.

DNS in one paragraph

DNS turns a name into an address. Your device asks a resolver (usually your provider's or a public one). If the resolver does not already have the answer cached, it asks the root servers, then the servers for the top-level domain, then the domain's own authoritative name servers, which hold the real records. The answer comes back with a time to live (TTL): the number of seconds any cache may keep it before asking again.

What 24 well-known domains actually publish

For each domain we recorded address records, mail records, name servers, email-authentication records and security records. TTLs were read directly from the domain's authoritative name servers, so they are the published values rather than a cache's countdown. The domains are mostly large companies, media and government sites, so this shows how well-resourced sites are configured, not the average of the whole web.

How long a DNS change takes, measured

“DNS propagation can take 24 to 48 hours” is repeated in a lot of guides. It does not describe how these domains are set up. Their published TTLs for the main address record fell into these bands:

The median was 300 seconds. A change is not instant and it is not a day either: after you edit a record, a resolver may keep serving the old answer for up to the old TTL. With a 300-second TTL that is at most five minutes, with 3 hours it is up to three. The long waits people report usually come from a long TTL set earlier, from slow name-server changes (a different step, which can involve the top-level domain's records), or from a device and browser caching on top of DNS.

Email records: SPF and DMARC

SPF is a TXT record listing which servers may send mail for your domain and what receivers should do with the rest. All 24 had one. Fifteen ended in ~all (treat others as suspicious) and nine in -all (reject others). DMARC is a TXT record at _dmarc. plus the domain that tells receivers what to do with mail that fails the checks and where to send reports. Twenty of the 24 used p=reject. For a domain that sends email, these records matter for delivery as well as security, since large mail providers now ask bulk senders to have them.

What we found on our own domain

We ran the same checks on procutout.com. The good: it has an IPv6 address, a 300-second TTL, two name servers, mail records and an SPF record ending in ~all. The gaps: no DMARC record, no CAA record, and no validated DNSSEC. Eighteen of the 24 domains we surveyed had CAA records or validated DNSSEC or both, and all 24 had a DMARC record. Publishing these gaps is a reminder that auditing your own records is worth ten minutes.

Check your own domain

1. Open DNS Lookup, enter your domain and read the A and AAAA records. Note the TTL.
2. Check that www and the bare domain both resolve, and decide whether www should be a CNAME or an A record.
3. Check the MX records match the mail provider you actually use.
4. Read the TXT records for one SPF record (there must be exactly one) and ask your mail provider what it should contain.
5. Look for a DMARC record at _dmarc.yourdomain with a command-line tool such as dig TXT _dmarc.yourdomain or your DNS provider's dashboard. Start with p=none to receive reports and tighten later.
6. Use IP Lookup on the addresses you find to confirm they belong to the host you expect.

Limits of this snapshot

It is one day, one resolver and 24 domains chosen for being well known, so it describes large sites, not the whole internet. A domain's TTL can differ between its name servers or by region, and we took the first server that answered. DNSSEC status is as reported by Cloudflare's resolver. Records change, so treat the figures as a dated picture; the script that produced them is easy to re-run to refresh them. The DNS Lookup tool queries public DNS from our server, so only enter public domain names.