Product capabilities

DNS evidence without the mystery layer.

MyWebDNS keeps the important diagnostic context attached to every answer: which probe asked, where it ran, which resolver replied, how long it took and how long the answer may remain cached.

Diagnostic surface

Built for comparison, not a green-or-red verdict.

The same restrained result model is used for A, AAAA, CNAME, MX, NS, TXT, SOA, PTR, SRV and CAA lookups.

01 / LOCATION

Observed probe locations

Map markers are calculated from latitude and longitude returned for the probe that ran each observation. MyWebDNS does not assign a country to a public resolver address or scatter decorative markers.

  • Written country and city beside every flag
  • Global community, local and authenticated-worker modes identified
  • Provider and resolver shown separately
02 / RECORDS

Ten practical record types

Use the same query workflow for website addresses, mail routing, aliases, nameservers, policy text, service discovery, reverse DNS and certificate authority rules.

03 / TIMING

TTL and latency kept distinct

TTL describes cache lifetime. Response time describes how long this observation took. They answer different questions and appear in separate columns.

04 / STATES

Honest response states

A successful answer, an empty answer, NXDOMAIN, a timeout and an unavailable probe do not collapse into the same warning. An unavailable measurement never appears as “DNS not propagated.”

05 / SECURITY

A deliberately small browser surface

The public interface uses server-rendered Razor, self-hosted CSS and dependency-free JavaScript. Lookup requests use an antiforgery header, stale requests are cancelled and response values are inserted as text rather than executable markup.

  • Content Security Policy with per-request nonce support
  • Rate limiting and bounded server request time
  • No third-party UI, analytics or advertising scripts

One coherent workflow

From question to evidence in four steps.

  1. 1

    Name the target

    Enter a domain, hostname or IP address appropriate for the selected record type.

  2. 2

    Dispatch to probes

    The server sends one normalized query to available Globalping community probes and enabled private nodes within bounded limits.

  3. 3

    Keep context attached

    Each observation returns its status, answer set, TTL, latency and resolver identity.

  4. 4

    Compare, then diagnose

    Use differences as a clue. Confirm the authoritative source before changing production DNS.

What the result can tell you

Useful signals for real DNS work.

After a server migration

See which observations still return the old address, then compare their TTL values before assuming a configuration fault.

During email troubleshooting

Compare the complete MX set, priority values and supporting address records instead of treating one hostname as the whole route.

While validating delegated nameservers

Use NS and SOA evidence as a starting point, then query the parent delegation and each authoritative server directly when they disagree.