(DIR) <- Back
# DNS Hijacking in Europe?
Last modification on 2023-06-08
Recently, I was forced to switch ISP because of the availability at my new flat.
Short after the connection was finally established, I began noticing really
strange behaviors on my OpenBSD gateway.
On my firewall, I usually run a caching *unbound(8)* resolver, querying root
resolvers directly - or some uncensored public DNS service. The first thing I
noticed via this connection, were the response-times being awkwardly off in
comparison to the usual latencies for given servers.
## Going down the rabbit hole
So I started digging deeper, and started to play with resolving "bad" domain
names, given that ISPs here are forced to *DNS-block* specific
copyright-infringing services by court order.[^1] **See disclaimer below.**
Very quickly I came to the conclusion, that my *unencrypted* DNS requests to
**any** public DNS service are tampered with by my ISP (or, more specifically
their blackbox-router). Every single request is answered by the ISP-owned
DNS-servers (including blacklists), regardless of the destination.
This practice is actually called **DNS hijacking**[^2] (falls into the category
of *DPI* - deep packet inspection), and has been common practice in oppressive
regimes for years. Seeing such measures in Central Europe really worries me,
because *network neutrality* is really in danger in the long run.
ICANN, the international agency responsible for top-level-domain administration,
has stated the following regarding this topic.[^3]
ICANN strongly discourages the use of DNS redirection, wildcards,
synthesized responses and any other form of NXDOMAIN substitution in
existing gTLDs, ccTLDs and any other level in the DNS tree for
registry-class domain names.
Actually, I found out, that the specific new router-model seen doing the DNS
hijacking is named "Technicolor CG4336DTA1", and surprise - contains GPL-code.
I already issued a request for all source code plus modifications on behalf of
the license.
Additionally, I contacted the responsible agency[^4] for matters regarding
network neutrality and router freedom to inspect the behavior.
[^1]: http://netzsperre.liwest.at/
[^2]: https://en.wikipedia.org/wiki/DNS_hijacking
[^3]: https://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09-en.pdf
[^4]: https://www.rtr.at/rtr/startseite.de.html
## Workaround
For me personally, the reaction to this behavior has been to force
*DNS-over-TLS*[^5] on my *unbound(8)* instance, which is used by all DHCP
clients in the network - tampering with the encrypted DNS packets is impossible.
Additionally, I set up some firewall rules in the LAN, to redirect all DNS
traffic to my gateway, so that no leaks to my ISP are possible.
*DNS-over-HTTPS*[^6] would also be a good candidate, as blocking port *443*
won't be possible in the end.
[^5]: https://en.wikipedia.org/wiki/DNS_over_TLS
[^6]: https://en.wikipedia.org/wiki/DNS_over_HTTPS
## Bloody evidence
**Disclaimer: I neither use the services named below, nor do I endorse the
usage of those websites. This is just for demonstration & research purposes.**
Additionally mirrored on the following sites:
- https://0x0.st/HcPB.txt
- http://sprunge.us/Z5VAfc
- https://pastebin.com/55MJHQ7m
### Via that ISP in Austria
**Cloudflare DNS**:
```
~ ❯ dig @1.1.1.1 kinox.to
; <<>> dig 9.10.8-P1 <<>> @1.1.1.1 kinox.to
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48860
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kinox.to. IN A
;; ANSWER SECTION:
kinox.to. 360 IN CNAME unavailable.for.legal.reasons.
unavailable.for.legal.reasons. 196 IN A 212.166.122.119
;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jun 07 22:33:45 CEST 2023
;; MSG SIZE rcvd: 96
```
**OpenNIC** (ns31.de):
```
~ ❯ dig @195.10.195.195 kinox.to
; <<>> dig 9.10.8-P1 <<>> @195.10.195.195 kinox.to
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25115
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kinox.to. IN A
;; ANSWER SECTION:
kinox.to. 360 IN CNAME unavailable.for.legal.reasons.
unavailable.for.legal.reasons. 24 IN A 212.166.122.119
;; Query time: 25 msec
;; SERVER: 195.10.195.195#53(195.10.195.195)
;; WHEN: Wed Jun 07 22:32:01 CEST 2023
;; MSG SIZE rcvd: 96
```
### On some random server in Northern Europe
**Cloudflare DNS**:
```
~ ❯ dig @1.1.1.1 kinox.to
; <<>> dig 9.10.8-P1 <<>> @1.1.1.1 kinox.to
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17749
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kinox.to. IN A
;; ANSWER SECTION:
kinox.to. 300 IN A 172.67.193.135
kinox.to. 300 IN A 104.21.65.226
;; Query time: 40 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jun 07 22:29:20 CEST 2023
;; MSG SIZE rcvd: 69
```
**OpenNIC** (ns31.de):
```
~ ❯ dig @195.10.195.195 kinox.to
; <<>> dig 9.10.8-P1 <<>> @195.10.195.195 kinox.to
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;kinox.to. IN A
;; ANSWER SECTION:
kinox.to. 300 IN A 172.67.193.135
kinox.to. 300 IN A 104.21.65.226
;; Query time: 31 msec
;; SERVER: 195.10.195.195#53(195.10.195.195)
;; WHEN: Wed Jun 07 22:30:52 CEST 2023
;; MSG SIZE rcvd: 69
```
.