digga.dev

A domain dig is a DNS query that asks a resolver for the records attached to a domain name — the A record behind a website, the MX records behind its email, the TXT records behind its SPF policy, and so on. You can run one from a terminal with the dig command, or from a browser with a free lookup tool like digga, which queries DNS over HTTPS and adds RDAP/WHOIS, subdomain, and email-security data in the same report. Use the command line when you want raw control over the resolver and query flags; use a web tool when you want a readable answer plus registration and email context without installing anything.

What "dig" actually means

dig (domain information groper) is a command-line DNS client. It sends a query to a resolver and prints the response. It is not a domain availability checker and it does not tell you whether a name is for sale — it reports what DNS currently says about a name that already exists in the DNS system.

A "domain dig" in everyday use means any DNS lookup of that kind, whether run in a terminal or through a web interface. The core question is always the same: what records does this name resolve to, and from which resolver did that answer come?

Which record types to query and what each tells you

For a quick health check, start with A/AAAA (is the site reachable?), MX (is email routed?), NS (who controls the zone?), and TXT (what policies are published?). CAA and DNSSEC records matter when you care about certificate issuance and spoofing resistance.

Running a dig from the command line

The basic form is:

dig example.com A

Input: a domain name and a record type. Action: your system's configured resolver is queried. Expected result: an ANSWER section with the record, a TTL, and a header showing the resolver's status (NOERROR, NXDOMAIN, SERVFAIL).

Useful variations:

• dig example.com MX — mail routing.
• dig example.com ANY — many resolvers now refuse or truncate ANY; query specific types instead.
• dig @1.1.1.1 example.com A — query a specific resolver rather than your default.
• dig +short example.com — answers only, no header or sections.
• dig +trace example.com — walk the delegation chain from the root down, useful for spotting where a delegation breaks.

Reading the output: the header names the resolver used and the status code; the ANSWER section holds the records you asked for; AUTHORITY holds the nameservers for the zone; ADDITIONAL often carries glue addresses. TTL tells you how long a resolver may cache that answer — a low TTL means changes propagate faster.

Running a dig with a web tool like digga

digga runs the same kind of query through DNS over HTTPS and lets you switch resolvers live between Cloudflare, Google, and Alibaba DoH. The workflow is:

1. Enter an apex domain, subdomain, or full URL — digga normalizes it to the domain.
2. Read the DNS report for A, AAAA, MX, NS, TXT, CAA, DNSKEY, DS, SOA, SRV, PTR, NAPTR, and CNAME records.
3. Switch the DoH resolver to compare answers if one resolver looks stale or wrong.
4. Open the companion views for RDAP (with raw WHOIS as fallback), passive subdomain discovery from public sources such as Certificate Transparency logs, IP/ASN ownership for each A and AAAA record, and email authentication (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, with the SPF lookup limit checked).

The advantage over a bare dig is context: the same report shows who registered the domain, which network hosts it, and whether its email setup resists spoofing. The tool is open source under AGPL 3.0 and requires no account.

Combining DNS with registration and email data

DNS alone answers "where does this point right now." Pair it with:

• RDAP/WHOIS — registrar, nameservers, domain status, creation and expiry dates. RDAP returns structured data; WHOIS is the raw fallback when a registry has not caught up.
• Subdomain discovery — passive enumeration from public sources, with no traffic sent to the target, useful for mapping an attack surface or finding forgotten staging hosts.
• Email authentication — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI in one view, so you can see how well a domain resists spoofing.

Together these turn a single record lookup into a picture of a domain's infrastructure, ownership, and mail posture.

Common failures and what they mean

• NXDOMAIN — the name does not exist in DNS. Check for typos, or confirm the domain is actually delegated.
• SERVFAIL — the resolver could not get a valid answer, often a broken delegation or an unreachable authoritative server.
• Wrong resolver — different resolvers can return different answers during propagation; compare two before concluding something is broken.
• Propagation delays — a recent change may still be cached under the old TTL. Query the authoritative nameserver directly to see the current state.
• Empty ANSWER with NOERROR — the name exists but has no record of that type; common when a domain has A records but no MX.

If a web tool and your terminal disagree, check which resolver each is using — that is usually the whole explanation.

"Google dig" usually means one of two things: querying DNS through Google's public resolvers (8.8.8.8 / 8.8.4.4), or running the dig command-line tool and pointing it at Google's resolver. Both get you the same records; the difference is whether you type a command or click a button. If you have a terminal, dig gives you the most detail. If you don't, an online DNS lookup does the same job in a browser. Below are the exact commands, the fields worth reading, and how to tell a real failure from a caching artifact.

First, pick your entry point

dig is standard on macOS and most Linux distributions. On Windows it's often absent, so either use WSL, install BIND tools, or fall back to a browser lookup.

Running dig from the command line

The basic form is dig [@resolver] name [type]. To query a domain's A records through Google's public DNS:

dig @8.8.8.8 example.com A

To use Google's secondary resolver, swap in @8.8.4.4. Common record types you'll actually need:

dig @8.8.8.8 example.com A        # IPv4 address
dig @8.8.8.8 example.com AAAA     # IPv6 address
dig @8.8.8.8 example.com MX       # mail servers
dig @8.8.8.8 example.com TXT      # SPF, DKIM, verification strings
dig @8.8.8.8 example.com NS       # authoritative nameservers
dig @8.8.8.8 example.com CNAME    # alias target
dig @8.8.8.8 example.com CAA      # which CAs may issue certs

Add +short to strip everything but the answer:

dig @8.8.8.8 example.com MX +short

What you should see: a header block, a QUESTION section echoing your query, an ANSWER section with the records, and an AUTHORITY section naming the nameservers responsible for the zone. If the ANSWER section is empty, the record type doesn't exist for that name even if the domain itself does.

Doing the same thing in a browser

If you don't want to install anything, an online lookup returns the same records. On digga, the DNS lookup page queries A, AAAA, MX, NS, TXT, CAA, and DNSSEC records live and lets you switch between Cloudflare, Google, and Alibaba DNS over HTTPS. That resolver switch matters: if one resolver returns a stale or empty answer, a second opinion from another provider tells you whether the problem is the domain or your resolver.

The workflow is the same as the command line — enter the apex domain, subdomain, or full URL, pick the record type, read the answer. The site also runs RDAP first with a raw WHOIS fallback for registration data, and a separate email security view that checks SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI, including whether your SPF record exceeds the lookup limit.

Reading the output: the fields that matter

Status code. NOERROR means the query succeeded — it does not mean records exist. NXDOMAIN means the name doesn't exist at all. SERVFAIL means the resolver couldn't get an answer, often a broken zone or DNSSEC failure. REFUSED means the server won't answer you.

ANSWER section. The actual records. An empty ANSWER with NOERROR is normal when you ask for a type the domain doesn't publish (e.g. no MX on a domain that doesn't receive mail).

TTL. How many seconds the record may be cached. A low TTL (300s) means recent changes propagate fast; a high TTL (86400s) means you may be seeing an old value for up to a day. This is the single most common reason "the DNS change didn't take effect."

AUTHORITY section. The nameservers that own the zone. If these don't match what your registrar shows, your delegation is wrong.

Flags. aa means an authoritative answer; rd means recursion was requested. A non-authoritative answer came from a cache, not the source.

When the query fails

• NXDOMAIN on a domain you know exists — check for a typo, or that you're querying the right subdomain. The apex existing doesn't mean www or mail does.
• SERVFAIL — try a different resolver. If Google and Cloudflare both fail, the zone itself is likely misconfigured or has a DNSSEC problem.
• Timeout — your network or VPN may be blocking port 53. Switch to DNS over HTTPS, which runs over 443 and usually gets through.
• Stale answer after a change — query the authoritative nameserver directly (dig @ns1.example.com example.com A) to bypass caches, or wait out the TTL.
• Different answers from different resolvers — expected during propagation. Compare Google, Cloudflare, and Alibaba; once all three agree, the change has spread.

What dig doesn't tell you

A DNS query returns records, not ownership. To find the registrar, creation date, expiry, and domain status, you need RDAP or WHOIS — digga runs RDAP first and falls back to raw WHOIS when a registry hasn't caught up. To see which subdomains exist, you need passive enumeration from Certificate Transparency logs and public sources, which sends no traffic to the target. And to check whether a domain resists email spoofing, you read its SPF, DKIM, and DMARC records rather than its A record. DNS is one angle; a full picture combines DNS, registration data, subdomains, IP ownership, and email authentication.

A single search on digga.dev accepts an apex domain, a subdomain, or a full URL and returns DNS records, registration data, subdomains, IP/ASN ownership, and email authentication in one report. It's free, open source under AGPL 3.0, and requires no account. Use it when you're debugging a deploy, triaging an incident, or checking how well a domain resists spoofing — not when you need a legally authoritative registration record, since RDAP and WHOIS reflect what registries publish.

One lookup, five angles

The site organizes its output into six tools behind one search box. You type a domain (or paste a URL — it figures out the apex), and the report covers:

Each area also has a dedicated page if you only need one lookup: DNS Lookup, WHOIS Lookup, RDAP Lookup, Subdomain Finder, Email Security Check, and an SSL/TLS Certificate Checker.

Reading DNS records across resolvers

The DNS tool queries live over DNS-over-HTTPS and lets you switch between Cloudflare, Google, and Alibaba DoH. That switching matters: if a record looks wrong or missing, comparing resolvers tells you whether the problem is the zone itself or propagation/caching on one resolver.

What the common types tell you:

• A / AAAA — the IPs the name currently points to; each is annotated with its network owner.
• MX — where mail is delivered; a missing or unexpected MX is a common cause of "email not arriving."
• NS — which nameservers are authoritative; useful for confirming a registrar or DNS migration took effect.
• TXT — often holds verification strings and email policy records; read it alongside the email security view rather than in isolation.
• CAA — which certificate authorities are allowed to issue for the domain.
• DNSSEC records (DNSKEY, DS) — whether the zone signs its answers and whether the delegation chain is in place.

A practical sequence for a deploy that "isn't working": check A/AAAA first, then NS to confirm you're looking at the right authoritative servers, then CNAME if the hostname is an alias.

Registration data: RDAP first, WHOIS as fallback

digga pulls structured registration data through RDAP and falls back to raw WHOIS when a registry hasn't caught up. From this you can find the registrar, nameservers, domain status, and creation and expiry dates. The fallback behavior is the useful detail — RDAP coverage isn't universal, so a tool that only speaks RDAP will show blanks for some TLDs.

Treat both as published registry data, not proof of ownership. Status codes and dates are what the registry reports.

Subdomain discovery without touching the target

The subdomain finder enumerates passively from Certificate Transparency logs and other public sources. No traffic is sent to the target, and results stream back to your browser as they arrive. This is the right approach when you want to map an attack surface or inventory your own hosts without alerting anything on the other end. Because it's passive, coverage depends on what has been logged publicly — absence of a subdomain in the results isn't proof it doesn't exist.

Email security in one view

The email security check analyzes SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI together, and validates the SPF lookup limit for you. That last check is the one people most often miss: SPF has a limit on the number of DNS-querying mechanisms it can use, and exceeding it causes a permerror that silently breaks authentication. Seeing SPF, DKIM, and DMARC side by side also makes misalignment obvious — a valid DKIM signature on a domain that doesn't match the From header still fails DMARC.

Digging from any page

Chrome and Firefox extensions let you right-click any page and dig its domain, skipping the copy-paste step. That's the fastest path when you land on a suspicious or unfamiliar site and want its DNS, registration, and email posture immediately.

When this fits and when it doesn't

Use digga for reconnaissance, debugging, and quick verification across DNS, registration, subdomains, IP ownership, and email security in one pass. Skip it if you need contractual or legal confirmation of ownership, or if you need active scanning of a target — the subdomain tool is deliberately passive, and nothing here sends traffic to the host you're researching.

A domain lookup is a query that pulls the public records attached to a domain name: its DNS records, its registration data, its subdomains, the networks behind its IP addresses, and its email authentication setup. On digga, one search box accepts an apex domain, a subdomain, or a full URL and returns all of these in a single report, free and without an account. Use it when you are debugging a deploy, triaging an incident, checking whether a domain is safe to trust, or just curious who is behind a name.

The six things a full lookup covers

digga bundles six tools behind one search. Each also has its own dedicated page if you only need one angle.

The subdomain finder is passive: it reads public sources and sends no traffic to the target, so you can enumerate a domain you do not control without touching its servers.

Reading DNS records: what each type actually tells you

DNS is the part people skip past, but each record type answers a different question. Here is what to look for.

• A and AAAA — the IPv4 and IPv6 addresses the name points to. If a site is down, this is the first place to confirm it still resolves, and to check whether it moved.
• CNAME — an alias. A www CNAME pointing at a hosting provider's hostname tells you where the site is actually served from.
• MX — where email for the domain is delivered. A missing or unexpected MX is a common cause of "our email stopped working."
• NS — the authoritative nameservers. These tell you which DNS provider controls the zone, which matters when you are about to change DNS and need to know who to change it with.
• TXT — free-form text, and the home of verification tokens and email policy records. SPF and DMARC both live here.
• CAA — which certificate authorities are allowed to issue certificates for the domain. A restrictive CAA is a real anti-misissuance control.
• DNSSEC records (DNSKEY, DS) — whether the zone is cryptographically signed. If DS exists at the parent but DNSKEY does not resolve, the domain is misconfigured and validating resolvers will fail it.
• SOA, SRV, PTR, NAPTR — zone metadata, service locations, reverse lookups, and service discovery. Less common, but SOA is useful for finding the zone's primary nameserver and contact.

Because digga queries resolvers live, you can switch between Cloudflare, Google, and Alibaba DoH and compare. If one resolver returns a different answer than another, you are usually looking at propagation lag or a split-horizon setup — a genuinely useful signal during a migration.

RDAP vs WHOIS: why the order matters

Both answer "who registered this and when," but they are not the same format.

• RDAP returns structured, machine-readable data: registrar, domain status codes, creation and expiry events, and DNSSEC status, each as a labeled field.
• WHOIS returns raw text in whatever format the registry happens to use, which varies by TLD.

digga queries RDAP first and falls back to raw WHOIS when a registry has not caught up. In practice this means you get clean fields most of the time and still get an answer for the TLDs that lag. What you can reliably read from either: the registrar, the nameservers, the domain status (for example whether it is on client-hold or pending delete), and the creation and expiry dates. Expiry is the one to watch — a domain expiring in days is a real operational risk.

Judging email security from SPF, DKIM, and DMARC

This is the part of a lookup with the most direct security payoff, because it tells you how easily someone could send mail pretending to be that domain.

• SPF lists which servers may send mail for the domain. The catch is the lookup limit: SPF allows a maximum of 10 DNS lookups, and exceeding it silently breaks the policy. digga checks that limit for you, which is the failure most people miss.
• DKIM publishes a public key so recipients can verify a signature on outgoing mail. A missing DKIM record means mail cannot be cryptographically tied to the domain.
• DMARC tells receivers what to do when SPF and DKIM fail, and where to send reports. The policy value is the headline: p=none only monitors, p=quarantine sends failures to spam, and p=reject blocks them outright. A domain with no DMARC record at all is straightforward to spoof.
• MTA-STS and TLS-RPT enforce and report on encrypted mail transport.
• BIMI controls the verified logo shown next to mail in supporting clients.

Read together, these tell you whether the domain is defended or wide open. A domain with a strict DMARC policy, valid DKIM, and a passing SPF is hard to impersonate. One with none of them is trivial.

Running a full lookup, step by step

1. Enter the target. Type an apex domain, a subdomain, or paste a full URL. digga normalizes it, so you do not need to strip https:// or paths yourself.
2. Start with DNS. Confirm the name resolves and check the record types that matter for your task — A/AAAA for reachability, MX for mail, NS for control, CAA and DNSSEC for security posture.
3. Check registration. Read the RDAP result for registrar, status, and expiry. If the registry has not caught up, the WHOIS fallback fills the gap.
4. Enumerate subdomains. Trigger the subdomain finder to see what else is exposed. Results stream back as they are found, so you can start reading before the scan finishes.
5. Map the infrastructure. Click through the A and AAAA records to see the ASN, network owner, and geolocation behind each address.
6. Audit email security. Open the email security view and read SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI together, with the SPF lookup count already validated.

Common snags and what they mean

• A record missing but the site works — the name may be CNAME'd elsewhere, or served only over IPv6. Check AAAA and CNAME before concluding anything is broken.
• Different answers from different resolvers — usually propagation lag after a change, or intentional split-horizon DNS. Compare resolvers to tell which.
• SPF present but mail still fails — almost always the 10-lookup limit. The check flags this so you do not have to count manually.
• No RDAP data — some registries are slow to support it. The WHOIS fallback exists precisely for this.
• DNSSEC half-configured — a DS record without a matching DNSKEY breaks validation for everyone using a validating resolver. Treat it as urgent.

When to use this

Reach for a full domain lookup when you are debugging a deploy or DNS change, triaging a mail or deliverability incident, evaluating whether a domain is trustworthy before interacting with it, or auditing your own domain's spoofing resistance. digga is open source under AGPL 3.0, needs no account, and has browser extensions for Chrome and Firefox that let you right-click any page to dig its domain without copying anything.

Cybersecurity is the practice of keeping your data, accounts, and services from being accessed, stolen, altered, or knocked offline by someone who shouldn't have them. For a personal site or small online presence, that reduces to a short list of concrete jobs: protect your login credentials, keep your software current, serve traffic over HTTPS, and lock down the domain and DNS layer that everything else depends on. You don't need an enterprise security team to cover the basics — but you do need to treat your registrar account and your hosting account as the two most valuable things you own, because whoever controls those controls the site.

What cybersecurity actually protects

It helps to separate the assets from the threats, because most small-site incidents come from a handful of causes.

The pattern: each asset has one or two controls that remove most of the risk. You don't need all of them on day one, but skipping the account and domain layers is the mistake that's hardest to undo.

The threat categories a small site actually faces

• Credential theft — reused or weak passwords, or credentials leaked from another breached service. This is the most common way small sites fall.
• Phishing — fake login pages or "your domain is expiring" emails designed to capture your registrar or hosting password.
• Malware and backdoors — usually arriving through an outdated CMS, plugin, or theme.
• DDoS — flooding a site until it's unreachable; often handled by your host or a CDN rather than by you.
• Misconfiguration — an open admin panel, directory listing, or default credentials left in place.

Notice that four of the five are about access, not exotic exploits. That's why the basics work.

Core protections to apply first

Use strong, unique passwords and a password manager

Every account tied to your site — registrar, host, CMS, email — should have a different password. A password manager makes this practical. The goal is that one leaked password can't be replayed anywhere else.

Turn on multi-factor authentication

MFA is the single highest-value control for your registrar and hosting accounts. Even if a password is stolen, an attacker without the second factor can't log in. Prefer an authenticator app or hardware key over SMS where the service supports it.

Serve everything over HTTPS

An HTTPS/TLS certificate encrypts traffic between visitors and your site and prevents browser "not secure" warnings. Most hosts and registrars offer a free certificate; the important part is that it's installed and that HTTP redirects to HTTPS.

Update promptly and keep the surface small

Apply CMS, plugin, and theme updates as they're released, and delete anything you're not using. Fewer components means fewer places for a known vulnerability to sit unpatched.

Apply least privilege

Give each person (and each integration) only the access they need. Don't run your site day-to-day from an administrator account, and don't hand out admin rights for tasks that don't require them.

Secure the domain and DNS layer

This layer is easy to overlook and expensive to lose, because a hijacked domain can point anywhere.

• Protect the registrar account with a unique password and MFA. Your registrar account is the root of control over the domain.
• Enable the registrar lock (often called a transfer lock or clientTransferProhibited) so the domain can't be moved without your action.
• Keep registrant contact email secure — that inbox is often the recovery path for the domain.
• Enable DNSSEC where your registrar and DNS provider support it, so responses can be cryptographically validated and spoofing is harder.
• Watch for unauthorized DNS changes — if records you didn't touch appear, treat it as a compromise.

Porkbun is an ICANN-accredited domain registrar, which means it operates under ICANN's registrar rules — relevant here because those rules govern transfers, locks, and registrant contact requirements. Its site lists Stripe among its payment platforms. Beyond that, check your specific registrar's and DNS provider's current feature set for lock and DNSSEC support, since availability varies.

Warning signs and first steps if something looks wrong

Watch for: unexpected DNS records, visitors reporting malware warnings, unexplained admin accounts, a sudden traffic drop, or emails about transfers you didn't request.

If you suspect a compromise:

1. Change passwords on registrar, hosting, and CMS accounts, starting with the registrar.
2. Revoke active sessions and reset MFA where possible.
3. Check DNS records against what you expect and revert unauthorized changes.
4. Restore from a known-good backup if files were altered.
5. Re-scan and update the software before reopening the site.

Containment first, then recovery — don't try to clean a live, still-compromised site.

What to outsource vs. manage yourself

Hosting-level security, CDN, and WAF are usually worth outsourcing because they require scale and constant attention. Account hygiene, MFA, updates, and domain/DNS protection are things you should keep in your own hands regardless of size — they're cheap to do and costly to skip.