Domain Names

A domain name is a human-readable identifier in the Domain Name System. It maps a memorable name to infrastructure that can serve websites, email, APIs, files, applications, feeds, redirects, and other networked resources. A good domain is not only a marketing asset. It is a durable pointer, a trust surface, a namespace, and a small piece of internet governance.

Domains matter in this compendium because they connect SEO, independent publishing, blogs, identity, archives, provenance, standards, data sources, OSINT, and the practical work of making information findable. A page can move, but a domain can keep the public handle stable if redirects, DNS, and ownership are maintained carefully.

A domain name is a delegated label sequence in the DNS hierarchy. It can identify a site, organization, product, person, project, application, mail domain, API, or documentation namespace. The name itself is not the server, the website, the email system, or the organization. It is a public pointer that depends on registry delegation, registrar control, authoritative nameservers, DNS records, HTTP behavior, certificates, and renewal discipline.

For knowledge-graph work, the distinction matters. A domain, host, URL, registrar account, DNS zone, certificate, repository, organization, person, and website are different nodes.

A domain is one of the few identifiers a person or project can carry across hosting platforms, social networks, content systems, and product pivots. It anchors canonical URLs, email addresses, feeds, API endpoints, redirects, analytics, structured data, public archives, and documentation.

For a personal site, publication, or tool, the domain should be treated like a small root of trust. Search engines, readers, password managers, email receivers, citation systems, and semantic web metadata all infer continuity from the domain. Losing control of it can break more than the homepage.

Useful domains tend to be:

• memorable: short enough to say aloud, spell, and remember after one encounter;
• semantically fit: close to the person, project, product, or category without being too narrow;
• durable: not tied to a temporary slogan, feature, tool, or trend;
• trustworthy: free of confusing homographs, brand conflicts, typo traps, or sketchy history;
• operationally clear: easy to configure across DNS, email, analytics, search, redirects, and deployment platforms;
• portable: useful even if the project changes shape, merges, or becomes an archive.

The best domain is often not the cleverest one. It is the one that can survive years of redirects, citations, feed subscriptions, email reputation, and reader memory.

Before buying or adopting a domain, treat it as an existing public object, not an empty label. Check whether the name has prior use, spam history, abandoned redirects, unexpected certificate history, indexed pages, expired forum profiles, trademark collisions, or confusing neighbors. A domain can look clean in a registrar search while carrying reputation problems that only appear in search results, archive captures, DNS history, or certificate logs.

The review should be proportional to the role of the domain. A throwaway staging name needs little ceremony. A canonical publishing domain, product domain, or mail domain deserves a stronger provenance pass: old URL samples, existing backlinks, visible search snippets, archive captures, certificate transparency observations, public suffix behavior, and obvious homograph or internationalized-domain risks. Record what was checked so a later steward can distinguish "no evidence found" from "nobody looked."

For SEO, the acquisition question is whether the domain can accumulate authority without inheriting a mess. For OSINT, it is whether public evidence supports the claimed ownership and timeline. For data sources, it is whether the domain can be cited as a stable origin for documents, feeds, APIs, or archives.

Domain ownership is really a bundle of operational relationships. A registrant controls a registration through a registrar. A registry operates a top-level domain. Authoritative nameservers publish the zone. Resolvers answer queries. Web and mail systems then make use of the records.

The IANA Root Zone Database (opens in new tab) is the top-level delegation reference, and IANA's reserved domains (opens in new tab) are useful for avoiding examples that accidentally point at real internet properties. ICANN's domain name basics (opens in new tab) and glossary (opens in new tab) help distinguish registries, registrars, registrants, and DNS operators.

The old DNS foundations are still worth reading. RFC 1034 (opens in new tab) describes domain concepts and facilities, while RFC 1035 (opens in new tab) describes implementation details. Modern systems add layers, but the basic model still explains why delegation, caching, TTLs, and authoritative records matter.

Records to understand:

• A and AAAA map names to IPv4 and IPv6 addresses;
• CNAME aliases one name to another, with important apex-domain constraints;
• MX routes mail;
• TXT carries SPF, verification, policy, and other text-based assertions;
• NS identifies authoritative nameservers;
• CAA constrains certificate issuance;
• SRV, HTTPS, and SVCB support service discovery and modern connection behavior;
• DNSSEC records help authenticate DNS answers where deployed.

The Public Suffix List (opens in new tab) is also operationally important because browsers and libraries use it to reason about registrable domains, cookies, and effective top-level domains.

A domain becomes visible to readers through URLs. The web-facing record should therefore preserve scheme, host, path, query behavior, canonical URL, redirects, sitemap, robots policy, and important legacy routes.

Modern HTTP semantics are described across RFC 9110 (opens in new tab), RFC 9111 (opens in new tab), and RFC 9112 (opens in new tab). For editorial work, the practical lesson is simple: redirects, cache behavior, canonical tags, and status codes are part of the domain's public memory. Moving a site without them fractures SEO, citations, feeds, archives, and graph identity.

For independent publishing, this is the bridge between blogs, SEO, and semantic web. A reader, crawler, archive, and graph index should converge on the same entity even if old posts, mirrors, and backlinks use older URL forms.

Many domain migrations fail quietly because the website works while email breaks. A domain used for login, newsletters, invoices, support, or password reset should not be considered healthy until mail behavior is verified.

Email trust surfaces include:

• MX routing;
• SPF, defined in RFC 7208 (opens in new tab);
• DKIM, defined in RFC 6376 (opens in new tab);
• DMARC, defined in RFC 7489 (opens in new tab);
• bounce handling, transactional sending, and provider-specific verification records.

These records connect domains to standards, data storage, and OSINT: they are public evidence of how a domain is operated and authenticated.

Registration data is increasingly exposed through RDAP rather than legacy WHOIS. RDAP (opens in new tab) and RFC 7482 (opens in new tab) are useful entry points for understanding registration lookup behavior and query patterns.

Certificates are another public evidence surface. RFC 5280 (opens in new tab) defines the certificate and certificate revocation list profile used by the public-key infrastructure, while Certificate Transparency (opens in new tab) makes certificate issuance observable. CT logs can reveal historical hostnames, issuance mistakes, migrations, and infrastructure changes.

The goal is not surveillance trivia. The goal is being able to prove where a public handle pointed at a given time and whether a claimed migration, ownership change, or archival capture is supported by evidence.

A useful domain record should preserve:

• domain name and punycode form when relevant;
• registrant or steward when public and appropriate;
• registrar, registry, renewal date, lock status, and account owner;
• DNS host, authoritative nameservers, zone-file export, TTLs, and change history;
• apex and www behavior, redirect chains, canonical URL, sitemap, robots policy, and feed URLs;
• MX, SPF, DKIM, DMARC, and sending-provider records;
• certificate issuers, certificate transparency observations, and important hostnames;
• analytics, search-console, CDN, hosting, and deployment ownership;
• archive captures, historical redirects, and retired aliases.

This contract links domains to data storage, graphs, GitHub, semantic web, and wget. The domain is the public handle; the record is what makes the handle auditable.

Domain evidence is time-bound. A domain that hosted a trusted blog in 2014 may host unrelated advertising, a parking page, a malware campaign, or a completely different project in 2026. The string is stable, but control, hosting, DNS, certificates, email, redirects, and content can drift independently.

Good records separate those layers. "Owned by the same person," "served from the same host," "redirected to the new canonical site," "issued a certificate for the same hostname," and "contained the same article" are different claims. A wget capture can preserve the page state, RDAP can describe registration data, certificate transparency can show issuance history, and SEO checks can show whether canonical URLs and sitemaps moved cleanly.

This is especially important for blogs, GitHub project pages, data sources, and public documentation. A citation should not silently inherit trust from a domain's old identity after ownership changes. A useful domain timeline records when the domain was checked, what evidence supported the identity claim, and which parts of the stack were not verified.

When moving a domain, preserve canonical URLs, redirects, email authentication, analytics verification, sitemap location, search-console ownership, feed URLs, and important inbound links. Test apex and www, HTTP and HTTPS, old and new routes, and expected status codes.

Also verify email separately. A website migration can appear successful while MX, SPF, DKIM, DMARC, bounce handling, or transactional sending silently fails. A domain used for login, newsletters, invoices, or support is not migrated until both web and email behavior are checked.

Domains deserve a boring maintenance rhythm. At least periodically, verify registrar access, renewal payment, lock status, nameservers, DNS records, certificate issuance, mail authentication, canonical redirects, sitemap location, feed URLs, and important third-party integrations. Keep the review date with the record so the graph can distinguish fresh operational evidence from stale setup notes.

For a personal publishing domain, the lightweight version is enough: confirm the site resolves, old posts redirect, RSS still works, email still authenticates, and an archive capture exists for high-value pages. For an application or public data source, add monitoring, change logs, rollback notes, and ownership records. The goal is not bureaucracy; it is keeping a public identifier from quietly rotting.

A domain is only as durable as the custody around it. A useful domain record should name who can renew it, who controls the registrar login, which email address receives recovery messages, where DNS can be changed, and which services depend on it for login, delivery, or public trust. This does not mean publishing private account details. It means recording the operational map somewhere safe enough that a project can survive staff turnover, lost devices, expired cards, or a founder's forgotten inbox.

For public-facing records, expose only the safe abstraction: steward, renewal posture, registrar class, DNS provider, and whether continuity has been checked recently. For private operations, keep the actual recovery path, payment owner, two-factor method, emergency contact, and transfer policy. That custody layer connects domains to GitHub, blogs, data storage, and OSINT: a name can be technically live while institutionally orphaned.

A domain node becomes useful when it stores more than the string itself. Useful graph predicates include resolves_to, redirects_to, canonical_for, uses_nameserver, registered_with, has_mx, authenticates_email_with, cert_issued_by, archived_at, hosts_project, documents_repository, and superseded_by.

Those fields let a knowledge graph connect a domain to blogs, semantic web metadata, search documents, external references, and archival captures without flattening everything into one untyped link.

When a site moves, expires, or changes ownership, wget captures can help preserve the old state: redirect chains, canonical pages, sitemap references, feed files, and source documents. The capture should stay tied to the domain record so provenance does not collapse into "found somewhere on the web."

For overlanding, a personal domain can make route reports, repair notes, and field photographs durable enough to cite, but it also increases responsibility around exact coordinates, private land, and fragile places. The domain record should distinguish public-safe reports from private trip archives.

A domain page should make the identity stack visible. Show the registered domain, canonical host, important subdomains, DNS provider, registrar, certificate surface, email authentication status, redirects, sitemap, feeds, and archive references as separate facts. A reader should be able to tell whether a domain is a brand, a publication, an application, an API namespace, an email trust surface, or a historical pointer.

For SEO and provenance, domains need literal language: DNS, domain name, canonical URL, redirect, registrar, nameserver, certificate, sitemap, RSS feed, email authentication, SPF, DKIM, DMARC, and public suffix. Those phrases match the operational questions people actually search for. The graph can then connect them to richer entities such as organization, repository, publication, archive capture, and structured data profile.

The display should also expose drift. A domain that moved cleanly, one that expired, and one that now points to unrelated content should not look equivalent. Status labels make domain history useful instead of merely nostalgic.

For a wiki, the safest pattern is to treat every domain as a time-bound claim: who controlled it, what it pointed to, which records supported that fact, and when it was checked.

Useful display states include active canonical domain, active redirect, parked, expired, transferred, archived, private, uncertain, and retired. Those labels keep domain records readable without pretending every operational detail belongs in the title. A compact status table can show the current state while the graph preserves older evidence.

Examples help readers understand the distinction: a personal blog may move from example.net to example.com while old post URLs redirect cleanly; a project may keep its GitHub repository but lose its documentation domain; a data portal may keep the domain while changing every endpoint path. These are different preservation problems, so the record should name the failure mode.

Canonicalization is where domain identity becomes observable. The graph should not only store the preferred domain; it should record how the public web behaves. Does http:// redirect to https://? Does the apex redirect to www, or the other way around? Do old article paths preserve slugs, issue 301 redirects, or collapse into a homepage? Does the canonical tag agree with the visible URL? Does the sitemap list the same host that users are meant to cite?

Those checks matter because domains often look healthy from the homepage while deep links decay. A migration can keep the logo, certificate, and landing page intact while breaking years of citations, RSS entries, backlinks, documentation URLs, and saved browser bookmarks. For blogs, books, public data sources, and GitHub documentation, old paths are part of the intellectual record.

The useful evidence bundle is compact: request URL, final URL, status code chain, canonical tag, sitemap host, robots policy, feed URL, certificate hostname, and archive capture. A wget crawl or Firecrawl audit can preserve the crawl surface, while RDAP and certificate transparency provide separate registration and issuance evidence. Keeping those layers separate prevents a domain from being treated as continuous just because one layer still resolves.

Domain nodes should be connected to hostnames, URLs, organizations, people, repositories, feeds, email systems, certificates, redirects, archives, and claims. A single domain can support many identities over time, and a single identity can move across many domains. The graph should make both directions visible.

Useful edges include registered_to, delegated_to, resolves_to, serves_site, canonicalizes_to, redirects_to, sends_mail_for, has_certificate, archived_at, cited_by, supersedes, parked_after, transferred_to, and formerly_hosted. Useful node kinds include domain, hostname, URL, DNS zone, registrar, registry, certificate, mail policy, sitemap, feed, archive capture, website, organization, and project.

For SEO and provenance work, the most important edge is often canonicalizes_to. It says which URL should receive link equity, citations, structured data, and reader trust. For OSINT and archival work, the most important edge may be formerly_hosted or archived_at, because the question is not what the domain means today but what it meant when a source cited it.

Common domain failures include:

• letting a domain expire because renewal, payment, or registrar access was not operationally boring;
• changing canonical domains without redirects, canonical tags, sitemap updates, and search-console follow-through;
• breaking email authentication during a web migration;
• splitting authority across too many microsites when one stable namespace would compound better;
• failing to preserve old URL paths after CMS or framework migrations;
• buying names with risky history, homograph confusion, or unresolved trademark conflicts;
• treating domains as only branding, when they also encode trust, persistence, email reputation, and link equity.

• RFC 1034: Domain names - concepts and facilities (opens in new tab)
• RFC 1035: Domain names - implementation and specification (opens in new tab)
• IANA Root Zone Database (opens in new tab)
• IANA Reserved Domains (opens in new tab)
• ICANN domain name basics (opens in new tab)
• ICANN glossary (opens in new tab)
• RDAP overview (opens in new tab)
• RFC 7482: Registration Data Access Protocol query format (opens in new tab)
• Public Suffix List (opens in new tab)
• RFC 9110: HTTP Semantics (opens in new tab)
• RFC 9111: HTTP Caching (opens in new tab)
• RFC 9112: HTTP/1.1 (opens in new tab)
• RFC 7208: Sender Policy Framework (opens in new tab)
• RFC 6376: DomainKeys Identified Mail (opens in new tab)
• RFC 7489: DMARC (opens in new tab)
• RFC 5280: Internet X.509 public key infrastructure certificate profile (opens in new tab)
• Certificate Transparency (opens in new tab)
• Wikidata: domain name (opens in new tab)

• SEO for canonical URLs, sitemaps, redirects, and crawl signals.
• Standards for DNS, RDAP, HTTP, email authentication, and certificate infrastructure.
• Blogs for durable publishing namespaces and feed identity.
• Semantic Web for entity identity and same-as relationships.
• Data Sources for provenance records and public evidence.
• Graphs, Data Storage, and Data Visualization for durable domain records, redirects, and rebuildable provenance.
• OSINT for public evidence collection around DNS, RDAP, certificates, and redirects.
• Overlanding for public trip reports, route provenance, and location-sensitive publishing.
• GitHub Repo Practices for repository, Pages, deployment, and documentation links that often sit behind a domain.
• wget for Web Archival for preserving domain-bound pages, redirects, and crawl evidence.