~craftyguy/dnsane

DNS proxy that filters replies based on primary connection IP protocol support
netman: trigger reloading nameservers on NM_DEVICE_STATE_DISCONNECTED
netman: debug print state from NM and when nameservers are sent
netman: use map to store NM states

clone

read-only
https://git.sr.ht/~craftyguy/dnsane
read/write
git@git.sr.ht:~craftyguy/dnsane

You can also use your local clone with git send-email.

#About

dnsane is a DNS proxy that filters responses from upstream DNS servers to provide clients with DNS responses that match IP protocol version(s) supported by NetworkManager's "Primary Connection."

In other words, if your primary connection in NetworkManager is a WiFi network that only supports IPv4, dnsane makes sure that no DNS responses will contain records for AAAA / IPv6. This sounds nuts, right? See the "Why?" section.

dnsane relies entirely on NetworkManager to provide it with DNS nameservers, and connection priority information. dnsane will use the DNS nameservers configured for the primary NetworkManager connection. Connection status changes in NetworkManager will cause dnsane to reload/refresh DNS nameserver info from NetworkManager, just in case the list of nameservers was modified by whatever caused the status change.

dnsane does not attempt to prioritize connections by type/interface or nameservers, these prioritizations can be set in NetworkManager.

#Why?

This was made primarily to address a common problem for networked devices that are multi-homed, where DNS responses might "convince" certain apps to connect over a lower priority / non-preferred connection when they should be using something else.

A classic example of this is a phone connected to a mobile data network that supports both IPv4 and IPv6, and a (preferred) WiFi network that is IPv4-only. Some apps will query both A and AAAA records for a given domain, and then may choose (for whatever dumb reason) to use AAAA. Unfortunately this means the connection would go over the only connection with routable IPv6... the mobile data connection. Even if the app received a valid A record and could have used the preferred WiFi connection.

#What's with the name?

"dnsane" is a portmanteau of "DNS" and "insane", the "DNS" part comes from this being a DNS proxy filter thing, and "insane" is from how I feel after trying to find some way to resolve this multi-homed problem before settling on this silly app.

If you have a better name, send me a patch.

#Building / Installing

$ make

To install locally:

$ make install

There's an openrc runscript under the openrc directory that can be used to start dnsane.

Runtime Requirements:

- NetworkManager
- dbus (system session, for communication with NM)

#Usage

dnsane binds to port :53 on localhost. The preferred way to run it is to configure NetworkManager to disable managing /etc/resolv.conf:

# /etc/NetworkManager/conf.d/99-no-resolv.conf
[main]
dns=none

And modify resolv.conf to use dnsane:

# /etc/resolv.conf
nameserver 127.0.0.1

Now any DNS lookups (e.g. from libc) that use resolv.conf will have responses filtered by dnsane.

#Contributing

Send patches and questions to the dnsane mailing list: https://lists.sr.ht/~craftyguy/dnsane

All patches should complete make test successfully.

New filters should come with benchmarks, and changes to existing filters should include some before/after benchmark data in the commits.