0

I run a network with a router from my ISP and a WiFi access point from TP-Link. The access point has a static IP address (192.168.0.100) and its DHCP server is disabled.

My computer runs Linux with dnsmasq enabled and employs it as its primary name server. I expected this server to forward all requests that it cannot resolve to the DNS server of my ISP router and, therefore, the domain that is supposed to lead to the web interface of the TP-Link router, tplinkwifi.net, to stop working.

I was very surprised when I saw that this domain is in fact still resolved to 192.168.0.100. Tracing the DNS lookup didn't clear up my confusion: It seems like it is actually a global DNS server that responds with the respective IP address from my local network:

$ dig +trace tplinkwifi.net

; <<>> DiG 9.11.25-RedHat-9.11.25-2.fc33 <<>> +trace tplinkwifi.net
;; global options: +cmd
.           5693    IN  NS  h.root-servers.net.
.           5693    IN  NS  a.root-servers.net.
.           5693    IN  NS  l.root-servers.net.
.           5693    IN  NS  b.root-servers.net.
.           5693    IN  NS  f.root-servers.net.
.           5693    IN  NS  g.root-servers.net.
.           5693    IN  NS  i.root-servers.net.
.           5693    IN  NS  e.root-servers.net.
.           5693    IN  NS  k.root-servers.net.
.           5693    IN  NS  m.root-servers.net.
.           5693    IN  NS  d.root-servers.net.
.           5693    IN  NS  j.root-servers.net.
.           5693    IN  NS  c.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

tplinkwifi.net.     0   IN  A   192.168.0.100
;; Received 48 bytes from 192.36.148.17#53(i.root-servers.net) in 83 ms

How is this possible?

2

Dig thinks the response came from a root server. But root servers do not produce such responses – they're not recursive, they're only authoritative for the . zone and nothing else. (If you were actually talking to a root server, you would have gotten a referral to the servers handling .net instead.)

From that it would seem that your router actually intercepts all DNS requests – no matter what server you're trying to contact – and if the request was for "tplinkwifi.net" then the router sends you a spoofed response of its own, without actually letting you contact the server.

4
  • That makes more sense, thank you. When you're talking about the router that intercepts the DNS requests, are you referring to the ISP router or to the access point? If it is the former: Do you have any idea why it would even bother with a special treatment of a domain that is absolutely meaningless from its point of view? If it is the latter: Why would it be able to do that? My computer shouldn't have a clue that 192.168.0.100 is by any means a special node, should it? – user1249788 Dec 10 '20 at 6:48
  • I'm talking about the TP-Link. Admittedly it's unusual for an access point (being a bridge) to still intercept IP packets – but if the manufacturer wanted to make it "easy to access", they would still easily have done it. – user1686 Dec 10 '20 at 7:01
  • For a test, run dig tplinkwifi.net @203.0.113.1 – that address is definitely not a DNS server at all – and if that still produces a response, you can be sure it didn't come from the real 203.0.113.1 – user1686 Dec 10 '20 at 7:03
  • I didn't take into account that the access point is special due to the fact that it is responsible for forwarding all my traffic. So that makes sense, I guess. Thank you! – user1249788 Dec 10 '20 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy