Pihole in a lxc on router/firewall logging tons of request seemingly from the router/firewall or other clients connected to it

I am running OW on a x86/64 mini PC which beyond serving as my router/firewall, also runs pihole in a linux container (lxc). Recently, pihole is logging thousands of DNS requests coming back to 10.0.4.1 which is the gateway on the router/firewall's lxcbr0 interface on which the container is running.

What's even more interesting is that these requests seem to be coming exclusively from Apple devices which are connected wirelessly to a dumb AP, containing addresses such as:

10-courier.push.apple.com
14-courier.push.apple.com
e673.dsce9.akamaiedge.net
gateway.fe2.apple-dns.net
gdmf.apple.com
get-bx.g.aaplimg.com
gsp-ssl.ls-apple.com.akadns.net
gsp-ssl.ls.apple.com
gspe35-ssl.ls-apple.com.akadns.net
init-cdn-lb.ess-apple.com.akadns.net
init-p01md.apple.com
init.ess.apple.com
init.ess.g.aaplimg.com
init.itunes.apple.com
kt-prod.v.aaplimg.com

I have other client devices (Linux boxes) which do not have this problem.

ubus call system board
{
	"kernel": "6.6.91",
	"hostname": "r2max",
	"system": "Intel(R) N150",
	"model": "iKOOLCORE R2Max",
	"board_name": "ikoolcore-r2max",
	"rootfs_type": "ext4",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"firmware_url": "https://downloads.openwrt.org/",
		"revision": "r29664+16-3cd2ff31504d",
		"target": "x86/64",
		"description": "OpenWrt SNAPSHOT r29664+16-3cd2ff31504d",
		"builddate": "1747569132"
	}
}
/etc/config/network
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd99:97d2:a14e::/48'

config interface 'wan'
	option device 'eth1'
	option proto 'dhcp'
	option peerdns '0'
	list dns '1.1.1.1'
	list dns '1.0.0.1'

config interface 'lan'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option delegate '0'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'lan5'
	option ipv6 '0'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:u*'
	list ports 'lan2:u*'
	list ports 'lan3:u*'
	list ports 'lan4:u*'
	list ports 'lan5:u*'

config bridge-vlan
	option device 'br-lan'
	option vlan '3'

config bridge-vlan
	option device 'br-lan'
	option vlan '4'

config device
	option name 'br-lan.10'
	option type '8021q'
	option ifname 'br-lan'
	option vid '10'
	option ipv6 '0'

config device
	option name 'br-lan.3'
	option type '8021q'
	option ifname 'br-lan'
	option vid '3'
	option ipv6 '0'

config device
	option name 'br-lan.4'
	option type '8021q'
	option ifname 'br-lan'
	option vid '4'
	option ipv6 '0'

config device
	option name 'eth0'
	option ipv6 '0'

config device
	option name 'eth1'
	option ipv6 '0'

config device
	option name 'lan1'
	option ipv6 '0'

config device
	option name 'lan2'
	option ipv6 '0'

config device
	option name 'lan3'
	option ipv6 '0'

config device
	option name 'lan4'
	option ipv6 '0'

config device
	option name 'lan5'
	option ipv6 '0'

config device
	option name 'wg0'

config device
	option type 'bridge'
	option name 'lxcbr0'
	option bridge_empty '1'
	option ipv6 '0'

config interface 'guest'
	option proto 'static'
	option device 'br-lan.3'
	option ipaddr '192.168.3.1'
	option netmask '255.255.255.0'

config interface 'iot'
	option proto 'static'
	option device 'br-lan.4'
	option ipaddr '192.168.4.1'
	option netmask '255.255.255.0'

config interface 'lxc'
	option device 'lxcbr0'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '10.0.4.1'

config interface 'wg0'
	option proto 'wireguard'
         .... omitting the rest as it is just wireguard peers
/etc/config/firewall
config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'
	list network 'wg0'

config zone
	option name 'wan'
	option input 'DROP'
	option output 'ACCEPT'
	option forward 'DROP'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'
	option enabled '0'

config forwarding
	option src 'lan'
	option dest 'lxc'

config forwarding
	option src 'lxc'
	option dest 'wan'

config zone
        option name 'lxc'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        list network 'lxc'

config rule 'wg'
        option name 'Allow-WireGuard'
        option proto 'udp'
        option target 'ACCEPT'
        option src 'wan'
        option dest_port '51820'

config zone
        option name 'iot'
        option output 'ACCEPT'
        option forward 'REJECT'
        option input 'REJECT'
        list network 'IOT'
        list network 'iot'

config zone
        option name 'guest'
        option output 'ACCEPT'
        option input 'REJECT'
        option forward 'REJECT'
        list network 'guest'

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'rpi4b-standard'
        option src 'wan'
        option src_dport '30122'
        option dest_ip '192.168.1.101'
        option family 'ipv4'
        list proto 'tcp'
        option dest_port '22'

config forwarding
        option src 'guest'
        option dest 'wan'

config forwarding
        option src 'lan'
        option dest 'guest'

config forwarding
        option src 'lan'
        option dest 'iot'

config rule
        option name 'guest dhcp and dns'
        option src 'guest'
        option target 'ACCEPT'
        option dest_port '53 67 68'

config rule
        option name 'pi-hole-dns guest to lxc'
        list proto 'udp'
        option src 'guest'
        option dest 'lxc'
        option dest_port '53'
        option target 'ACCEPT'

config rule
        option src 'IoT'
        option target 'ACCEPT'
        option name 'iot dhcp'
        option dest_port '67 68'

config rule
        option name 'iot dns'
        list proto 'udp'
        option src 'IoT'
        option dest 'lxc'
        option dest_port '53'
        option target 'ACCEPT'
/mnt/data/lxc/pihole

Distribution configuration

lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = aarch64

Container specific configuration

lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
lxc.rootfs.path = dir:/mnt/lxc/pihole/rootfs
lxc.uts.name = pihole

Network configuration

lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 10.0.4.250/24
lxc.net.0.ipv4.gateway = 10.0.4.1

/etc/config/dhcp
config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	list dhcp_option '6,10.0.4.250'

config dhcp 'guest'
	option interface 'guest'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list dhcp_option '6,10.0.4.250'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config dhcp 'iot'
	option interface 'iot'
	option start '100'
	option limit '150'
	option leasetime '12h'

config dhcp 'wg0'
	option interface 'wg0'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

yes, apple devices use apple ecosystem: push, itunes, private relay etc services. what is the problem?

Tens of thousands of queries coming back to 10.0.4.1. I would like to understand why and prevent it. I am also interested in understanding why it is only Apple devices. How is their DNS protocol different from a Linux box's DNS protocol?

why you think dns is different with apple?? still not sure what is the issue here: an apple device wants access an apple service therefore sends dns query requests, that's normal. try to switch off services on your apple devices you don't use.

but you have not mentioned openwrt version you use and i am not entirely sure your config is valid.
this type of stanza is likely not used anymore, at least i cannot see in my vlan-enabled config.

but i am maybe wrong regarding proper syntax.

so still would like to understand your problem:

  1. your pihole receives dns queries from apple devices but should not? elaborate why should not.
  2. you receive too much dns traffic from apple devices, only from apple devices? define too much, does pi-hole set for dns caching?
  3. you don't know what these fqdns are, why apple devices using them?
  4. something else?

I understand that, but what isn't normal is the fact that it shows up in the query log as 10.0.4.1 rather than the IP of the device itself. I should note that the devices do make DNS requests that get logged as their hostnames, but they also make requests that get logged at 10.0.4.1 which is odd and I would like to understand why.

It's a snapshot I build every so often, currently:

OpenWrt SNAPSHOT, r29664+16-3cd2ff31504d

I believe that my network stanza is correct. I was created by LuCI when I setup the thing.

To your numbered points:

  1. It's my desire to understand why some DNS requests get logged as the device IP whereas others get logged as 10.0.4.1
  2. Yes, only apple devices have this behavior. Right now, I have over 30,000 entries back to 10.0.4.1. The next largest count is only 2,700. Yes, pihole has DNS caching enabled.
  3. I do not know why these addresses are used.

and all hosts are in the same network? sorry if i sound dumb but i have not seen apple devices would do dns queries differently than linux hosts, so just trying to find the differentiator.

It will be quicker if you would post these for two different devices that have different behavior(s).

I edited the first post with the additional info.

Do you have any linux boxes connected to the dumb AP?
Since you have the pihole containerized, maybe you are seeing all these requests from 10.0.4.1 since that's the ip you gave the interface responsible for bridging your containerized pihole.

Yes, several RPi models are connected wirelessly to that AP.

In an attempt to simplify this, I took the container out of the mix. Pi-hole is running on a bare metal x86 box now and I am seeing the same behavior but it is coming back to a single iPhone 16. All other Apple devices behavior normally.

I also tried having the offending iPhone connect to another SSID on my network but that did not change the behavior. I am thinking this is not an OpenWrt issue nor a Pihole issue, but an issue with the iPhone but I do not know what setting on it or perhaps even something malicious is to blame.

Here is an expanded list of the DNS entries that are showing up in the pihole log as originated from the IP of the router/firewall rather than the IP of the iPhone.

1012573445.rsc.cdn77.org
1383071503.rsc.cdn77.org
1422452418.rsc.cdn77.org
1691397408.rsc.cdn77.org
_dns-push-tls._tcp.ipv4only.arpa
_dns.resolver.arpa
a1015.mm2.akamai.net
a1063.b.akamai.net
a1516.b.akamai.net
a161.b.akamai.net
a1744.dscw154.akamai.net
a1818.dscw154.akamai.net
a1899.b.akamai.net
a194.t.akamai.net
a2047.dscw183.akamai.net
a2047.mm3.akamai.net
a2047.w181.akamai.net
a2047.w182.akamai.net
a2047.w183.akamai.net
a2047.w184.akamai.net
a2047.w185.akamai.net
a29.us.akamai.net
a668.t.akamai.net
a748.b.akamai.net
a780.mm3.akamai.net
a834.b.akamai.net
a901.mm3.akamai.net
addons-pa.googleapis.com
amp-api-edge-cdn-lb.itunes-apple.com.akadns.net
amp-api-edge-lb.itunes-apple.com.akadns.net
api.snapkit.com
api16-core-useast8.tiktokv.us
api16-normal-useast5.tiktokv.us
api16-normal-useast8.tiktokv.us
api19-core-useast8.tiktokv.us
api19-normal-useast8.tiktokv.us
app-analytics-services.com
app-analytics-v2.snapchat.com
app.snapchat.com
aws-proxy-gcp.api.sc-gw.com
aws-proxy-gcp.api.snapchat.com
aws.api.snapchat.com
aws.duplex.snapchat.com
bag-cdn-lb.itunes-apple.com.akadns.net
bag.itunes.apple.com
baseurl
bolt-gcdn.sc-cdn.net
buy.itunes-apple.com.akadns.net
bytedance.map.fastly.net
caldav.fe2.apple-dns.net
cdn-v4.amp-endpoint3.com
cdn-v6.amp-endpoint3.com
cf-st.sc-cdn.net
chat-e2ee-ig-p42.c10r.facebook.com
chat-e2ee.c10r.facebook.com
classroom.google.com
cloudidentity.googleapis.com
configuration-lb.ls-apple.com.akadns.net
configuration.apple.com
configuration.ls.v.aaplimg.com
content.fe2.apple-dns.net
cp-rp16-normal-useast8.tiktokv.us
dgw-ig.c10r.facebook.com
dgw.c10r.facebook.com
dig.tiktokv.us
dualstack.h2.bytedance.map.fastly.net
e17437.dsct.akamaiedge.net
e28622.a.akamaiedge.net
e673.dsce9.akamaiedge.net
e6858.dsce9.akamaiedge.net
edge-057.uschi7.ce.apple-dns.net
edge-057.uschi7.icloud-content.com
gateway.fe2.apple-dns.net
gateway.icloud.com
gcp.api.sc-gw.com
gcp.api.snapchat.com
gdmf.apple.com
gdmf.v.aaplimg.com
gecko16-normal-useast8.tiktokv.us
get-bx.g.aaplimg.com
googlehosted.l.googleusercontent.com
graph.facebook.com
gs-loc-new.ls-apple.com.akadns.net
gs-loc.ls-apple.com.akadns.net
gsa.apple.com
gsa.idms-apple.com.akadns.net
gsas.apple.com
gsp-ssl.ls-apple.com.akadns.net
gspe79-cdn.g.aaplimg.com
guzzoni-apple-com.v.aaplimg.com
hotapi16-normal-useast8.tiktokv.us
inappcheck-lb.itunes-apple.com.akadns.net
inbox.google.com
instagram.c10r.instagram.com
jsb16-normal-useast8.tiktokv.us
lb._dns-sd._udp.0.8.9.10.in-addr.arpa
lf-main-gecko-source.tiktokcdn.com
lf-main-gecko-source.tiktokcdn.com.ttdns2.com
lf16-gecko-source.tiktokcdn.com
lf19-gecko-source.tiktokcdn-us.com
lh3.googleusercontent.com
libra16-normal-useast8.tiktokv.us
log16-normal-useast8.tiktokv.us
mask-h2.icloud.com
mask.apple-dns.net
mask.icloud.com
media1.giphy.com
meetings.googleapis.com
mesu-cdn.origin-apple.com.akadns.net
mesu.g.aaplimg.com
mon16-normal-useast5.tiktokv.us
mon16-normal-useast8.tiktokv.us
mqtt.c10r.facebook.com
mssdk16-normal-useast8.tiktokv.us
netcts.cdn-apple.com
ngx-v4.amp-endpoint2.com
ngx-v6.amp-endpoint2.com
notifications-pa.googleapis.com
oauth2.googleapis.com
oauthaccountmanager.googleapis.com
ocsp2-lb.apple.com.akadns.net
ocsp2.apple.com
ocsp2.g.aaplimg.com
oec16-normal-useast5.tiktokv.us
oec16-normal-useast8.tiktokv.us
oec19-normal-useast5.tiktokv.us
ohttp-relay1.fastly-edge.com
p16-common-sg.tiktokcdn-us.com
p16-common-sign-no.tiktokcdn-us.com
p16-common-sign-sg.tiktokcdn-us.com
p16-common-sign-useast2a.tiktokcdn-us.com
p16-common-sign-va.tiktokcdn-us.com
p16-common-va.tiktokcdn-us.com
p16-pu-sign-useast8.tiktokcdn-us.com
p16-pu-useast8.tiktokcdn-us.com
p16-ug-incentive-va.ibyteimg.com
p16-ug-incentive-va.tiktokcdn.com
p179-content.icloud.com
p19-common-va.tiktokcdn-us.com
p19-oec-ttp.tiktokcdn-us.com
p19-pu-sign-useast8.tiktokcdn-us.com
p19-pu-useast8.tiktokcdn-us.com
p19-sign.tiktokcdn-us.com
people-pa.googleapis.com
pitaya-ttp2.tiktokv.us
pull-f5-tt01.tiktokcdn-us.com
pull-f5-tt01.tiktokcdn-us.com.c.worldfcdn2.com
pull-f5-tt02.tiktokcdn-us.com
pull-f5-tt02.tiktokcdn-us.com.c.worldfcdn2.com
pull-f5-tt04.tiktokcdn-us.com
pull-f5-tt04.tiktokcdn-us.com.c.worldfcdn2.com
pull-f5-va01.tiktokcdn-us.com
pull-f5-va01.tiktokcdn-us.com.c.worldfcdn2.com
pull-flv-f77-tt01.tiktokcdn-us.com
pull-flv-f77-tt02.tiktokcdn-us.com
pull-flv-f77-tt04.tiktokcdn-us.com
pull-flv-f77-va01.tiktokcdn-us.com
pull-q5-va01.tiktokcdn-us.com
pull-q5-va01.tiktokcdn-us.com.c.worldfcdn2.com
pull-w5-va01.tiktokcdn-us.com
pull-w5-va01.tiktokcdn-us.com.c.worldfcdn2.com
roovza-launches.appsflyersdk.com
roovza-skadsdk.appsflyersdk.com
rtlog16-normal-useast8.tiktokv.us
safebrowsing.g.aaplimg.com
scontent-dfw5-1.cdninstagram.com
scontent-dfw5-3.cdninstagram.com
service-reviews-ultimate.elfsight.com
sf16-ies-music-sg.tiktokcdn.com
sf16-sg.tiktokcdn.com
smoot-searchv2-ause2c.v.aaplimg.com
star-mini.c10r.facebook.com
star-mini.fallback.c10r.facebook.com
star.c10r.facebook.com
star.fallback.c10r.facebook.com
starling.tiktokv.us
static.doubleclick.net
taskassist-pa.googleapis.com
time.apple.com
time.g.aaplimg.com
tnc16-normal-useast5.tiktokv.us
token.safebrowsing.apple
ttp-api16-tiktok-com-apix.bytewlb.akadns.net
updates.cdn-apple.com
updates.g.aaplimg.com
us-central1-gcp.api.sc-gw.com
us-central1-gcp.api.snapchat.com
us-east1-aws.api.sc-gw.com
us-east1-aws.api.snapchat.com
us-east4-gcp.api.snapchat.com
us.bytedance.map.fastly.net
usc1-gcp-v61.api.snapchat.com
v16m.tiktokcdn-us.com
v19.tiktokcdn-us.com
v45-ttp.gpm.ttoverseaus.net
v45.tiktokcdn-us.com
valid.apple.com
vcs16-normal-useast8.tiktokv.us
video-dfw5-2.xx.fbcdn.net
video.us.bytedance.map.fastly.net
webcast-ws16-normal-useast8.tiktokv.us
webcast16-normal-useast8.tiktokv.us
webcast19-normal-useast8.tiktokv.us
xp.apple.com
xp.itunes-apple.com.akadns.net
10-courier.push.apple.com
14-courier.push.apple.com
e673.dsce9.akamaiedge.net
gateway.fe2.apple-dns.net
gdmf.apple.com
get-bx.g.aaplimg.com
gsp-ssl.ls-apple.com.akadns.net
gsp-ssl.ls.apple.com
gspe35-ssl.ls-apple.com.akadns.net
init-cdn-lb.ess-apple.com.akadns.net
init-p01md.apple.com
init.ess.apple.com
init.ess.g.aaplimg.com
init.itunes.apple.com
kt-prod.v.aaplimg.com

EDIT: I don't think pi-hole is to blame... something is odd with that iPhone. I can stop the behavior by applying the following traffic rule, but that is really a band-aid fix.

config rule
	option src 'lan'
	option name 'block iphone'
	list src_ip '10.9.8.243'
	option target 'DROP'

I would still like to know what on the iPhone is circumventing the DNS entry and defaulting to the router as the DNS server.