Tell dnsmasq not to pass requests upstream

[Travis-Snoozy]

The behavior of dnsmasq changed in version 2.86 -- before then, if a record was set for a domain name with dnsmasq, and a record for a type not specified for that domain was requested, dnsmasq would indicate no data existed for that record type. After 2.86, record types that are not specified are instead passed upstream. The latter behavior causes problems for the Steam client, which will disregard a correctly set A-record for lancache.steamcontent.com, if no AAAA is set with dnsmasq and dnsmasq passes the AAAA query upstream. The documentation for dnsmasq indicates the correct way to restore the old behavior is to use the local=/host/ syntax -- emit this syntax for each of our lancache-hosted DNS entries.

What CDN does this PR relate to

Steam

Does this require running via sniproxy

N/A (create-dnsmasq.sh update)

Capture method

N/A (create-dnsmasq.sh update)

Testing Scenario

Home network, Linux, Windows, Steamdeck clients; OpenWRT (dnsmasq-based) router serving DNS. Deleted prior dnsmasq config, ran create-dnsmasq.sh, copied the generated output/dnsmasq/steam.conf file to the router's configuration directory for dnsmasq (/tmp/dnsmasq.d/), restarted dnsmasq on the router, and verified no AAAA record is served. Restarted Steam on each of the platforms, monitored the lancache access log, verified all three types of client access the cache correctly.

Testing Configuration

local=/lancache.steamcontent.com/
address=/lancache.steamcontent.com/192.168.42.10

Sniproxy output

N/A

[Travis-Snoozy]

Note that an alternate approach -- setting the AAAA record to a nominal "NULL address" (the words of the dsmasq man page) via address=/lancache.steamcontent.com/:: -- was tested. While it does work for the Windows Steam client, it does not work for the Linux steam client.

[nightah]

LGTM, since I've stopped using dnsmasq I didn't pick this up personally but I did experience the issue just before I swapped.

For reference here's the explanation from the man page:

Note that the behaviour for queries which don't match the specified address literal changed in version 2.86. Previous versions, configured with (eg) --address=/example.com/1.2.3.4 and then queried for a RR type other than A would return a NoData answer. From 2.86, the query is sent upstream. To restore the pre-2.86 behaviour, use the configuration --address=/example.com/1.2.3.4 --local=/example.com/

[nightah]

LGTM.