Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I strayed into the .PH TLD record on the IANA root zone database and found the first nameserver interesting.
I don't really know why they're there and I'm not in the right to assume, but considering the political climate in and between both countries (China and Philippines), it caused me a slight concern.
Could a bad actor do anything bad if they're a TLD's nameserver? If so, what are some examples? One that came to mind is DNS query harvesting then using it to track/profile users.
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).
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.
and:
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.
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
TL;DR:
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!
While in part subjective, .SK is a famous example.
See https://medium.com/@Oskar456/stolen-sk-domain-717e070f6735
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.
ph "served" by hkGoing 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:
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 206.51.255.1 2620:171:805:ad2:7068:0:0:1
nserver: NS2.CUHK.EDU.HK 137.189.6.21 2405:3000:3:6:0:0:0:15
nserver: NS4.APNIC.NET 2001:dd8:12:0:0:0:0:53 202.12.31.53
nserver: PH.COMMUNITYDNS.NET 194.0.1.23 2001:678:4:0:0:0:0:17
If an authoritative server "goes rogue" in some sense, it could data mine and/or make up any answers it wants for the subset of queries that land at that specific server.
Queries will be split across the the set of authoritative nameservers as specified by the NS records.
Each of these four "servers" (probably anycast clusters in at least some of these cases) could be assumed to handle somewhere around 1/4 of the queries in this example, assuming that they all have decent connectivity and work properly.
(Resolver implementations often have a strategy of essentially latching on to all servers that are "reasonably responsive" and spreading the queries across these.)
So yes, an abusive authoritative server operator could cause direct trouble (like making things resolve to the wrong addresses or making things not exist) as well as data mine the incoming queries.
All that said, if the ph zone was signed (which it for some reason is not), the authoritative server operators would not be in the same position of power regarding what data is served.
Contemporary resolver servers validate responses and would not accept responses for signed zones that do not include valid signatures, and in a setup like this the signatures would be generated by the zone owner (some branch of the government or their designated operator in the case of a ccTLD) and delivered as part of the zone data. The authoritative server operator would merely be serving the data they were handed (or I suppose they could try serving something else, but they cannot generate signatures for "something else").
In addition to the other answer given on this page - certificate authorities rely on DNS for domain validation when issuing certificates. If a bad actor is able to gain control of a TLD name server, they can dupe a CA into issuing a certificate for any domain in the TLD, by resolving the CA's DNS request to their own DNS server when the CA performs domain validation.
