Emulate a DNS server?

[brlin-tw]

Currently, the Wi-Fi hotspot TetherFi created announces that it has a DNS server at 192.168.49.1:

$ sudo nmap --script broadcast-dhcp-discover
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-08 17:24 CST
Pre-scan script results:
| broadcast-dhcp-discover: 
|   Response 1 of 1: 
|     Interface: wlp1s0
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.49.1
|     Domain Name Server: 192.168.49.1

, which isn't really available:

$ dig google.com @192.168.49.1

; <<>> DiG 9.18.18-0ubuntu2.1-Ubuntu <<>> google.com @192.168.49.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 12644
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 8 msec
;; SERVER: 192.168.49.1#53(192.168.49.1) (UDP)
;; WHEN: Wed May 08 17:21:28 CST 2024
;; MSG SIZE  rcvd: 28

I would like to ask whether we can emulate one that listens on {tcp,udp}://192.168.49.1:53 and responds to clients' DNS queries so that client DNS resolution can still work without relaying the request to the HTTP proxy service?

[pyamsoft]

I don't think so because we would need root to bind to port 53 as its privileged.

Also writing a DNS server sounds like a large undertaking, and its beyond my current ability.

[brlin-tw]

@pyamsoft

I don't think so because we would need root to bind to port 53 as it is privileged.

We can listen to an unprivileged port(e.g. 5353) and require the users to figure out how to use the nonstandard port themselves on the client side(via firewall rules, etc.).

Or, maybe, not broadcasting that there's a DNS server in the network?

writing a DNS server sounds like a large undertaking

Can't we simply forward the requests to the system resolver(assuming there's one) or a public one like 8.8.8.8?

[pyamsoft]

Yes we couls rebind to another port, but this project is not really meant for a network level tweaker to have to manage port settings and configuration. Requiring a user to know what a DNS server is and how its setup is out of scope.

As far as forwarding requests, that is what is already happening when the hotspot receives requests, since DNS resolutions will always happen on the hosting device, not the client.

[brlin-tw]

@pyamsoft

Requiring a user to know what a DNS server is and how its setup is out of scope.

That's understandable. Can we at least not announce there's a DNS service listening at 192.168.49.1 via DHCP?

[pyamsoft]

I am not sure actually.

Android handles the entire DHCP and DNS setup as an internal of "starting WiFi direct". As a non root app, I have no visibility or control over any of it.

The only API I am able to do, as far as I know, is "hey Android start WiFi direct" and Android does everything else behind the scenes.

[brlin-tw]

I think there's nothing we can do then, thanks for the explanation. Closing.