The .eth.link service has been extremely broken for years. It was always bad at updating, and lately itās been down for days on end.
As I understand it the history of this is that the ENS team originally built the service, then handed the domain over to Cloudflare, who either lack the technical skills required to run a website serving static HTML or just donāt really care about .eth.link.
As an alternative we have .eth.limo, which is brilliantly run but is just a really weird domain name, whereas .eth.link makes total sense.
I assume that at this point asking Cloudflare to get their act together would be flogging a dead horse, so is there anything we can do to bribe or shame them into giving up and transferring .eth.link to the .eth.limo people?
Afaik .eth.link still belongs to TNL who gave Cloudflare the right to use it.
To make a second functional gateway, we donāt necessarily need to transfer ownership of .eth.link, but any āethā DNS domain will be ok. However, Iām not sure if any are available.
OK great, so if we pass a governance proposal to ask TNL to transfer it to the .eth.limo people thatāll work?
There are of course other domains - I mean, .eth.limo is already another domain - but I donāt think thereās anything good. .link kind of uniquely makes sense for this purpose.
I support such a proposal. The reaction I have seen is consistently āthat is weirdā to the .limo variant. Whereas .link perfectly describes what it does. The best solution is of course all popular browsers implementing simply using the .eth instead.
Could you provide more details on the issues you are experiencing? This should help defining metrics to monitor and improve against, for all gateways operators.
Iām here to listen. For issues related with Cloudflare operation of eth.link, they are referenced in the public statuspage. Regarding the last one, a public report is being drafted.
*.eth.link A record should be a static DNS entry. The fact that wget is unable to resolve it is not expected.
Could you run the following and provide the response?
For what I can see, the main issue is the DNS server of your ISP returns a SERVFAIL when requesting vitalik.eth.link. This does not happen when using Google recursive DNS server 8.8.8.8.
About ns2.ethdns.xyz returning a REFUSED, this is expected. ns2.ethdns.xyz holds an NS to Google Cloud DNS nameservers ns-cloud-e1.googledomains.com, which is not a recursive DNS server, and returns REFUSED for domains it does not manage, resolver.cloudflare-eth.com.
Iām still trying to understand the reason for the SERVFAIL, and would update this post if I figure out something.
I donāt suppose you guys could try just setting the A records directly instead of having this extra step with the CNAME to resolver.cloudflare-eth.com?
@edmundedgar this is feasible, but makes maintenance harder. Iāll check if this can be added to vitalik.eth.link first to confirm it solves the issue you are facing.
If that works, then we would make a broader assessment on how this affect *.eth.link. Mainly, the CNAME helps for certificate provisioning internally.
If I may ask, does the SERVFAIL on your DNS resolver affect all *.eth.link domains?
Itās the same with every .eth.link Iāve tried, nothing special about vitalik.eth.link. The site Iāve been trying to get to work is reality.eth.link. If you want to try with some other .eth.link Iām happy to test whatever you try.
Just to add to this now we have an additional data point: Although .eth.link domains are normally unreachable from the DNS servers both my ISP and mobile providers, they work fine when the domain is redirected to a āthis domain has expiredā page. So if thereās a blacklist involved, itās somewhere further down like the IP address. Or it could be related to the CNAME setup or something.