DNS not resolving on bridged router

[my_pi]

Recently added a new router to our home network in bridge mode to extend our wifi range upstairs. I previously installed pi-hole on a new Rpi 3A (running raspbian lite) a few days prior, everything has been working perfectly. However any devices connected to the bridged router , wifi or ethernet, don't have an internet connection and can't resolve DNS. When I check their DNS server it is correctly pointed to the Pi's local IP at 192.168.1.149. When I add a secondary DNS pointing to the main router's IP at 192.168.1.1, internet access is restored but pi-hole shows all traffic as going through the main router instead of showing each device individually. Pi-hole is set up to Listen on all interfaces, permit all origins.

Occasionally some devices will connect to the secondary router but get a 169.254.x.x IP. This usually goes away after restarting both routers, but comes back some time later.

Any device connected to the secondary router is able to access the main routers GUI at 192.168.1.1, the secondary router's GUI at 192.168.1.2 and pi-holes web interface at 192.168.1.149.

The main router is a Linksys wrt1900 ac and the secondary is a Telstra Smart Modem Gen 2 (Arcadyan) in bridge mode, with it's IP set to 192.168.1.2 running on the same subnet .I've only got IPv4 turned on for both devices. DHCP is only running on the pi through pi-hole, assiging IPs from 192.168.1.50 to 192.168.1.250.

I'm not sure what extra settings I need to adjust to make everything work correctly for devices connected to the secondary router.

Debug Token:

https://tricorder.pi-hole.net/wudcb1b2a0

[Bucking_Horn]

Your debug log shows that you had public IPv6 connectivity when you first setup Pi-hole, but not any more:

*** [ DIAGNOSING ]: Setup variables
    IPV6_ADDRESS=2001::(redacted)

*** [ DIAGNOSING ]: Networking
[✓] IPv6 address(es) bound to the wlan0 interface:
   fe80::(redacted) does not match the IP found in /etc/pihole/setupVars.conf

Unless you've enabled IPv6 support for Pi-hole's DHCP server, this would not contribute to your issue.
Still, it may be a good idea to run pihole -r and choose Reconfigure to make Pi-hole aware of your network changes for IPv6.

Your debug log also shows you've enabled DNSSEC.
Cryptographic evaluation of the digital signature relies on a common time frame on the server and your RPi, and as RPis are lacking a hardware clock (or RTC), DNSSEC could be expected to fail sporadically for a few lookups, until a successful NTP restores an accurate time again.

But you may also have a more basic networking problem.

@my_pi

Occasionally some devices will connect to the secondary router but get a 169.254.x.x IP. This usually goes away after restarting both routers

Assignment of a link-local IPv4 address (from 169.254.0.0/16) usually means that your client device has failed to solicit an IP address from the DHCP server in your network.

Note that DHCP negotiation is initiated from your client by a network broadcast, and that is only visible on the same network segment (e.g. all devices connected to the same router in layman terms).

Since you are running two routers, those may constitute two network segments. Your router would then have to act as DHCP relay agent to Pi-hole. In order to do so, your relaying router needs to be aware of Pi-hole's IP address.

This wouldn't sufficiently explain why you experience issues only from time to time, but it may be worth checking your device for a DHCP relay option. Of course, it would depend on your router if and how you can control this behaviour.

And since your are connecting your RPi via its wlan interface, your observation may also be caused by temporary drops of your WiFi connection.

[my_pi]

Thanks so much for your help.
I've reinstalled pi-hole, disabled DNSSEC and tried again but I'm still having the same issues. Devices connecting to the second router are now getting correct IP addresses and I can see the DHCP requests coming up in the pihole log.
There's still no internet for any devices connected to the second router though and debugging on windows just says that the DNS server is not responding. My iPhone is showing that is has a valid IP address and the DNS server is set to the Rpi's but it seems to have the same issue.
Could there be something blocking communication between the second router and the rpi DNS server?

[Bucking_Horn]

Yes, there are a multitude of ways how DNS could be blocked or intercepted and redirected or otherwise compromised by network devices.

From a client that is connected to your second router, what is the output of the following commands:

nslookup pi.hole

nslookup flurry.com 192.168.1.149

(assuming your Pi-hole still resides at .149)

[my_pi]

I'm getting UnKnown for both commands

nslookup pi.hole
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.1.149

DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

nslookup flurry.com 192.168.1.149
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.1.149

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

[Bucking_Horn]

Your output of nslookup pi.hole shows that your client does indeed use Pi-hole's IP address for DNS queries by default, so that's good.

But it times out, just as the result of the lookup of flurry.com forced through Pi-hole's IP.

We can rule out that you've configured a DNS loop with Pi-hole (often resulting in time-outs) since your debug log shows you are not using your router as Pi-hole's upstream DNS, nor did you enable Conditional Forwarding.

This means something is blocking DNS requests on their way from your client to Pi-hole.

As you had Pi-hole working on your RPi before you installed your second router, it is highly unlikely that a firewall on the RPi itself is blocking the DNS port (though you may want to check your RPi's firewall, just to be sure).

It is indeed more likely that one of your routers is blocking it.
It would depend on your router how to tackle this.

You may improve your chances on a knowledgable answer when you also consider to consult your routers' support forums.

[my_pi]

Firewall settings seemed to be fine, I have no idea what the issue was but it seems very likely to have been related to the second router - the Telstra Smart Modem Gen 2 (TSM). Frustratingly, there's also apparently no official manual for this router either.

I swapped the two routers around, making the TSM the primary router and the Linksys set to bridge mode as the second. Everything is working fine now.

Things I tried that didn't work were resetting both routers to factory settings, disabling firewalls, reinstalling pi-hole and connecting the pi directly to the secondary modem instead of the first.