jdevalk · jdevalk · Aug 8, 2026 · Aug 8, 2026
diff --git a/public/.well-known/agent-skills/index.json b/public/.well-known/agent-skills/index.json
@@ -6,7 +6,7 @@
       "type": "skill-md",
       "description": "Query and apply The Website Specification — a platform-agnostic specification of what a good website does. Use when the user asks what their site should have, whether something is required, how to audit a URL, what's missing for agent readiness, or anything else where you'd otherwise be guessing at web best practice. Backs answers with primary sources and ships an MCP server with search, list, fetch, checklist, and audit tools.",
       "url": "/.well-known/agent-skills/specification-website/SKILL.md",
-      "digest": "sha256:0150bdc77567dbaf9d9739af3cdea7015902e656ff2b39f96c2e01377a0b92e1"
+      "digest": "sha256:bba469a59dfcb3a619678878967f0cbf83f4bb95d3cd6ecd07bf8209e0d6aeaf"
     }
   ]
 }
diff --git a/public/.well-known/agent-skills/specification-website/SKILL.md b/public/.well-known/agent-skills/specification-website/SKILL.md
@@ -5,7 +5,7 @@ description: Query and apply The Website Specification — a platform-agnostic s
 
 # specification.website
 
-The Website Specification is a single source of truth for what a good website does. Ten categories, 167 pages, every item tagged with a status. It ships in three machine-readable forms: per-page Markdown, llms.txt / llms-full.txt, and an MCP server.
+The Website Specification is a single source of truth for what a good website does. Ten categories, 168 pages, every item tagged with a status. It ships in three machine-readable forms: per-page Markdown, llms.txt / llms-full.txt, and an MCP server.
 
 ## When to use this skill
 

diff --git a/public/og-default.png b/public/og-default.png
diff --git a/public/og/checklist.png b/public/og/checklist.png
diff --git a/public/og/spec.png b/public/og/spec.png
diff --git a/public/og/spec/foundations.png b/public/og/spec/foundations.png
diff --git a/public/og/spec/foundations/for-sale-dns.png b/public/og/spec/foundations/for-sale-dns.png
diff --git a/src/content/changelog/2026-08-08-for-sale-dns.md b/src/content/changelog/2026-08-08-for-sale-dns.md
@@ -0,0 +1,8 @@
+---
+title: A domain can now say it is for sale, in DNS
+date: "2026-08-08"
+type: added
+relatedSlugs: [for-sale-dns, dnssec, caa-records]
+---
+
+Added a page on [`_for-sale` DNS records](/spec/foundations/for-sale-dns/), the reserved leaf node name RFC 10023 registered in July 2026. It is `optional` for the obvious reason, but the interesting part is that it is not domain parking: the record sits beside a live site, tells a browser nothing, and answers the one question WHOIS and RDAP cannot — a name being registered has never meant it is unavailable.
diff --git a/src/content/spec/agent-readiness/dns-aid.md b/src/content/spec/agent-readiness/dns-aid.md
@@ -6,7 +6,7 @@ summary: "Publish SVCB/HTTPS records under _agents.example.com so agents can dis
 status: optional
 order: 85
 appliesTo: [all]
-relatedSlugs: [link-headers, mcp-and-tool-discovery, dnssec, well-known-overview, a2a-agent-cards, agentic-resource-discovery]
+relatedSlugs: [link-headers, mcp-and-tool-discovery, dnssec, well-known-overview, a2a-agent-cards, agentic-resource-discovery, for-sale-dns]
 updated: "2026-05-29T11:27:49.000Z"
 sources:
   - title: "draft-mozleywilliams-dnsop-dnsaid — DNS for AI Discovery"

diff --git a/src/content/spec/foundations/for-sale-dns.md b/src/content/spec/foundations/for-sale-dns.md
@@ -0,0 +1,95 @@
+---
+title: "_for-sale DNS records"
+slug: for-sale-dns
+category: foundations
+summary: "If a domain is genuinely for sale, say so in DNS. A TXT record at _for-sale.example.com advertises it to brokers and availability services without taking the site down or parking it."
+status: optional
+order: 180
+appliesTo: [all]
+relatedSlugs: [dnssec, caa-records, dns-aid, well-known-overview]
+updated: "2026-08-08T00:00:00.000Z"
+sources:
+  - title: 'RFC 10023 — The "_for-sale" Underscored and Globally Scoped DNS Node Name'
+    url: "https://www.rfc-editor.org/rfc/rfc10023.html"
+    publisher: "IETF"
+  - title: "RFC 8552 — Scoped Interpretation of DNS Resource Records through Underscored Node Names"
+    url: "https://www.rfc-editor.org/rfc/rfc8552"
+    publisher: "IETF"
+  - title: "IANA — Underscored and Globally Scoped DNS Node Names registry"
+    url: "https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml"
+    publisher: "IANA"
+---
+
+## What it is
+
+`_for-sale` is a reserved DNS leaf node name, defined by RFC 10023 (Informational, July 2026) and registered with IANA. A `TXT` record published at `_for-sale.example.com` signals that `example.com`, although registered and resolving normally, is available for purchase.
+
+```dns
+_for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale"
+```
+
+The record carries a mandatory version tag followed by at most one `tag=value` pair:
+
+| Tag     | Meaning                          | Example                              |
+| ------- | -------------------------------- | ------------------------------------ |
+| `ftxt=` | Free human-readable text         | `ftxt=Eligibility criteria apply.`    |
+| `furi=` | Contact or information URI       | `furi=mailto:hq@example.com`         |
+| `fval=` | Asking price, currency + amount  | `fval=EUR2500.00`                    |
+| `fcod=` | Proprietary code, by prior agreement | `fcod=XX-aHR0cHM...`             |
+
+The wrong belief to clear first is that this is a way of *parking* a domain. It is close to the opposite. Parking replaces the site with a sales page, which costs you every visitor the domain still has. `_for-sale` sits beside a live site in DNS and says nothing to a browser: the homepage keeps serving, the mail keeps flowing, and the record can be added and removed at will. RFC 10023 makes the point explicitly — the convention is designed to work while the domain is still in active use.
+
+It is also not the same thing as registration data. WHOIS and RDAP answer "is this name registered?"; a registered name may still be purchasable, and an unregistered one may not be worth having. That gap is the whole reason the convention exists, and it is why brokers and automated availability services are the intended audience rather than people.
+
+## Why it matters
+
+The signal a domain owner most wants to send is the one there has never been a channel for. If you are willing to sell, the interested buyer has no way to learn that short of a cold email to a WHOIS contact that privacy redaction has probably removed. Enquiries that would have been welcome never arrive, and the ones that do arrive are indistinguishable from spam.
+
+Putting the signal in DNS rather than on the page is what makes it useful to the parties who can act on it. A broker or an availability service checking a name resolves it anyway; one extra lookup tells them what a rendered page could not, because nothing on a working homepage says "the domain under this is negotiable". It is externally checkable, costs one record, and carries no risk to the site itself — a browser never sees it.
+
+## How to implement
+
+Publish a single `TXT` record at the `_for-sale` leaf of the zone you are selling, and only while you mean it.
+
+```dns
+; Free text
+_for-sale IN TXT "v=FORSALE1;ftxt=Serious offers only"
+
+; A URI to negotiate through — https, mailto and tel are the usable schemes
+_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"
+
+; An asking price: uppercase currency code, then the amount
+_for-sale IN TXT "v=FORSALE1;fval=USD12500"
+```
+
+Rules worth getting right the first time:
+
+- **The version tag is mandatory** and case-sensitive: every record starts `v=FORSALE1;`. It exists so a processor can tell a real `_for-sale` record from an unrelated `TXT` record that a DNS wildcard happened to expand into that name.
+- **One tag-value pair per record.** To publish a price *and* a contact URI, publish two records in the same RRset and let the processor pick what it understands. This is not SPF; the pairs do not concatenate.
+- **One character-string per record**, 255 octets maximum, so nothing has to be reassembled during parsing.
+- **Keep the TTL at 3600 seconds or less.** A stale record advertising a price you have withdrawn, or a domain you already sold, is worse than no record.
+- **Place it at a leaf.** `_for-sale.example.com` is valid at any level of the tree, but `xyz._for-sale.example.com` is not, and records under `.arpa` must be ignored — an offer to sell address space is out of scope.
+- **Remove it when the domain is no longer for sale.** The convention has no "not for sale" value; absence is the only way to say no.
+
+Sign the zone with [DNSSEC](/spec/security/dnssec/) if you can. An unsigned `TXT` record asserting your domain is for sale, at a price, with a contact URI, is a comfortable thing for someone else to forge.
+
+This site does not ship a `_for-sale` record: specification.website is not for sale.
+
+## Common mistakes
+
+- **Cramming several pairs into one record.** `"v=FORSALE1;fval=EUR2500;furi=https://…"` looks reasonable and is not what the format defines. Use one pair per record, multiple records per RRset.
+- **Publishing it aspirationally.** The indicator is only for domains actually available. It is not a marketing banner, and a record that exists to lure enquiries is an abuse the RFC calls out by name.
+- **Assuming it obliges anyone.** Publishing the record does not commit the holder to sell, and an advertised `fval=` price is indicative — the RFC tells processors to display a disclaimer and never to treat it as a purchase commitment.
+- **Expecting a wildcard to cover a whole zone.** `_for-sale.*.example.com` is not a valid wildcard. There is no way to put every domain under a TLD up for sale with one record.
+- **Trusting the content.** If you are on the reading side, `ftxt=` is attacker-controlled text and `furi=` is an attacker-controlled URI. Sanitise before display — the RFC's own example content is `<script>...</script>` — and never auto-navigate a user to a `furi=` target without an explicit confirmation step.
+
+## Verification
+
+```bash
+dig +short TXT _for-sale.example.com
+```
+
+- The answer begins with `v=FORSALE1;` and contains at most one `tag=value` pair per string.
+- The TTL is 3600 or lower: `dig TXT _for-sale.example.com | grep _for-sale`.
+- If the zone is signed, `dig +dnssec TXT _for-sale.example.com` returns a validating `RRSIG`.
+- The record resolves at all. During a redemption or `pendingDelete` period, or when DNSSEC validation is bogus, the name will not resolve and the signal silently disappears.
diff --git a/src/content/spec/security/caa-records.md b/src/content/spec/security/caa-records.md
@@ -6,7 +6,7 @@ summary: "A CAA record tells certificate authorities which of them are allowed t
 status: recommended
 order: 110
 appliesTo: [all]
-relatedSlugs: [https-tls, hsts, dnssec]
+relatedSlugs: [https-tls, hsts, dnssec, for-sale-dns]
 updated: "2026-05-29T09:13:20.000Z"
 sources:
   - title: "RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record"

diff --git a/src/content/spec/security/dnssec.md b/src/content/spec/security/dnssec.md
@@ -6,7 +6,7 @@ summary: "DNSSEC cryptographically signs DNS records so resolvers can verify the
 status: optional
 order: 120
 appliesTo: [all]
-relatedSlugs: [caa-records, https-tls, hsts]
+relatedSlugs: [caa-records, https-tls, hsts, for-sale-dns]
 updated: "2026-08-08T00:00:00.000Z"
 sources:
   - title: "RFC 4033 — DNS Security Introduction and Requirements"