Pointing .eth name to traditional website

Hoping somebody could clarify this for me. I understand Brave browser can resolve .eth names directly without having to use the .link addition. Do I still have to create and IPFS hash that associates my ENS name with a traditional domain name or can I simply update an ENS record to make this connection? Alternatively, is it possible to use Arweave insted of IPFS?

Thank you,

Yes Arweave is supported, you can set your content record to any ipfs/ipns/bzz/onion/onion3/sia/arweave URL.

You can also make the website immediately redirect to a traditional DNS website by using a script or meta tag. There’s an example of that here:

5 Likes

OK, that’s sort of what I thought. ENS cannot redirect directly to an IP address then. Out of curiosity, since IPFS can make the redirect, what is exactly is preventing ENS from also implementing this feature directly? Is it possible that this functionality can be added in the future or is there a more fundamental issue?

It’s not IPFS that is making the redirect per se. IPFS is just a decentralized storage protocol, but the HTML file you get from IPFS and load in your browser is doing the redirect (with a meta tag or script).

ENS is a completely different system built on a different network (Ethereum). What you describe is possible, but it’s not something that ENS would be responsible for implementing. ENS is just your decentralized address book, where your name points to any records you want.

You can even create completely custom records, like you could add an ipaddress record and point it to an IP address. But then if you wanted that to work in a browser, like actually request content from that address from the .eth name, you would need to make modifications to Brave Browser, etc, and convince those dev teams to merge your changes as well (or make your own browser).

Yes, this makes sense. But, Brave browser is querying information from ENS, right? As in, when I search a .eth name that has been set up as you describe it looks the name up in the ENS database, reads the IPFS hash, queries the stored html document, and then redirects, right? But since Brave is already referring to the ENS database what’s stopping it from reading an IP content record and immediately redirecting?

I’m hoping to do a deep dive for users looking to setup an entirely decentralized web presence, so I hope you don’t mind my inquiries. I’m just trying to fully understand the complexities and how things will likely be improved in the future. As is, most IPFS redirects I have seen are absurdly slow, but I understand this is largely due to the developing nature of IPFS. Even if speed couldn’t be solved by eliminating a step it seems adoption would be improved if non-technical ENS users could make redirects with a simple content record update. As ENS grows browsers should want to support ENS, so if that’s the only holdup I don’t think it will be for long.

Just a little clarification here, ENS isn’t a “database” per se, at least not in the way that most people consider to be a “database”. The ENS smart contracts, registry entries, and records are all stored on the Ethereum blockchain, which is a completely public and permissionless network. Typically when people refer to “databases” they mean a private (or permissioned) data storage solution that is centrally controlled by some company.

Nothing, assuming you do the legwork to get that implemented. You could come up with a record standard for that, get the ENS community on board with it, get browsers like Brave/etc to implement it, create pull requests in various projects where necessary, etc.

But if your goal is to “setup an entirely decentralized web presence”, then why do you want this in the first place? Why do you want to have your ENS name auto-resolve in your browser to a web2 IP address, which (just like the DNS root zone) is ultimately controlled by the Internet Assigned Numbers Authority (IANA), a centralized entity owned by ICANN and tied to the US government?

The main reason that the ENS contenthash record requires one of those protocols (ipfs/arweave/sia/bzz/etc) is because those are decentralized storage solutions. So you’re pointing your decentralized domain name to your decentralized website.

3 Likes

Good question. I think it would be preferable to host a website fully on the blockchain, but there is some difficulty I understand depending on the functionality needed. If you can self host rather than relying on a centralized hosting center that having a decentralized identity is at least a step in the right direction.

Good point. I admittedly don’t know the situation with IANA. I’m just very aware of cases of DNS registrars revoking ownership of domain names. ENS certainly provides a solution to this. Has IANA ever meddled with IP address issuance? The possibility alone is a valid concern of course.

Yes, this makes sense. I suppose I was just questioning why ENS wasn’t interested in creating a linked content record for IP address redirection given that the legwork was already done to get Brave onboard with the IPFS redirection. If it is a matter of principle I can understand that though.

1 Like

EIP 1185 provides for DNS records in ENS names, it’s currently listed as “Stagnant” but I’d like to see it revived.

We’re working on a resolver over at easyDNS which can resolve Handshake HNS, Stacks domain DNS RRs, if there is a way to put DNS RRs into an ENS name, we’d want to add that to our resolver.

https://eips.ethereum.org/EIPS/eip-1185

3 Likes

This is very interesting. It didn’t occur to me that the hosting of DNS records would require an EIP.

How exactly will your resolver work in the case of HNS?

1 Like