Network Tools
Diagnostics and lookups: ping, DNS, WHOIS, IP, headers and more.
About
Resolve DNS, check headers, verify TLS, email auth, see your public IP, ASN and subnets — tuned for speed, clarity and privacy.
DNS propagation, HTTP headers and redirects, SPF/DKIM/DMARC, TLS expiry and chain checks, ASN/prefix lookups, IP visibility and subnet math live here. Server-side execution keeps answers consistent and layouts stay readable on mobile and desktop.
Requests run from the edge so you see what users and crawlers see, not your browser cache. Logging is minimal and packet captures are not stored beyond the request. Mail auth results include raw DNS plus policy summaries; headers show redirects, status codes, cache hints and security headers together.
Use these tools to validate launches, confirm DNS changes, verify CDN headers, audit TLS hygiene and fix email deliverability. Share links with your team without exposing tokens — inputs are fast, outputs are copyable, retries are instant.
FAQ
›Why do results differ by location?
›Do you store lookups or scans?
›Can I validate email deliverability here?
›What should I check before a launch?
These tools are the exception to the browser-only rule, and they have to be. A web page cannot open a raw socket, send an ICMP packet or query a nameserver directly — the browser sandbox exists precisely to stop that. So every lookup here is issued from our server, and the answer describes the internet as our server sees it. The My IP tool is the one that genuinely reports your connection, because that request comes from you.
That distinction matters when you are debugging. If a DNS check succeeds from our resolver but your laptop still cannot reach the site, the record is fine and your local cache, VPN or corporate resolver is not. Same for a port check: an open result proves the service accepts connections from the public internet, and tells you nothing about a firewall rule that only affects your office.
When something is down, work upward in order: does the name resolve, does TCP connect, does TLS negotiate, does HTTP return what it should. Jumping to the middle of that chain is how people spend an afternoon on a certificate problem that was actually an expired domain.
Reading DNS in the right order
There are two different answers to any DNS question: what the authoritative nameserver holds, and what a given resolver has cached. Querying the authoritative servers directly shows the current truth; querying a public resolver shows what most users are getting right now. When those disagree, you are simply waiting out a TTL. Nothing “propagates” — records are pulled on demand and held for the TTL you published, so lowering the TTL to 300 seconds a day before a migration is the only real preparation.
The apex of a domain cannot hold a CNAME, because the record type conflicts with the SOA and NS records that must exist there. Providers work around this with ALIAS or flattening records that resolve to an address at query time. Get this wrong and mail stops, because the conflicting CNAME suppresses the MX record.
When you compare two nameservers, check the SOA serial. If it differs between them, one has not picked up the latest zone transfer, and you are chasing an inconsistency rather than a configuration error.
Traceroute tells the truth about the path, not the latency
Routers generate the ICMP time-exceeded messages traceroute depends on using their control plane, which is deliberately deprioritised compared to forwarding traffic. A middle hop showing 180 ms while the final destination answers in 30 ms is completely normal and means nothing is wrong. Only the last hop’s latency describes the actual round trip.
Rows of asterisks mean a hop did not reply, usually because ICMP is filtered there — not because packets are being dropped. Return paths are frequently asymmetric, so what you see is one direction of a two-way trip, and MPLS tunnels can hide several physical hops behind what looks like a single link. Use traceroute to find where a path changes provider or geography, not to measure performance.
What a TLS check should tell you
Expiry is the obvious thing and the least interesting one. The failure that costs people real time is an incomplete chain: the server sends its leaf certificate but omits the intermediate. Browsers paper over this by fetching the missing certificate through the AIA extension, so the site looks fine to you while curl, Java clients, older Android devices and payment webhooks all reject it. A chain check catches it before your partners do.
Also confirm the hostname appears in the SAN list rather than only the deprecated common name, that TLS 1.2 and 1.3 are offered while 1.0 and 1.1 are not, and that the certificate covers every hostname you actually serve. Combined with a header check — HSTS, the redirect chain, cache directives, whether the server leaks its exact version — you get a fairly complete picture of how a host presents itself.
Email authentication in three records
SPF lists the hosts allowed to send for your domain, and it has a hard limit of ten DNS lookups during evaluation. Chaining several vendor include statements blows past that limit and produces a permanent error, which many receivers treat as a failure. Count your lookups whenever you add a service.
DKIM signs the message with a private key while publishing the public key at a selector under the domain, so a receiver can prove nothing was altered in transit. DMARC ties the two together, adds alignment requirements between the visible From domain and the authenticated one, and tells receivers what to do when checks fail. Start at p=none with a reporting address, read the aggregate reports for a few weeks until you have found every legitimate sender, then move to quarantine and finally reject.
Common questions
- Is the lookup run from my computer or from your server?
- From our server, with the exception of My IP, which reports the address your own request arrived from. That is why results reflect our vantage point on the network rather than yours. For anything that depends on your local network, run the equivalent command on your own machine.
- How accurate is IP geolocation?
- Country-level accuracy is usually reliable; city-level is a guess based on registry data and network topology, and it is frequently wrong by hundreds of kilometres. Mobile carriers, VPNs and CGNAT make it worse by mapping large user populations to a single gateway. Treat it as a hint, never as evidence.
- Why is WHOIS data mostly hidden?
- Registrars redact personal contact details for most domains to comply with GDPR and similar privacy rules, replacing them with a proxy address. Registration and expiry dates, registrar name and nameservers stay visible and are usually what you need anyway. Some ccTLDs redact even more.
- What is the difference between a closed and a filtered port?
- Closed means the host replied with a TCP reset — something is there, nothing is listening on that port. Filtered means nothing replied at all, so a firewall silently dropped the packet. Filtered results are ambiguous by design; that is the point of dropping rather than rejecting.
- How long do DNS changes take to appear?
- As long as the previous TTL on the record, because resolvers keep serving the cached copy until it expires. A record with a 24-hour TTL can take a full day to turn over worldwide. Lower the TTL well before you plan the change, not after.
- What does an ASN lookup tell me?
- It maps an IP address to the autonomous system that announces it, which usually identifies the hosting provider, cloud region or ISP behind an address. That is useful for spotting whether traffic comes from a residential network or a datacentre. It does not identify an individual customer of that provider.
- Do you log the domains and addresses I look up?
- We keep short-lived request records for rate limiting and abuse prevention, and nothing is tied to an account or profile. The data being queried is public registry and DNS information in the first place. Nothing you look up is shared or sold.
- Why does my public IP change?
- Most residential connections get a dynamic address from the ISP that can change on reconnection or lease expiry. Mobile networks also place many subscribers behind CGNAT, so the address you see belongs to the carrier gateway rather than to your device. A static address usually requires a business plan.