4 ms·

Using a Rwandan TLD negates pretty much all the effort in finding the fastest provider. No glue records and an unresponsive TLD nameserver translates into 100+m

by r1ch 5y ago

Using a Rwandan TLD negates pretty much all the effort in finding the fastest provider. No glue records and an unresponsive TLD nameserver translates into 100+ms for the initial DNS lookup (likely the only one that matters for such a service).

YetAnotherNick 5y ago
If you don't know, DNS are cached at multiple layers, including ISP.
- acdha 5y ago
  This is technically correct but don’t rely on caching to solve this problem. Unless you’re getting a ton of widespread traffic you’ll probably be getting more cache misses than you expect - every time I did client-side monitoring, the DNS 90th percentile was quite notably higher than the 50th.
  - r1ch 5y ago
    The trend has definitely been towards lower and lower TTLs with cloud deployments and such. What used to be a 1 day TTL with a static host is now 5 minutes in the cloud. Servers that use geo DNS (EDNS-Client-Subnet) also cause considerable cache misses since the caching becomes very granular.
    - acdha 5y ago
      Good points - also people started using more TLDs and hostnames as the average page started loading different service endpoints directly in the client, and I got the impression that a fair number of places were slow to increase their DNS cache sizes.
Santosh83 5y ago
Well the homepage of the site opened pretty much instantly for me, and I've never visited it before to have cached its pages or IP address.
gnfargbl 5y ago
I'm not sure it's _so_ bad, in practice? If you dig +trace url.rw, you can see that the NS record for url.rw is held on ns-rw.afrinic.net, pch.ricta.org.rw, ns1.ricta.org.rw, ns3.ricta.org.rw and fork.sth.dnsnode.net. It's true that some of those servers are slower than others (for me, the AfriNIC server is 500ms whilst the dnsnode.net server is 50ms), but that shouldn't really matter because the TTL on the record is 86400. So the chances are that all the big DNS services (8.8.8.8 etc) should have the correct nameservers for url.rw in the cache already. Yes, if you're running a local-ish resolver, things are different... but most folks are dependent on Google, Cloudflare or their (large) ISP. The actual A record for url.rw is held on AWS's DNS servers, with a TTL of 300. But AWS's DNS servers are fast.

by r1ch 5y ago

YetAnotherNick 5y ago

If you don't know, DNS are cached at multiple layers, including ISP.

acdha 5y ago
This is technically correct but don’t rely on caching to solve this problem. Unless you’re getting a ton of widespread traffic you’ll probably be getting more cache misses than you expect - every time I did client-side monitoring, the DNS 90th percentile was quite notably higher than the 50th.
- r1ch 5y ago
  The trend has definitely been towards lower and lower TTLs with cloud deployments and such. What used to be a 1 day TTL with a static host is now 5 minutes in the cloud. Servers that use geo DNS (EDNS-Client-Subnet) also cause considerable cache misses since the caching becomes very granular.
  - acdha 5y ago
    Good points - also people started using more TLDs and hostnames as the average page started loading different service endpoints directly in the client, and I got the impression that a fair number of places were slow to increase their DNS cache sizes.

Santosh83 5y ago

Well the homepage of the site opened pretty much instantly for me, and I've never visited it before to have cached its pages or IP address.

gnfargbl 5y ago

I'm not sure it's _so_ bad, in practice? If you dig +trace url.rw, you can see that the NS record for url.rw is held on ns-rw.afrinic.net, pch.ricta.org.rw, ns1.ricta.org.rw, ns3.ricta.org.rw and fork.sth.dnsnode.net. It's true that some of those servers are slower than others (for me, the AfriNIC server is 500ms whilst the dnsnode.net server is 50ms), but that shouldn't really matter because the TTL on the record is 86400. So the chances are that all the big DNS services (8.8.8.8 etc) should have the correct nameservers for url.rw in the cache already. Yes, if you're running a local-ish resolver, things are different... but most folks are dependent on Google, Cloudflare or their (large) ISP. The actual A record for url.rw is held on AWS's DNS servers, with a TTL of 300. But AWS's DNS servers are fast.