Slow loading times (e.g. heise.de) and no DNS resolution with pihole -g

Hi,

I'm using pihole on a Raspberry Pi 3 Model B with Arch installed. I'm using my Router (Fritz!Box) as my IPv4 upstream DNS Resolver in the pihole settings. I haven't specified an other upstream DNS resolver.
I'm testing pihole with a windows client and set there manually the ipv4 and ipv6 of my local Raspberry Pi as the only DNS resolver and having the following issues. I read about the problems but I'm not able to fix them.

  Pi-hole version is 3.2.1 (Latest: v3.2.1)
  AdminLTE version is 3.2.1 (Latest: v3.2.1)
  FTL version is v2.13.2 (Latest: v2.13.2)
  1. "DNS resolutions is not available" if I'm using pihole -g or the web ui. I read about the bug so here is my resolv.conf

    //# This file is managed by man:systemd-resolved(8). Do not edit.
    //#
    //# This is a dynamic resolv.conf file for connecting local clients directly to
    //# all known uplink DNS servers. This file lists all configured search domains.
    //#
    //# Third party programs must not access this file directly, but only through the
    //# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
    //# replace this symlink by a static file or a different symlink.
    //#
    //# See man:systemd-resolved.service(8) for details about the supported modes of
    //# operation for /etc/resolv.conf.

    //# nameserver 192.168.10.1 ==> router address
    nameserver 127.0.0.1

Yesterday I could fix the problem with adding nameserver 127.0.0.1 but today it's not working.

  1. I'm having slow loading times on pages like heise.de. Other users had the same problem but i was not able to try their solutions because i couldn't use pihole -g. I was mostly connected with IPv6 or https issues. Therefore i updated the IPv6 global address in /etc/pihole/setVars.conf which was outdated and checked iptables. I also disabled ip(6)tables but this didn't resolve the problem. My current firewall settings are:

    sudo ip6tables -nL
    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all ::/0 ::/0 ctstate RELATED,ESTABLISHED
    ACCEPT all ::/0 ::/0
    DROP all ::/0 ::/0 ctstate INVALID
    ACCEPT icmpv6 ::/0 ::/0 ipv6-icmptype 128 ctstate NEW
    ACCEPT icmpv6 fe80::/10 ::/0
    ACCEPT tcp ::/0 ::/0 tcp dpt:22
    ACCEPT tcp ::/0 ::/0 tcp dpt:80
    REJECT tcp ::/0 ::/0 tcp dpt:443 reject-with tcp-reset
    ACCEPT all fe80::/10 ::/0
    ACCEPT tcp ::/0 ::/0 tcp dpt:53
    ACCEPT udp ::/0 ::/0 udp dpt:53

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    sudo iptables -nL
    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    DROP all -- 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
    ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ctstate NEW
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
    REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 reject-with tcp-reset
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
    ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

I'm new to iptables and pihole so please be patient if i have done something wrong :slight_smile:slight_smile:
I tried to create a debug token or debug log but pihole -d doesn't exists.

Greetings from germany

Check if the "nameserver 127.0.0.1" is still there.
This "resolv.conf" file is often managed by other software that can overwrite these settings.
I dont know about "Arch" but with Raspbian/Debian, the "resolv.conf" file is being populated through dhcpcd5, the "static domain_name_servers=" bit:

pi@noads:~ $ tail -5 /etc/dhcpcd.conf
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name_servers=127.0.0.1

Why not ? Errors displayed ?

Sounds to me something is still broken with the "Arch" setup.
Maybe someone with similar (working) setup can help out.

The Arch install doesn't include the debugger. You can see more info about that package here: AUR (en) - pi-hole-server

  1. Yes nameserver 127.0.0.1 is still the only entry in resolv.conf.
  2. pihole -g doesn't work because the DNS Problem => so depends on Problem #1
    Error is:
    [✗] DNS resolution is currently unavailable
    [✗] DNS resolution is not available

@Mcat12 is there a option to debug pihole on arch linux or is there a log file that contains information about the issues?

Thanks for you help.

What is the output of these commands?

timeout 1 getent hosts pi.hole
timeout 1 getent hosts raw.githubusercontent.com
timeout 1 dig +short pi.hole
timeout 1 dig +short raw.githubusercontent.com

Hi,

i got pihole -g working again. The issue seems still to be the nameserver entries but i comment them wrong.
I uses in hurry #nameserver 192.168.10.1 but it seems to be that there must be a blank after the '#' or at leat the nameserver 127.0.0.1 at the top of the file.

I asked again about a debug option because i though of a log file that contains valuable information about such issues.
Anyway here is the output of the commands:

pi@raspberry~> timeout 1 getent hosts pi.hole
pi@raspberry~> timeout 1 getent hosts raw.githubusercontent.com
151.101.112.133 github.map.fastly.net
pi@raspberry~> timeout 1 dig +short pi.hole
192.168.10.10
pi@raspberry~> timeout 1 dig +short raw.githubusercontent.com
github.map.fastly.net.
151.101.112.133
pi@raspberry~>

After getting pihole -g i tried this possible solution:

SSH into the Pi Hole server
Run ifconfig to get the IPv6 address (global, not local)
sudo nano /etc/pihole/setupVars.conf
Change IPV6_ADDRESS to the address from step 2
Run pihole -g
Log into routers settings
Update the IPv6 DNS server to the new address
Restart the Pi Hole server
Restart the router
Joy

from this thread: https://discourse.pi-hole.net/t/some-websites-load-very-slow/1876/24

It seems to be faster now but i need mor time to test. Just got some minutes today to properly test it.

Just to be sure: I havn't configured a upstream DNS in the pihole settings. Is that a problem if there a DNSv6 request to the pihole?

Thank you very much!

:eyes: What are the contents of /etc/pihole/setupVars.conf? Without an upstream DNS server you shouldn't be able to resolve unblocked domains.

I was clearly to tired yesterday evening. I wanted to point out that havn't configured a IPv6 DNS Resolver. IPv4 Upstream Resolver is my router. So i wannted to ask if the missing IPv6 Resolver is a problem.

I would like to set my router as IPv6 Upstream Resolver too but I'm not sure which ipv6 address the router dns has because the default gatway ipv6 address is different from the dns server ipv6 address provided by in or by routers dhcp settings (default value)

Sry for the confusion.

If you have IPv6 internet access, then you should configure the router with Pi-hole's IPv6 address (and make sure Pi-hole is using IPv6). As for finding the IPv6 address of the router, Google will help you :wink:.

Finding the IPv6 isn't the issue. My router has nothing to do with which device will get pihole. I'm setting the dns v4 & v6 resolvers manually on each device. The thing is / was the Upstream DNS from pihole to the router: Is there a IPv6 resolver needed/essentiell? My router seems to habe two ipv6 adresses one as default gateway and one for the dns server. That was the issue why i havn't just used one. I wasn't sure which on was the right one.

But anyway: Sites like heise or youtube ads are now loading faster but still not as fast as without pihole. In Firefox the site loads around 10 to 15 seconds but displays the actual content after 1-2 seconds. In Edge loading is done after 2 seconds. Chrome is much worse. I get the first content after 15 seconds. So there is still an issue.

If i change IPv4 and IPv6 in SetupVars.conf to 0.0.0.0 and 0:0:... Firefox loading times are equal to Edge and only take 1-2 seconds. (I habe disabled all addons in FF) But is redirecting the queries to "null" intended?

My iptables are now:

pi@raspberry~> sudo iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere ctstate INVALID
ACCEPT icmp -- anywhere anywhere icmp echo-request ctstate NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
REJECT tcp -- anywhere anywhere tcp dpt:https reject-with tcp-reset
REJECT udp -- anywhere anywhere udp dpt:http reject-with icmp-port-unreachable
REJECT udp -- anywhere anywhere udp dpt:https reject-with icmp-port-unreachable
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:domain

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

pi@raspberry ~> sudo ip6tables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all anywhere anywhere DROP all anywhere anywhere ctstate INVALID ACCEPT ipv6-icmp anywhere anywhere ipv6-icmp echo-request ctstate NEW ACCEPT ipv6-icmp fe80::/10 anywhere ACCEPT tcp anywhere anywhere tcp dpt:ssh ACCEPT tcp anywhere anywhere tcp dpt:http REJECT tcp anywhere anywhere tcp dpt:https reject-with tcp-reset REJECT udp anywhere anywhere udp dpt:http reject-with icmp6-port-unreachable REJECT udp anywhere anywhere udp dpt:https reject-with icmp6-port-unreachable ACCEPT all fe80::/10 anywhere ACCEPT tcp anywhere anywhere tcp dpt:domain ACCEPT udp anywhere anywhere udp dpt:domain

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Disabling iptables has no effect.

Since DNS can go over IPv4 or IPv6 for any request, it does not matter if you have an IPv6 upstream or not. You can use the "null" option if you want (that is what is set when the web interface is not installed), but you might get warnings in place of ads on the page. You can try benchmarking the DNS to see if it's a DNS issue or perhaps an issue with your router/network.

I analyzed the long loading times today with wireshark. It's not an issue with IPv4 or IPv6 and even normal DNS lookup requests from windows with nslookup are fast.

The issues are https request to the raspberry pi (192.168.10.10) which are getting rejected with TCP rest as recommended at another topic if you use the pi-hole ip as the black hole. On pages like heise.de there a a lot of them. Below is a image of the wireshark capture. If i use the "null" service there are of course no such requests and therefore no such long loading times.

The TCP reset on port 443 should not have a noticeable effect on the speed of the page.

This is correct.

That is expected and also correct. The browser is immediately informed that the connection cannot succeed and stops trying to load that specific content. It looks exactly the same for me but then I see no long loading times. How about a screenshot from the Networkings tab from your Developer Tools of your browser? It should show which domain is still expected to arrive and you can have a look if this particular connection was reset.

@Mcat12 It has one, but a positive one: immediate closing of the connection instead of eventual timeout :wink:

Hi,
here is a screenshot of google chrome network tab after loading heise.de.
The long loading domains are pi-holed domains like https://script.ioam.de/iam.js.

Okay, there is this one request of a gif file that took > 40 seconds. Can you provide some more details on that one?

Here we go:

URL: https://www1.mpnrs.com/deliver2/trg/trg.gif?lv=9&tad=13f0kjf8mps0

Here is another screenshot of the network tab. For this one i changed the IPv4 and IPv6 of SetupVars.conf to "null" again. As you can see the same long loading request are now the fastest ones.

It might be that Chrome is using QUIC, which we've seen to cause some errors. You can disable it in chrome://flags

I had similair issues in the past with pihole -g
Added nameserver 8.8.8.8 above nameserver 127.0.0.1 in resolve.conf helped.
It will be overwritten later, but pihole -g works at least 1 time.

Your fritzbox: native ip6 ?....Does if have ipv6 dhcp enabled? What ipv6 DNS server is it telling the clients?

I disabled QUIC in chrome but it hadn't any effect on the issue. Here some screenshots.

@Jeroen1 i solved the pihole -g issue. My Fritz Box has native ipv6 enabled and is sending the ipv6 adress from pihole.