Dnsmasq Config

Bruce Ediger

When I last had problems with PPP, I noticed that some non-routeable IP addresses ended up getting sent out for DNS reverse lookup.

This is different than routing packets with those same (nominally) non-routeable addresses out into The Internet.

When I had some problems with my PPP-over-Ethernet user name and password, I noticed some DNS queries that didn’t make any sense.

Oct 20 19:49:40 monarch dnsmasq[927]: query[A] monarch.glamour from 10.0.20.35
Oct 20 19:49:40 monarch dnsmasq[927]: forwarded monarch.glamour to 9.9.9.9
Oct 20 19:49:40 monarch dnsmasq[927]: forwarded monarch.glamour to 8.8.8.8

10.0.0.0/8 isn’t supposed to get out to the wider internet at all. Dnsmasq had some misconfiguration that was causing it to send queries to the Quad-9s DNS server, and to Google’s public DNS server.

I’ll grant that this happened during a time when everything but pppd acted like a network connection to The Internet existed, but it still shouldn’t have happened.

Even when pppd had created a connection, the occasional 10.0.0.0/16 address got sent out, according to sudo journalctl -f -u dnsmasq.

The occasional A or AAAA query got sent out as well:

Nov 27 18:11:58 monarch dnsmasq[3904]: query[AAAA] modest4.glamour from 10.0.20.35
Nov 27 18:11:58 monarch dnsmasq[3904]: forwarded modest4.glamour to 8.8.8.8
Nov 27 18:11:58 monarch dnsmasq[3904]: reply modest4.glamour is NODATA-IPv6

I don’t have IPv6 dual stacks running in my network right now, so this has no effect other than taking a little longer per DNS name resolution, but I don’t want to be a bad network citizen. I’d like this kind of look up to not happen.

It wasn’t too difficult to fix. I found that I’d previously put a few lines in /etc/dnsmasq.conf to cover part of the situation. All I had to do was add several similar lines .

# Example of routing PTR queries to nameservers: this will send all
# address->name queries for 192.168.3/24 to nameserver 10.1.2.3
#server=/3.168.192.in-addr.arpa/10.1.2.3
server=/0.10.in-addr.arpa/10.0.0.1

# Add local-only domains here, queries in these domains are answered
# from /etc/hosts or DHCP only.
#local=/localnet/
local=/glump/
local=/salmon/
local=/walrustitty/
local=/spork/
local=/glamour/

The server= line changed from server=/0.0.10.in-addr.arpa/10.0.0.1, to what you see above. That changes dnsmasq from taking care of 10.0.0.0/24 by itself, to taking care of 10.0.0.0/16 by itself. I had added subnets 10.0.10.0/16, 10.0.20.0/16, 10.0.30.0/16, 10.0.40.0/16 to my house since I seriously looked at dnsmasq configuration last.

The local= lines are the Highly Official Top Level Domains I gave to my “/16” subnets. Consumer grade WiFi routers often give out “.intranet” as a domain. I’d go so far as to say this is a de facto standard, more standard than anything else the knuckleheads who do WiFi router firmware hardcode, which is weird. I want to see things fail, rather than lazily take the defaults and hope everything Just Works, so I have odd top level domains instead of .intranet.

Between giving dnsmasq a /16 instead of a /24, and adding my clever top level domains as something it should also take care of, the problem of asking 9.9.9.9 what domain name goes with 10.0.20.35 disappears.

Well, you also have to remember that dig does not do reverse look ups without the “-x” flag. dig 10.0.20.35 sends out “10.0.20.35.” as a putative fully-qualified domain name. dig -x 10.0.20.35 does a reverse query for “35.20.0.10.in-addr.arpa.”