Dnsmasq-full fails to heed 'server' directives

I recently re-flashed a GL-AR750 with Gl.iNet firmware 4.3.7 based on OpenWRT 22, and now the dnsmasq-full DNS server does not heed the ‘server’ directive. Matching domains are forwarded to the upstream DNS server as if they did not match.

I had been using v3 firmware based on OpenWrt 19 with identical /etc/config/dhcp configuration (except for one new line ‘edns-packet-max=1232’ in the v4 configuration).

I do not have a stock OpenWrt 22 device to test, so I am posting with Gl.iNet first.

The shell session excerpts below show relevant system and configuration info, then show the failed query and a query directly to the correct nameserver.

root@Glark:/# cat /proc/cpuinfo; echo GLVERSION:; cat /etc/glversion; echo PROC-VERSION:; cat /proc/version

system type             : Qualcomm Atheros QCA9533 ver 2 rev 0
machine                 : GL.iNet GL-AR750
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 432.53
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16
Options implemented     : tlb 4kex 4k_cache prefetch mcheck ejtag llsc dc_aliases perf_cntr_intr_bit perf
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

Linux version 5.10.176 (glinet@glinet) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r20123-38ccc47687) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 Sun Apr 9 12:27:46 2023

root@Glark:/# opkg status dnsmasq-full

Package: dnsmasq-full
Version: 2.86-17
Depends: libc, libubus20220601, libnettle8, kmod-ipt-ipset, libnetfilter-conntrack3
Provides: dnsmasq
Status: install user installed
Architecture: mips_24kc
 /etc/config/dhcp ddd520eb24451a892c9c666d83c10c9ea4fc944efbc34a149bc962c56bd8812f
/etc/dnsmasq.conf 1e6ab19c1ae5e70d609ac7b6246541d52042e4dee1892f825266507ef52d7dfd
Installed-Time: 1681043266

root@Glark:/# grep 'manage\|queries' /var/etc/dnsmasq.conf.cfg01411c


root@Glark:/# nslookup bluebird.manage.RP

** server can't find bluebird.manage.RP: NXDOMAIN

** server can't find bluebird.manage.RP: NXDOMAIN

root@Glark:/# nslookup bluebird.manage.RP


Name:   bluebird.manage.RP

If the ‘server’ directive was being heeded, the query for ‘bluebird.manage.RP’ would have gone to and gotten the correct result (“because bluebird” is simply the hostname of the nameserver itself).

Instead, the query goes upstream to Comcast nameserver, which of course returns NXDOMAIN. Yes, I’ve restarted dnsmasq and rebooted the router. Everything else in logs and performance of dnsmasq is as expected.

Sat Dec 30 17:06:10 2023 daemon.info dnsmasq[1]: 577 query[A] bluebird.manage.RP from
Sat Dec 30 17:06:10 2023 daemon.info dnsmasq[1]: 577 forwarded bluebird.manage.rp to

[edit: new firmware is based on OpenWrt 22, not 21]

The answer appears to be that dnsmasq has become case sensitive, since the version in the v3 firmware which worked with the same config file. Changing to lowercase “.rp” in the config changes dnsmasq behavior to correct (expected) behavior.

I believe this is a bug, because DNS ought to be case insensitive in its essential operation but preserve input case for user output, if I understand this RFC correctly: RFC 4343 - Domain Name System (DNS) Case Insensitivity Clarification

I will try to reproduce on non-Gl.iNet dnsmasq and report upstream if appropriate.


FYI/FWIW: OWRT can be run in Vbox. HOW-TO is for an older version but it should still work w/ 23.05 for latest upstream dnsmasq v dnsmasq-full: