The Fiji DNS servers are unreachable, but you can get as far as a router at the University of the South Pacific. So the problem is local to there.
traceroute 144.120.146.1
traceroute to 144.120.146.1 (144.120.146.1), 30 hops max, 60 byte packets
...
8 AARNET-PTY.edge5.London1.Level3.net (217.163.113.74) 274.795 ms 274.476 ms 273.781 ms
9 xe-0-0-0.pe1.a.suv.aarnet.net.au (113.197.15.213) 312.534 ms 311.764 ms 311.766 ms
10 fastethernet0-0.aarnie.usp.ac.fj (202.158.204.194) 313.356 ms 312.176 ms 312.363 ms
11 * * *
12 * * *
Fijivillage.com reports: "All websites and apps hosted in Fiji with the dotcom.fj suffix are currently down and this has also affected Vodafone’s M-PAiSA services.
This is due to an outage in the University of the South Pacific hosted dotcom.fj domain." [1][2]
I use 24 hours on anything I'm not planning on making changes to. High TTL is a better experience for customers because they'll probably have it in local-ish caches even if there is internet routing disruption.
And 10 mins on anything I'm about to make changes to. That means if I accidentally make the wrong change, the 'blast radius' is minimized.
Obviously, when changing 24h down to 10 mins, keep a close eye on DNS server load, packet loss on links close to it, etc. If in doubt, raise and lower ttl's slowly.
I would recommend an hour for almost everything except where very fast updates is expected, in which case 5m is my lowest number (I work at a registrar).
There are rumors of DNS resolvers deciding that some TTLs are “too low” to be valid, and applying their own default TTL value instead, thereby negating any benefit a low TTL would have had.
If the DNS server is out for more than 1 minute you'll get an outage. You also increase latency by preventing anybody from caching the response for more than 1 minute.
3 of the 5 nameservers for fj are online and responding (they are all anycasted around the world). It looks like connectivity to Fiji itself is what is disrupted.
Two are operated by gransy.com and one by PCH.net (which you should consider donating to and helping random country codes stay online: https://www.pch.net/about/donate).
"Google Public DNS is a validating, security-aware resolver. All responses from DNSSEC signed zones are validated unless clients explicitly set the CD flag in DNS requests to disable the validation."
couldn't get address for 'ns4.fj': not found
couldn't get address for 'ns5.fj': not found
couldn't get address for 'ns2.fj': not found
couldn't get address for 'ns1.fj': not found
couldn't get address for 'ns3.fj': not found
dig: couldn't get address for 'ns4.fj': no more
This is why I always say you should think twice when choosing a ccTLD if you don’t have a presence there. Not every registry has the same uptime as Verisign.
Given the amount of past outages of ccTLDs we've seen (almost none), i'd say this problem is negligible and nothing to worry about.
There is one very recent exception however, the russian plans to partly separate from the internet shortly (especially regarding DNS) could well be an issue.
Technical and legal issues that cause issues for customers at small ccTLDs are not uncommon. It all depends on who is running the registry. Try "cctld hijacked" and "cctld downtime" in your favorite search engine for a dozen or so examples.
Registries range in resources from "highly experienced billion-dollar organizations", to literally "we have a guy who updates the zone file in notepad", and they range in legal environment from, "functional democratic state with well-established judiciary" to "our government was violently overthrown this week".
Whether or not the problem is negligible depends on your particular use-case. For some, it might be a good choice, for others, it might not be.
Like I have said before¹²: Neither your registrar nor your chosen TLD registry should be in the habit of suspending domains at the drop of a hat, or be at risk of going out of business suddenly. If you mostly trust your local government, your national ccTLD should suffice. In fact, it should be your default choice unless you have strong indications it does not fulfill the above criteria.
.io is the TLD for the British Indian Ocean Territory, which is associated with the forced displacement of the Chagos islander people to make room for the Diego Garcia military base, amongst others. The British unilaterally decided to detach the Chagos archipelago from Mauritius before it got independent, which the deported people say (not without reason) is a crime against their human rights.
To back that up - the Chagosian claim is backed by the UK and rulings at the International Court of Justice. The UN supports Mauritius' claim to the territory.
Even besides the literal crimes against humanity, the .io domain really doesn't need to exist - what with the British Indian Ocean Territory having no permanent population and really not being a country at all.
Google's DNS server at 8.8.8.8 is having problems.
Lookup using DNS server of sonic.net, which is a normal DNS server.
Lookup with Google DNS: Checking example.com to make sure Google DNS server is live. Also fails with 1.1.1.1 DNS server.The Fiji DNS servers are unreachable, but you can get as far as a router at the University of the South Pacific. So the problem is local to there.
[1] https://www.usp.ac.fj/