**Note; The author (me) was the person (for the longest time, since the beginning of DNS blocking in Malaysia) was the actual person executing the site blocking, was also responsible in industry participation and helping the government driving policies while pushing back to ensure that Internet neutrality and sanctity stays. I wrote the first national standards under MTSFB on Information & Network Security enforceable under CMA, applied to all telcos and have authored ISO standards on cyber security. **

Recent times, Malaysia was shocked by sudden issue of DNS blocking, which went from just DNS blocking to expanding its scope to DoH/DoT poisoning. In the subsequent sections, we will explore the impact of such measures, what are the issues and some information about MCMC's site blocking practices.

Blocking - Yay/Nay

When the idea of blocking or limiting access to websites were conceived, the immediate idea was to deny access to websites that contravene the laws of the land. The measure was discussed agreed at a time when Internet was booming, security standards were just being thought off and things were much simpler.

It started off with sites that clearly intravene the laws. Pornography is not allowed in Malaysia, became a defacto blocking requirements. Internet provided access to information, without any restrictions.

This came as a enforcement measure to address the requirements of Section 223, Communications and Multimedia Act 1998. The act says...

Improper use of network facilities or network service, etc. 233. (1) A person who— (a) by means of any network facilities or network service or applications service knowingly— (i) makes, creates or solicits; and (ii) initiates the transmission of, any comment, request, suggestion or other communication which is obscene, indecent, false, menacing or offensive in character with intent to annoy, abuse, threaten or harass another person; or Communications and Multimedia 119 (b) initiates a communication using any applications service, whether continuously, repeatedly or otherwise, during which communication may or may not ensue, with or without disclosing his identity and with intent to annoy, abuse, threaten or harass any person at any number or electronic address, commits an offence.

Well meaning, clear and makes sense, to most people. But we Malaysians know what the act was actually used for. So bad that it's even called Akta Sakit Hati.

I remember a time when we used to block all discussions regarding Lina Joy (that name stuck to my head) and even resulted in the blocking of MalaysiaKini (yes I carried out that as well, but there is another story to that part. Buy me a teh tarik and I spill tea).

The blocking request comes in a form of a letter from MCMC, in most instances citing Section 233 CMA. I've seen a number of request citing other acts, and interestingly even citing an enactment (legally enactment affects state level, but MCMC seem to think its national issue). ISPs at time challenge the request but very rare MCMC backs down from the request.

While blocking creates a list of non-permitted items, you also end up having this ever growing list of sites to be blocked. Extremely rare, MCMC would actually send cleaning request to remove old/unwanted sites from the list. There is no publicly available list provided by MCMC on sites that are blocked. The dynamic nature of Internet allows sites to change IP Addresses, change hostname because it's easily procurable. Beyond that, the blocking worked for rudimentary reasons.

That said, ISP/NSP also have to abide by the Mandatory QoS requirements to ensure that the services stay up. Imagine having a long block list to process before a DNSquery gets responded.

I can go at lengths about these processes, but I think you get the basic idea.

Technical issues with site blocking

The Internet works on the glue called DNS, or Domain Name Service. What it does, is to resolve a name to an address, specifically an internet address (either IPv4 or IPv6) address.

Example

Server: 202.188.18.188 Address: 202.188.18.188#53

Non-authoritative answer: Name: google.com Address: 216.58.200.14

Computers don't recognise names, only us humans do. Since it's not humanly possible to remember all the website IP address (and some servers host multiple websites), hence the domain name scheme was introduced.

When DNS blocking was introduced (I know I am repeating this), security standards weren't prevalent. Specifically DNSSEC.

ICANN has this to say about DNS and DNSSEC

DNS by itself is not secure DNS was designed in the 1980s when the Internet was much smaller, and security was not a primary consideration in its design. As a result, when a recursive resolver sends a query to an authoritative name server, the resolver has no way to verify the authenticity of the response. The resolver can only check that a response appears to come from the same IP address where the resolver sent the original query. But relying on the source IP address of a response is not a strong authentication mechanism, since the source IP address of a DNS response packet can be easily forged, or spoofed. As DNS was originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver originally queried by spoofing a response that appears to come from that authoritative server. In other words an attacker can redirect a user to a potentially malicious site without the user realizing it.

Recursive resolvers cache the DNS data they receive from authoritative name servers to speed up the resolution process. If a stub resolver asks for DNS data that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forged DNS response that is accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver. The resolver will then proceed to return the fraudulent DNS data to other devices that query for it.

As an example of the threat posed by a cache-poisoning attack, consider what happens when a user visits their bank's website. The user's device queries its configured recursive name server for the bank web site's IP address. But an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a web site created by the attacker. This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site to transfer funds or take other unauthorized actions.

The DNS Security Extensions (DNSSEC) Engineers in the Internet Engineering Task Force (IETF), the organization responsible for the DNS protocol standards, long realized the lack of stronger authentication in DNS was a problem. Work on a solution began in the 1990s and the result was the DNSSEC Security Extensions (DNSSEC).

DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it's not DNS queries and responses themselves that are cryptographically signed, but rather DNS data itself is signed by the owner of the data.

Every DNS zone has a public/private key pair. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures over that data. As the name "private key" implies, this key material is kept secret by the zone owner. The zone's public key, however, is published in the zone itself for anyone to retrieve. Any recursive resolver that looks up data in the zone also retrieves the zone's public key, which it uses to validate the authenticity of the DNS data. The resolver confirms that the digital signature over the DNS data it retrieved is valid. If so, the DNS data is legitimate and is returned to the user. If the signature does not validate, the resolver assumes an attack, discards the data, and returns an error to the user.

DNSSEC adds two important features to the DNS protocol:

Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated. Data integrity protection allows the resolver to know that the data hasn't been modified in transit since it was originally signed by the zone owner with the zone's private key.

Long story short, we tech folks of the Internet realise DNS can be manipulated, so to prevent the bad guys from doing DNS hijacking, the DNSSEC standards were introduced.

How does it affect DNS hijacking (whether good or bad guys)

When the DNS Zone is cryptographically signed, all records returned by the DNS Server can be verified if its coming from an authentic DNS Server. In the event that a rogue DNS server responds, then the name lookup will fail. (Courtesy: Microsoft)

If you are interested in the inner workings of DNSSEC, I have a link at resources section from Microsoft that gives you a clear indication.

So, whether the DNS Hijacking is done for legitimate reasons or not, this security feature will flag it as failed.

What about DoH/DoT

DoH or DNS over HTTP and DoT which is DNS over TLS was a further enhancement of the DNS protocol. In order to improve efficiency of the DNS protocol and to introduce added security and privacy, the extension to support HTTP/TLS for DNS was conceived. TLS is an end to end encryption, meaning from source to destination. It uses PKI (public key infrastructure) in form of digital certificates which are cryptographically signed by Public Certificate Authorities, which allows users to validate if they are hitting the right site.

In the recent DNS hijacking, it was observed that traffic going to dns.google.com (DoT) is being redirected to, in this case TM's DoT site. As such, the response now comes from TM and not Google. This implmentation will break some network clients who have embedded certificate validation as part of the process, rending the app to not work. In future, when browsers implement strict checking, in order to ensure that the DNS traffic is not tampered with, such hijacking attempts will cause failure in Internet use.

So what are you trying to say?

In short, both implementations of DNS Hijacking can and will interrupt (not catastropically) break the internet in Malaysia.

Creating such capabilities

Remember that these capabilities have to be created at the ISP in order for such hijacking to be done. What are some of the issues related to this?

While we believe that the government is acting on the rakyat's best interest, the use will not certainly stop at blocking porn or sites that violate the law. The use can and will be extended for other reasons, similar to how the Section 233 of CMA being used.

Meaning, the knife you use to cut carrots can be used for other crime.

Remember that such capabilities are powerful, and in hands of nefarious actors can cause huge damage. Threat actors, getting access to ISPs can now use this ability to redirect users to different malicious site.

A simple example, the PM of Malaysia may end up visiting a malicious site once a redirect rule is applied when he attempts to check his mail for [email protected] (fictitious of course). The network only recognises rules, not whose doing it or why.

Recently a major ISP in Malaysia had data breach and its data leaked.

Having such rulesets requires the network to be constantly available and working as normal. Anyone worked in an ISP will tell you that the network is constantly changing and upgrading, so there may be a time when things don't quite work. I recall an ISP having a DNS outage for some extended time. Because such redirect rules don't exist, users were able to simply change DNS settings and the Internet continued to work as per normal. Imagine if redirect rules were in effect, all DNS traffic will come to a grinding halt since its being redirected to the non-working ISP DNS servers.

So what are you saying?

By doing the DNS hijacking, the Internet becomes insecure for an average user.

Most users will simply click Okay to ignore any popup that comes in, when an error happens. Ask a few times, users will just ignore permanently.

An average user, who disables such notification in his/her due course of browsing will be subject to heightened risks of using the Internet, including a high chance of falling prey to online scams, banking fraud and other cyber related issues.

So, how do we address the original problem?

The internet is a vast resource of knowledge and content. I remember watching Tom and Jerry in my younger years, constantly chasing each other.

And thats what this venture is. To retrofit a global network of content into a legal framework, through technical means. You block one site, another comes up. You patch a hole, another one appears. I find this approach of DNS blocking is a band-aid approach rather than addressing the elephant in the room.

My suggestion? Start with education.

Teach whats right. What should be done, what should be avoided. Take a scientific approach instead of FUD (Fear, Uncertainty, Doubt). Malaysians are missing a key ingredient in their education - sex education.

When a topic becomes taboo, everyone becomes curious of it. Make it public, everyone moves on.

But I want technical solution.

Okay, give users a choice. Create a Madani DNS Server - dns1.madani.ny, dns2.madani.my - similar to some public DNS providers who have curated and safe content and allow people to use it at their own choice. You meet the objective of safe internet while not compromising security for others.

Resources

• Microsoft - DNSSEC - https://learn.microsoft.com/en-us/windows-server/networking/dns/validate-dnssec-responses