Generated by TLDR This:
I don’t know what I did wrong, but I’ve angered one of the titans of the internet!
Unfortunately, not every web request can run the Cloudflare challenge page.
So, my original offense might not even have been against Cloudflare.
I had a terrible experience online for almost a week before everything cleared up.
The extension provides, what Cloudflare claims, is a privacy-preserving alternative to resolving CAPTCHA s on its challenge pages.
This might have affected the situation, but again, I have no insight into Cloudflare’s automated decision-making.
Jump in the discussion.
No email address required.
Do you mean "onchain TXT", like DNS TXT record?
My concern wouldn't be with storage size. It would be with the propagation, resolution, and synchronization of this information. Distributing all these network activities across a lot of peers means there needs to be more two-way communication to maintain integrity of the "web" of data, which could mean considerably more load on networks if many peers are involved. In short, the volume of two-way traffic scales exponentially with the number of nodes maintaining a "web" of distributed data. This would not only impact overall network bandwidth, but it would also incur a cost to performance. Maybe I'm misunderstanding ENS. Would any given peer be able to perform all address resolutions, or would it need to sometimes/frequently reach out to other peers on the network to do so?
Jump in the discussion.
No email address required.
That's like one of two things crypto definitely has you covered on. Any verifier and every miner needs one, stores the whole blockchain and facilitates lookups, it's integral to how they operate.
Jump in the discussion.
No email address required.
Again, I'm not talking about the "how" of it. I'm aware that blockchain has a way of doing that. I'm concerned with the intrinsic inefficiency of such systems deteriorating quality of service if implemented across the entire internet. Decentralization of a service across many more network nodes is necessarily less performant and more bandwidth intensive. This doesn't even get into the nature of how the current internet infrastructure has been optimized for downstream delivery.
Yes, ENS is something that could be used for niche applications. However, it's not scalable to a significant portion of the internet, let alone most of it.
Jump in the discussion.
No email address required.
Each full node has the entire block chain and is thus able to do a lookup without talking to other nodes. Are you under the impression DNS servers are all centralized.
Jump in the discussion.
No email address required.
Edit: Went back and reread your first comment:
Emphasis mine. I think I now understand what you were originally saying.
Ok, so to implement a blockchain solution for domain name resolution, the full DNS table would be stored on a node? You said that changes to ownership and configuration would be stored in the blockchain, so I presume this means that each node would take the blockchain with these changes and build the DNS table themselves? I.e. "Aquota bought bussy.net, bussy.net points to address 123.4.5.678" would be the latest entry and configuration for "bussy.net" and thus that would be the listing for that domain within the newly built DNS table.
How would domain registration be handled? Would a single company implement its own ENS-like system? Wouldn't this just lead to a similar issue whereby a single company is making these host-limitation decisions, just with a more distributed infrastructure? If not, how does the overall system decide when a domain registration is "valid"?
Would the complete change history of every domain within one of these ENS-like systems be stored indefinitely? If so, wouldn't that lead to deteriorating performance over time for the first building or rebuilding of a DNS table?
No, but they're more centralized than peer-to-peer systems.
Jump in the discussion.
No email address required.
I don't know why you're thinking of this as a hypothetical, it's a system that exists, you could just read the whitepaper.
Jump in the discussion.
No email address required.
I was being lazy and didn't want to research on my own. I also like to think this stuff out on my own to get an intuitive understanding.
To answer my question:
These key holders basically function as a hand-off ICANN.
TLDs are handled by smart contracts, which presumably establish the pricing rules for purchasing names within that TLD. My understanding is that these domain name purchases necessarily require compatible cryptocurrencies due to the algorithmic smart-contract enforcement. This seems like a major barrier to more widespread implementation.
It would be an absolute nightmare to try to shift the existing internet DNS infratructure onto this protocol.
Also, an interesting snippet in the FAQ:
Emphasis mine. This is indicative of the performance issues I was referring to previously. Decentralizing this functionality necessitates more information exchange between peers, thus further increasing bandwidth demand by this protocol.
Overall, though, fascinating stuff. I'm glad I looked into it.
Jump in the discussion.
No email address required.
This seems like a pretty trivial thing for browsers to do.
Jump in the discussion.
No email address required.
I misread it, the resolver handles the nameprep but the protocol itself requires that nameprep be done beforehand. In short, the protocol can encode bad data into the blockchain. This leads to problems like this.
Also, upon further reading, I see that the name resolution does not take place within the chain. The blockchain stores an owner and resolver for a namehashed entry, but the mapping of the name to an address takes place within a server listed as the resolver within the registry blockchain. When writing my previous comments, I was under the impression that address resolution took place within the blockchain.
Jump in the discussion.
No email address required.
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context