External Publication
Visit Post

[Pre-RFC] DNS domains as package namespaces

Rust Internals [Unofficial] April 26, 2026
Source

jmillikin:

GET https://{namespace}/.well-known/something.json is easy to explain, easy to understand the security properties (it's TLS), crates.io already does HTTPS fetches, and it works with any shared hosting that lets the tenant upload files (which is ... all of them, lmao).

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. That is, if I have a domain, it's easy for me to set DNS records without extra cost most of the time, but if I want to serve files that's extra cost, often extra monthly cost. And then if I want to serve HTTPS, I either need to pay more money, or set up automation with lets encrypt. DNS avoids these costs (and it also avoids the need to keep my server's software up to date).

Regarding DNSSEC, DoH (DNS-over-HTTPS) is more widely deployed and has superior security properties. So I don't think spoofed DNS data is a real risk.

jmillikin:

These requirements (summarized), if combined together, are in conflict with the concept of namespaces:

  • Packages may not be renamed.
  • Namespaces should be human-meaningful, not an opaque identifer.
  • It should be possible to transfer ownership of a package.
  • The name of a package should not misrepresent the owner of a package.

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. It's not clear what you mean by facade. Do you mean an actual crate that re-exports the other?


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).

Discussion in the ATmosphere

Loading comments...