Resolving query[type=65] to local address for iOS clients in dnsmasq

Installing and Using OpenWrt Network and Wireless Configuration
21

Thank you for this suggestion. I missed this note in the documentation.

Placing my domain in the Local Server section does prevent the DNS query[type=65] from resolving upstream. However, it responds with NODATA rather than an actual IP address. Unfortunately, I think this brings me to my initial problem where a NODATA response may return to the iOS device "first". Right now everything has been resolving properly so it is hard to test if this condition will ever be reached. Please correct me if I am wrong about this.

For reference, here are the dnsmasq logs I see now that I have added a Local Server entry.

Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1253 192.168.1.241/61654 query[A] sub.mydomain.com from 192.168.1.241
Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1253 192.168.1.241/61654 config sub.mydomain.com is 192.168.69.69
Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1254 192.168.1.241/59707 query[AAAA] sub.mydomain.com from 192.168.1.241
Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1254 192.168.1.241/59707 config sub.mydomain.com is fd17:b6b2:88cd::42b
Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1255 192.168.1.241/56265 query[type=65] sub.mydomain.com from 192.168.1.241
Fri Jan 26 03:20:51 2024 daemon.info dnsmasq[1]: 1255 192.168.1.241/56265 config sub.mydomain.com is NODATA
2 Likes
22

Thank you for the reply.

Yes, I know exactly what you mean. I had the same issue with Apple devices until I found this solution.

I'm not sure why Dnsmasq 2.86+ decided not to respect the address forward for all types of queries and not just for A and AAAA. Perhaps this wouldn't be an issue if Apple devices sent standard DNS queries and not type 65 randomly.

Anyway, this local server workaround seems to solve it and there doesn't seem to be any issues with failed queries. They revert to the A reply immediately.

1 Like
23

Some good news and update regarding the TYPE=65 [HTTPS] DNS queries.

According to the latest changelog of Dnsmasq, in version 2.90 there is a new option added called
--filter-rr

If it's implemented in a future release of OpenWrt, we might be able to add this line:
filter-rr=ANY
in /etc/dnsmasq.conf (or preferably an option in luci if available) and it will filter out any DNS types from the replies except for A, AAAA, MX and CNAME.

This should finally solve the issue if it works properly.

Sources:
"https://thekelleys.org.uk/dnsmasq/CHANGELOG"
"https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html"

2 Likes
24

Who should I contact and who could create a new 2.90 ipk package for openwrt? To replace the current

1 Like
25

Thank you for your question.

There seems to be a pull request already, but it needs to be approved by 6 reviewers. You can check it here: Adding Dnsmasq 2.90 - #2 by egc

I would be happy to see this approved for the next release, or even as an update package that would be available in Luci > System > Software (opkg) if possible.

2 Likes
26

I'm happy to say that the Dnsmasq 2.90 update was approved and it's now available on OpenWrt 23.05.2 through Luci > System > Software > Updates as well!

Big thanks goes to the OpenWrt developers that made it possible, including @systemcrash @egc @Joe_D and the team on https://github.com/openwrt/openwrt/pull/14853 also

To apply the new --filter-rr=ANY option in Dnsmasq 2.90, I've used these steps:

  1. Login via SSH to OpenWrt
  2. Type cd /etc/
  3. Edit the dnsmasq configuration file wtih vi dnsmasq.conf
  4. Press on i to edit
  5. Go to the bottom of the file with the arrow keys and type filter-rr=ANY
  6. (Optional) you can add filter-rr=HTTPS instead to filter TYPE65 queries
  7. Add cache-rr=ANY on a new line to cache all types of DNS replies
  8. Press ESC to quit the edit mode
  9. Press on : and then on w to write to the file and press return
  10. Press on : and then on q to quit vi and press return
  11. Restart Dnsmasq with /etc/init.d/dnsmasq restart

If everything works properly, this should filter out any DNS replies that are not A, AAAA, MX and CNAME.

It would be nice if there is an easier option to enable this via Luci as well in future updates.

Please try it out and see if it works properly for the HTTPS [type=65] replies and in general.

1 Like
27

Hello @GetVladimir - yes, 2.90 landed, and if I do say so, relatively quickly. Most of the devs know what dnsmasq is and generally understand it.

The PR I added for DNS-RR is still hanging out on github.

For those of you with a GH account, you can head over and approve it ( files changed -> review changes -> approve ), to show your support for the feature.

How long that will take - who knows. But once the feature is in, it will arrive relatively quickly in master, and maybe 23.

In the meantime, to make your instructions easier:

-7, --conf-dir=<directory>[,<file-extension>......],
    Read all the files in the given directory as configuration files. If extension(s) are given, any files which end in those extensions are skipped. Any files whose names end in ~ or start with . or start and end with # are always skipped. If the extension starts with * then only files which have that extension are loaded. So --conf-dir=/path/to/dir,*.conf loads all files with the suffix .conf in /path/to/dir. This flag may be given on the command line or in a configuration file. If giving it on the command line, be sure to escape * characters. Files are loaded in alphabetical order of filename.

This option in openwrt is confdir. Which defaults to "/tmp/dnsmasq.d" - so what you can do is make a new file e.g. dnsrr.conf with the options you wrote above, and put that either in "/tmp/dnsmasq.d" (lost at reboot) or elsewhere on your file-system, so no matter what you do, that is always included in your config.

You might want to check what happens to your config file when you restart dnsmasq with /etc/init.d/dnsmasq restart.

1 Like
28

In the meantime - I think filter-rr also looks like a good option to add. So I would like to make a PR for that, also.

1 Like
29

Thank you for the reply and the details!

Yes, OpenWrt seems to create a configuration file for Dnsmasq that could be viewed here:
cat /var/etc/dnsmasq.conf*

From that one, it points to 3 outside configuration files and 1 configuration directory:

conf-file=/etc/dnsmasq.conf
conf-file=/usr/share/dnsmasq/rfc6761.conf
conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf
conf-dir=/tmp/dnsmasq.d

I've used the one in /etc/dnsmasq.conf in the guide above because it's already there and seems to survive a reboot, but your suggestion to create a new directory specific for this, perhaps in /etc/config/dnsmasq-custom-config/ would be an even better solution.

Regarding the dns-rr, I thought that feature was already added in OpenWrt with the previous versions of Dnsmasq. Now it makes sense why it didn't work for the people that used it in the first comments of this post. I've reviewed the 2 files in the PR that you've linked and I've approved them.

1 Like
30

If filter-rr=HTTPS fixes the iOS client issue, isn't that a much safer 'default' fix to recommend than filter-rr=ANY? Blocking everything other than A, AAAA, MX and CNAME records might have a lot of unforeseen consequences.

E.g. may break email security features SPF/DMARC/DKIM (relies on TXT records), certificate renewal (relies on CAA records), SIP/VoIP (relies on SRV records), autodiscover (relies on TXT records), etc.

31

Yes, for the HTTPS (TYPE65) DNS queries specifically, that would be the better default fix.

For the other amplification DNS vulnerability issues, it might need the ANY to be effective against.

Regarding the email clients, that's a good point. Does the email service provider usually check for the SPF/DMARC/DKIM or the end-user's client app? If it's the service provider, then it might not be an issue

32

If you use webbased email (Gmail, Outlook, etc) or simple POP3 with a local client (Outlook, Thunderbird) it's not an issue. But that's kinda the point... You don't know what you'll break because many of this DNS stuff happens below the surface.

1 Like
33

@GetVladimir it's ready for testing. Grab the init file and replace your /etc/init.d/dnsmasq. See commit example config for your filters. Leave instance empty to apply to the default dnsmasq.

1 Like
34

If dnsmasq doing this filtering is the configured resolver for the server, yes.

Server-side.

35

This is great, thank you so much for creating this!

Just to be clear that I'm making everything correctly:

  1. Login to OpenWrt via SSH and replace the existing /etc/init.d/dnsmasq file with the dnsmasq.init raw file from the commit (I've compared the file with the existing one and see the changes, so it does seem like it would work as a replacement)
  2. After replacing the init file, I should use this configuration for example:
uci set dhcp.@dnsmasq[0].rr_csv='AAAA,HTTPS,65'
uci commit dhcp
/etc/init.d/dnsmasq restart

Is that correct?

36

That adds option rr_csv 'AAAA,HTTPS,65' to your main config dnsmasq.

This does what you need:

uci -q add dhcp 'filter_rr'
uci -q set dhcp.@filter_rr[-1].rr_csv='AAAA,HTTPS,65'
uci -q commit dhcp
1 Like
37

Thank you so much for the reply and for the clarification.

I will test it out with that configuration.

Just for conformity, should we change the filter-rr option to be added under dnsmasq instead of dhcp directly?

Mostly because dnsmasq already has these similar features under it:

dhcp.@dnsmasq[0].filter_aaaa='1'
dhcp.@dnsmasq[0].address='/example.com/0.0.0.0'
dhcp.@dnsmasq[0].server='/www.example.com/1.1.1.1'

perhaps also including the cache-rr feature, to have the whole feature-set complete and matching dnsmasq 2.90

38

I wonder if its possible to add an HTTPS-RR with dns-rr for a non ssl local site?

dig -t TYPE65 blog.cloudflare.com

gives me

blog.cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.28.7,104.18.29.7 ipv6hint=2606:4700::6812:1c07,2606:4700::6812:1d07

h2 is HTTP/2 over TLS, h3 is HTTP/3

According to https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids i could use http/1.1 for non ssl and prepare an entry like:

myhost.lan. 300 IN HTTPS 1 . alpn="http/1.1" ipv4hint=10.100.100.100

1 Like
39

That would be an extra few commits. Possible. But PR 'subjects' tend to be one thing only. But the absolutely glacial pace that things get merged at, it's a good idea to try.

I re-used the machinery for various other types of records for filter-rr, and didn't put the filters into the main dnsmasq[0] entry. The way I did it means it can apply globally, to all dnsmasq instances, but in a GUI it would probably fit better under each dnsmasq entry anyway (in which case this code and PR will change)...

1 Like
40

I distinctly remember asking the RFC authors early in the spec creation about having HTTP in there. No was the answer (but not because they did not want to).

Edit: it's unclear whether you meant HTTP or HTTPS without TLS (in which case, yes, it should work?)