{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigagphuofboujul3upu4hensfinecpabujoyytyhcrd6gqypzwaqe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkgzjl4db5c2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202#post_12",
  "publishedAt": "2026-04-27T00:55:51.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "> It's worth noting that requiring an HTTPS fetch to `.well-known/something.json` does increase the cost of this compared to the DNS-based approach. [...]\n\nSupporting alternate methods of domain verification (`TXT` records, ACME, `postmaster@` email, etc) can be added later if there's enough demand for them. For the initial version of an already-contentious feature I think it's important to use a verification mechanism that is easy to understand and deploy.\n\nEvery current user of crates.io has a GitHub account and therefore free access to a `{username}.github.io` domain, most domain registrars offer a small amount of free static file hosting, and many free hosting providers (including `github.io`) can be used with custom domain names.\n\n> I think they're just in conflict with your approach for namespaces. I don't find any of your proposed solutions to this very compelling.\n>\n> [...]\n>\n> I don't really think this is a good approach. DNS is fundamentally mutable, which is a property that we don't really want for the registry. People lose access to their domains all the time, and other people come into control of those domains (and it's possible for this to be done intentionally by bad actors).\n\nWhich approach to namespaces do you think would be better? Based on your response I'm guessing you'd prefer an opaque per-crate identifier such as a UUID, which per the thread is not a design that the crates.io team is willing to consider at this time.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}