Is there anything we can do to fix .eth.link?

šŸ’¬ General Discussion
#1

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?

2 Likes
#2

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.

1 Like
#3

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.

1 Like
#4

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.

1 Like
#5

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.

#6

I mean for instance right now:

wget https://vitalik.eth.link
ā€“2022-06-09 03:33:36-- https://vitalik.eth.link/
Resolving vitalik.eth.link (vitalik.eth.link)ā€¦ failed: Temporary failure in name resolution.
wget: unable to resolve host address ā€˜vitalik.eth.linkā€™

The same using .eth.limo:

wget https://vitalik.eth.limo
ā€“2022-06-09 03:33:33-- https://vitalik.eth.limo/
Resolving vitalik.eth.limo (vitalik.eth.limo)ā€¦ 174.138.125.8
Connecting to vitalik.eth.limo (vitalik.eth.limo)|174.138.125.8|:443ā€¦ connected.
HTTP request sent, awaiting responseā€¦ 200 OK
Length: 19841 (19K) [text/html]
Saving to: ā€˜index.html.1ā€™

index.html.1 100%[==============================================================================>] 19.38K 106KB/s in 0.2s

2022-06-09 03:33:34 (106 KB/s) - ā€˜index.html.1ā€™ saved [19841/19841]

Iā€™d also note that there is nothing about this current outage on the status page you linked.

#7

*.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?

dig +trace A vitalik.eth.link
#8

Output here, and the output from some other quick tests

#9

Thanks for the trace and additional commands.

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.

#10

If it helps I tried the nameservers on this list:

ā€¦and the ā€œAlternate DNSā€ nameserver 76.76.19.19 fails in the same way as my ISPā€™s nameserver and my mobile carrierā€™s nameserver.

Edit to add: I wonder if this is a malware blacklist or something, Alternate DNS says it does ad blocking.

#11

The malware list could explain it. I am not aware of a list that would include *.eth.link though.

Glad switching DNS server helped. Thatā€™s still an important accessibility issue for most, and the issue is still opened on Cloudflareā€™s side.

2 Likes
#12

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?

#13

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

1 Like
#14

Makes sense.

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.