#SecureSenses --verbose

DNS based censorship and domain blocking in Indonesia is very inconsistent among ISPs. There’s a government mandated black list which the ISPs operating in the country should enforce. However, Indonesia lacks centralised internet infrastructure and has many separate ISPs. In addition, the Indonesian government granted ISPs the authority to block content at their own discretion. All of this leads to a very inconsistent DNS blocking in Indonesia. Official DNS domain blacklist in Indonesia The Government mandated DNS blacklist is published in a redacted form and can be downloaded here: https://trustpositif.kominfo.go.id/ . This is where the blocked domains get redirected to. We can search the database and check if a domain is blocked. In the screenshot below we can see that a popular cryptocurrency exchange is blocked (Ada) and that wikipedia.org is not (Tidak Ada) - thanks to Google Translate. Examples of blocked DNS queries dig binance.com @182.253.45.122 ;; global options: +cmd ;; Got

In the Rogue DNS Server attack, a malicious actor configures a DNS server to act as the Authoritative Name Server for the targeted domain name. In simple terms he creates a DNS zone on a server and inserts DNS records of his choosing. This can be accomplished in the following ways: A legitimate DNS server gets compromised A DNS client gets pointed to a malicious DNS server (using DNS changer malware or by changing the router's DNS settings) By a malicious actor at an ISP or DNS provider (using his access to make unauthorized changes) With the Rogue DNS server in place, the original DNS query never reaches the legitimate Authoritative Name server. In fact it never reaches any server other than the compromised DNS resolver (that may not be exactly correct since usually any sizable recursive DNS infrastructure will have multiple layers of resolvers, forwarders and caching servers). Let’s look at an example. For this purpose we will spin up a simple Unbound DNS server instance that wil

Authoritative Name Server also referred to as NS, is a DNS server that is responsible for a particular DNS zone (domain). This is where the domain administrator configures DNS records in the zone.   Authoritative Name Servers are defined using NS (Name Server) resource record type. NS record type is described in RFC1035 - https://datatracker.ietf.org/doc/html/rfc1035#page-12 As depicted in the figure below, in a normal DNS resolution flow, a DNS client doesn't directly receive authoritative responses. It is a recursive resolver that iteratively queries the authoritative server on behalf of the client. For testing purposes we can query it directly. How to find Authoritative Name Servers? As with everything DNS related, dig to the rescue! Let’s query a recursive DNS resolver and ask it what the NS for securesenses.net. is: dig NS securesenses.net @8.8.8.8 ; <<>> DiG 9.10.6 <<>> NS securesenses.net @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HE

DNS injection is a type of a DNS poisoning attack in which, a network traffic monitoring device injects fake DNS responses. When a monitoring device detects a DNS query for a censored domain, it forges a fake response and sends it to the client.  This attack can be implemented by an on-path or an off-path device. This technique is commonly used by state actors to implement country based censorship.  We'll use The Great Firewall of China (GFW) to demonstrate this attack in practice.  Let's query wikipedia.org against Google DNS to get a baseline.  dig wikipedia.org @8.8.8.8 ; <<>> DiG 9.10.6 <<>> wikipedia.org @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61120 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;wikipedia.org.            IN    A ;; ANSWER SECTION: wikipedia.org.        234    I

There are two types of DNS queries: Recursive query Iterative query In a recursive query, the DNS resolver will respond with the final result, best answer it has or an error message. How it responds depends on what kind of DNS server it is. A recursive resolver will respond with the final IP address (or set of IPs). A non-recursive DNS server (Root or GTLD) will respond with the best answer it has. In an iterative query, the DNS resolver is required to provide the best answer it has. Assuming the queried record is not in the server’s cache, the DNS client will receive the referral to the next DNS server in the resolution path. That’s the theory. Let's look at practical examples. Recursive query DNS resolvers that are used by the DNS clients are referred to as “recursive resolvers”. Their purpose is to handle the queries, return the final resolution result and cache the response.  When a DNS client queries a recursive DNS resolver it receives the IP address (or an error). Recursive

DNS poisoning attacks are commonly referred to as DNS cache poisoning attacks. In reality DNS cache poisoning is only one class of DNS attacks. I have handled many real word DNS poisoning attacks but I have never observed actual cache poisoning attacks in the wild.   In this post we will cover the different types of DNS poisoning attacks, explain why they should not be referred to as DNS cache poisoning and make the case for a more relevant name for this class of internet censorship tactics.     For brevity, this will be a high level overview of the types of DNS attacks. Each will be covered in detail separately in a dedicated blog post.   I distinguish three types of network/server side DNS attacks: 1. DNS Cache Poisoning 2. DNS injection 3. Rogue DNS server   The above attacks don’t require any modification of the DNS client’s OS or the last mile router/modem. While outside of the scope of this article, for completeness client side based DNS attacks can be divided into the following: