I wonder if it would be a good idea to remake DNS on top of bluesky. The basic idea is that, if you own a domain name, you post DNS updates in a bluesky feed. The firehose itself is authoritative. DNS servers sit downstream of the firehose. All the updates to domain names get written into a database, and they essentially just respond to queries hitting that database. This would let anyone (with enough bandwidth) run a fast domain name server.
We could use this to fix some of DNS's long running problems. Like, we could add upstream cryptographic signatures to DNS records. And put TLS certificates in there too. We might be able to ditch TTL entries. In a DNS server, records should update via server-push from the firehose. You shouldn't have to wait for TTL to expire.
I think it'd make a nice little system.
I think you just invented blockchain DNS (e.g. https://handshake.org/) without the byzantine tolerance.
Yes, exactly. Blockchain DNS minus the blockchain is just good DNS.
Blockchain has some solid properties, don't throw the baby out with the bathwater.
What baby? DNS doesn't have the double spend problem. Why is the blockchain good for this?
The double spend problem for domains is the double domain purchase problem. I claim example.com and you also claim it, who wins?
Whoever buys it first. With a centralised database, this is trivial.
Usernames are the same. Who gets @example.bsky.social ? Whoever registers it first. Problem solved.
If you have a central database why do you need atproto?
To stream dns changes from site owners to dns servers. If you want to change a record, you post the change on atproto. DNS servers everywhere just subscribe to the jetstream. That way anyone can run a fast, local dns server which is kept up to date automatically.
How fast can I change my DNS records?
How fast can you post messages to Bluesky?
I'd like to see DNS ownership combined with the time range and an owner-unique key so you can go to the website you intended to visit rather than whoever happens to own the domain at the moment.
Why would they still have the server but not the domain?
Domains cost money to maintain. They can lapse, change, or be sold. Sometimes people make mistakes. So to my way of thinking they're great as a short-term named identifier but not as a long-term stable identifier. Would be nice to have both.
An authenticated chain similar to the crts for TLS certificates.
You don’t need a blockchain to implement a cryptographic chain of trust.
[dead]
How do you prove you own a domain with no records?
We’d need a registry of some sort. And a name space. Register a name, associated to a Bluesky account. Then use that Bluesky account to update dns records.
I think it would be a bad idea to have domain name ownership tied to one specific social media account. What if someone doesn't have Bluesky or doesn't want to have the two connected?
Then make an atproto account just for your dns. You can also self host atproto identity servers if you want.
How do you get the account's data?
I'm trying to work out how the OP's system would look like and I was wondering the same.
---
There are at least three parts that you'd need to solve:
1. AFAIK there is no single globally canonical Firehose. Different relays aggregate different sets of PDSes, and some might decide not to include your PDS if they don't like your content. The Firehose also isn't really the authority here. It transports signed updates from account repositories.
2. In theory you could make up a new kind of DNS record instead of NS, called PDS, PLC, or something. You'd ask your TLD registry to publish something like `PLC <did>` instead of the NS records for your DNS server.
The value should probably be the account DID (that's the PLC mentioned above), rather than the address of its PDS. The account DID is the stable identity that signs the repository updates. The PDS is just the server currently hosting that account's repository, and its address can change.
3. You then have a bootstrap problem. To get from an account DID to its PDS, you resolve the DID document and look for its `#atproto_pds` service entry. But `did:web` resolution uses HTTPS and therefore DNS. `did:plc` uses the PLC directory, but reaching that directory and then reaching the PDS URL also normally requires DNS.
So the DNS replacement would depend on the old DNS system to discover the server containing its DNS records.
---
Then, as an example, Google's DNS resolver at 8.8.8.8 would subscribe to one or more Firehoses, index DNS records from account repositories, and verify that their updates were signed by the DID named in the registry record.
Querying would then be something like: you look at the top-level record for the domain, see that there is no NS entry, find the PDS or DID entry, and look in your local Firehose-derived database for DNS entries signed by that account.
If the records aren't there, you might resolve the DID, find the current PDS, and fetch the repository directly. But that brings you back to the bootstrap problem.
Maybe the registry record would need to include both the DID and some kind of glue-like PDS address. Or perhaps the new system would need an independent way of resolving DIDs and locating PDSes without using DNS. I'm not sure what that would look like, especially once you include PDS migration and key rotation, but I think this is an additional part the proposal would need to solve.
/shrug
this is not quite what you are asking for but https://marque.at exists
No A, no B. It's not X, it's Y.
it's the support infrastructure for the other half of the project