How to temporarily disable Internet connectivity

[Wpq]

I have a perfectly working Pi-hole installation on my router (a Debian box connected to the ISP fibre and to the switch that powers the rest of my network). BTW thank you for this wonderful service.

My ISP's fibre failed and I will be stuck without Internet for a few days. My router is not useful anymore except for its DNS and DHCP functionality (DNS for the LAN).

Pi-hole is however getting crazy without access to Internet by constantly querying what seems to be NTP servers (this scrolls continuously):

Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] 0.north-america.pool.ntp.org from 192.168.10.210
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] pool.ntp.org from 192.168.10.208
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] pool.ntp.org from 192.168.10.105
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] 0.amazon.pool.ntp.org from 192.168.10.151
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] 0.north-america.pool.ntp.org from 192.168.10.43
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)
Dec  3 17:19:49 dnsmasq[846]: query[A] 1.north-america.pool.ntp.org from 192.168.10.210
Dec  3 17:19:49 dnsmasq[846]: config error is REFUSED (EDE: network error)

The file is growing fast, about 3 GB /day. This is not a problem disk-wise, but it seems to seriously disrupt its functionality: among others it does not respond to DHCP requests anymore and shows memory problems (error repeated constantly):

[2022-12-03 17:22:01.771 846M] Resizing "FTL-queries" from 1974239232 to (35258368 * 56) == 1974468608 (/dev/shm: 2.0GB used, 2.0GB total, FTL uses 2.0GB)
[2022-12-03 17:22:01.771 846M] WARNING: RAM shortage (/dev/shm) ahead: 99% is used (/dev/shm: 2.0GB used, 2.0GB total, FTL uses 2.0GB).

What is the correct way to deal with such a situation? (lack of Internet access) - since this is temporary, I would like to just retain DHCP and DNS functionality and disable all the rest (or whatever is needed to stop Internet requests)

Debug Token:

I do not know how to manually upload the debug file to tricorder

UPDATES

I managed to mitigate the issue somehow by:

• deleting /etc/pihole/pihole-FTL.db → the Athens of millions of failed queries were not processable (at least this is my impression)
• I manually commented out my server= lines in /etc/dnsmasq.d/99-local-mine.conf
• disabling chrony to limit the number of NTP queries

This made Pi-hole reactive again but I am still getting many failed DNS requests in the logs. If I could quickly respond to any DNS query outside of my local domain and return an NXDOMAIN (or something similar) and not log that it would help.

Anyway, I now know what to manually purge during these two days

[Bucking_Horn]

Pi-hole is already providing answers as fast as it can.
It has detected that all of its upstream DNS servers are inaccessible/inoperative. In consequence, Pi-hole immediately answer REFUSED to any DNS requests.

However, Pi-hole cannot control your client's behaviour. Having received a REFUSED reply won't influence their eagerness to know the IP for a given domain.

You may try to lower their rate of repeat for their requests by adjusting your local-ttl.

Run from your Pi-hole host machine, check the output of:

grep -nR local-ttl /etc/dnsmasq.d*

If that comes back empty, that would imply a local TTL of zero.

You could then create a custom file like /etc/dnsmasq.d/42-local-ttl.conf and add

local-ttl=30

Afterwards, run pihole restartdns.

This will inform clients that a DNS reply is valid for 30 seconds, and may coerce some clients to repeat their requests only once every 30 seconds.
Note that it cannot force clients to not repeat their requests earlier, but if this has an effect for you, you may consider adjusting the value.

And if you do so, remember to remove or at least lower it once your upstreams are available again.

[Wpq]

@Bucking_Horn

You may try to lower their rate of repeat for their requests by adjusting your local-ttl.

Oh, this is a really good point, thanks.

In the meantime I recovered my fibre access and everything is back to normal - but I will keep this solution handy just in case