Unable to load image

:marseynull: Someone PISSED OFF Cloudflare, but NOT for the reasons you think :!marseykernelpanic:

https://www.ctrl.blog/entry/cloudflare-ip-blockade.html

Orange Site

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.

69
Jump in the discussion.

No email address required.

Lookups don't require onchain Tx, only changes to ownership and configuration.


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
Jump in the discussion.

No email address required.

onchain tx

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.

It would be with the propagation, resolution, and synchronization of this information.

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.


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
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.


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
Jump in the discussion.

No email address required.

Edit: Went back and reread your first comment:

DNS isn't the problem, it's other points of centralization due to economies of scale.

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?

Are you under the impression DNS servers are all centralized.

No, but they're more centralized than peer-to-peer systems.

Jump in the discussion.

No email address required.

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"?

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.


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
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:

The root node is presently owned by a multisig contract, with keys held by trustworthy individuals in the Ethereum community. We expect that this will be hands-off, with the root ownership only used to effect administrative changes, such as the introduction of a new TLD, or to recover from an emergency such as a critical vulnerability in a TLD registrar.

These key holders basically function as a hand-off ICANN.

Top-level domains, like ‘.eth’ and ‘.test’, are owned by smart contracts called registrars, which specify rules governing the allocation of their subdomains. Anyone may, by following the rules imposed by these registrar contracts, obtain ownership of a domain for their own use. ENS also supports importing in DNS names already owned by the user for use on ENS.

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:

Over time, we plan to reduce and decentralise human control over the system. Powers still held by the ENS root, such as those to set pricing and renewal conditions for domains, will be decentralised as robust systems become available to permit doing so.

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.

Nameprep and handling improper naming is now pushed onto all consumers. There's no way for a resolver to handle this problem itself. I'm not sure if this is how it currently happens with the current DNS infrastructure, but it seems like another scaling issue for this protocol.

This seems like a pretty trivial thing for browsers to do.


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
Jump in the discussion.

No email address required.

More comments

This comment is ignorant and/or naive. Lookups require onchain Tx in order to be verified and/or to prove ownership and/or configuration. Without onchain Tx, lookups are useless.

Jump in the discussion.

No email address required.

you should know better than this bbbb


:#marseytwerking:

:marseycoin::marseycoin::marseycoin:
Jump in the discussion.

No email address required.

:soycry:

Jump in the discussion.

No email address required.



Now playing: Steel Drum Rhumba (DKC2).mp3

Link copied to clipboard
Action successful!
Error, please refresh the page and try again.