Could a bad actor do anything bad if they're a TLD's nameserver? If so, what are some examples?
Yes and see some examples below (I remember right now at least the following relevant cases, and will add more later if my memory finds out others).
Attacks on key actors in the chain of DNS resolution
The latest attack on some actors in DNS land was probably not just by luck targeting registrars/root/TLD nameservers operators. See:
but in summary the door in the foot was:
The DNS records for the domains sa1.dnsnode.net and fork.sth.dnsnode.net also were changed from their rightful home in Sweden to the German hosting provider controlled by the attackers in December. These domains are owned by Netnod Internet Exchange, a major global DNS provider based in Sweden. Netnod also operates one of the 13 “root” name servers, a critical resource that forms the very foundation of the global DNS system.
Contacted on Feb. 14 by KrebsOnSecurity, Netnod CEO Lars Michael Jogbäck confirmed that parts of Netnod’s DNS infrastructure were hijacked in late December 2018 and early January 2019 after the attackers gained access to accounts at Netnod’s domain name registrar.
The DHS even published an emergency directive on this case: https://cyber.dhs.gov/assets/report/ed-19-01.pdf
It is a clever, long running, sophisticated attack and I recommend studying it as it shows a lot of vulnerabilities in the current domain name system; Kreb's post gives 7 remediations possible at end, note that not a single one alone could have prevented the problem - the provider did use DNSSEC in fact! - and hence that most of the vulnerability still exists today - registry locking of domain names is also something not widely known yet useful.
Attacks on registry infrastructure having vulnerabilities
TLD nameservers can be sometimes hijacked just because of technical errors/bad configuration, this is one example: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html
The registry used
ns-a1.io as authoritative nameserver on the TLD (and other ones with the same pattern)... except that at the same time anyone was free to register this name as a domain name and hence get complete control of a part of all DNS resolution for the whole TLD!
Non-technical attacks on "stealing" the TLD
While in part subjective,
.SK is a famous example.
with the core part being:
In 1995, the people operating the TLD at Comenius University started the takeover attempt by renaming their private company Softwarehouse, s. r. o. (s. r. o. stands for limited liability company) to EUnet Slovakia s. r. o., which was similar to the name of the informal group taking care of the registry. In addition, they relocated the company to a small leased office on the premises of Comenius University so they would share the postal address. Then, in 1999, they asked ICANN to do a minor adjustment of the delegation — delete “Comenius University” and add “s. r. o.” after “EUnet Slovakia.”
This was one case in my longer answer at https://superuser.com/questions/1332236/what-happens-to-country-specific-tlds-in-a-war-involving-that-country to the question "What happens to country specific TLD's in a war involving that country?" where you will find similarities and other examples.
The attempt to have a court take the whole
.ir TLD as a remediation would also be a case on non-technical TLD hijack.
Specific case of
ph "served" by
Going back to your specific case where you seem surprised that one of the
.ph authoritative nameservers (remember that there is no order, so do not say "first") is
ns2.cuhk.edu.hk hence under
hk administration, I can not tell exactly why and how but I know this:
not all ccTLDs have big infrastructure or money to pay DNS providers to have a full reliable anycast constellation of nameservers for their TLD resolution (even if they are some doing that almost for free). Hence it was always a long standing practice of ccTLDs trying to help each other, and hence exchanging DNS services by having TLD1 give TLD2 one of its nameserver as authoritative. It helps in load balancing and at least at the beginning there was no politics involved and this was mostly solved like BGP peering requests (over a beer at a bar).
Note also sometimes it can be used for technical reasons and locality if it is believed that a significant amount of the population of users interested by the domains under the TLD lives in a specific area of the world better served by a nameserver in another "location" (network location is far different than geographic localtion). As as example have a look how
.gp (Guadeloupe) uses as authoritative one nameserver from the French .fr registry (
nic.fr) and one from the European organization RIPE (which is/was providing secondary authoritative nameservers for many ccTLDs, especially smaller ones).
Now, one has to remember that when you use a domain in a ccTLD, you are under its jurisdiction. And anything can happen here.
.ly is a famous example in that regard (see for example https://www.forbes.com/sites/davidewalt/2010/10/06/libya-revoking-ly-domains-that-dont-adhere-to-sharia-law/), but extrapolating you can say that
.ph has a little risk in relying on an
.hk domain name for its core infrastructure. It is not a technical risk right now, but still a risk.
As Håkan touched in its answer but I think it merits expansion, any owner of one such TLD nameserver can theoretically do two things:
- capture the data and see queries coming at it: by virtue of the DNS protocol it would see only, on average, a share of all requests, around the same amount as any other nameservers
- change the data returned and hence potentially hijack connections; this could be detected if DNSSEC is in place (which not all TLDs do)
PS: you don't need a screenshot, and you are better without.
You can do a DNS query:
$ dig ph. ns +noall +ans
ph. 12h IN NS ns2.cuhk.edu.hk.
ph. 12h IN NS ns4.apnic.net.
ph. 12h IN NS 1.ns.ph.
ph. 12h IN NS ph.communitydns.net.
or a Whois query to IANA whois server:
$ whois -h whois.iana.org ph | grep nserver:
nserver: 1.NS.PH 126.96.36.199 2620:171:805:ad2:7068:0:0:1
nserver: NS2.CUHK.EDU.HK 188.8.131.52 2405:3000:3:6:0:0:0:15
nserver: NS4.APNIC.NET 2001:dd8:12:0:0:0:0:53 184.108.40.206
nserver: PH.COMMUNITYDNS.NET 220.127.116.11 2001:678:4:0:0:0:0:17