Unbound DNS slow website loading and finally stucking

[OPNPeta]

I have noticed a website loading performance problem when I use Unbound DNS. I only noticed this problem in the last few days, websites sporadically load very slowly and finally stuck. I blamed it on my playing computer running Ubuntu.

Today, however, I also noticed the performance problem on my main computer runnming macOS and I think I have been able to locate the source of the error in my OPNsense firewall after gradually decommissioning all devices one after another.

I can't say whether this was caused by an OPNsense update or has been the case for some time.

Unfortunately, I don't have the technical Linux/BSD background to be able to provide detailed diagnostics or logs.

I think I have localised the problem with OPNsense, because when I switch to Dnsmasq DNS instead of Unbound DNS I no longer have any website performance problems.

My system

OPNsense 24.7.7-amd64
FreeBSD 14.1-RELEASE-p5
OpenSSL 3.0.15

Under System > Settings > General the option "Allow DHCP/PPP to overwrite DNS server list on WAN" is disabled as long as I am using Unbound DNS. If I understand this correctly, the upstream/root DNS servers are then queried for Unbound DNS. I had to reactivate this option when using Dnsmasq DNS, as otherwise there was no DNS resolving in the WAN.

Is this a known problem?

[cookiemonster]

> Is this a known problem?
Nope. Unbound is solid. Enterprises use them.
We can't guess your setup though

[OPNPeta]

Hmm, I don't really know how or where to start to get rid of the error.

Unfortunately, I don't have the technical background, but what I can't explain is why the pages with Unbound DNS simply don't continue to load. It is just a DNS request, either it is resolved or not. So why are images on websites only half loaded? On different computers. No error logs. Just websites stucking while the (should) load.
Using Dnsmasq-DNS everything works like a charm.

That makes no sense.
I'm confused to the max... 

[OPNPeta]

Did some testing in the meantime. Seems to be a DNS related problem in general on my system, not related to (just) OPNsense.
As first mentioned that switching to Dnsmasq-DNS on OPNsense will fix slow website loading I have to add now that this was not the solution. Same behaviour, regardless of using Unbound-DNS or Dnsmasq-DNS.

Even with a public DNS ( e.g 8.8.8.8 ) manually set on my playing/working device same result. It's always the same pages that do not load or stuck while loading.

Examples:
https://ifun.de
https://www.jeffgeerling.com/

Set up OPNsense from scratch, same results.

Some info about my system:

• OPNsense on APU4 (default setup (no special setup like VLAN, firewall rules, etc.), IPv4 DHCP, IPv6 disabled,Unbound-DNS)
  
• german Telekom VDSL 250/40
• Vigor 165 VDSL modem
• Unifi 24-port POE switch
• Unifi U6-LR AP
• Unifi Network Controller running self-hosted on Raspberry Pi
• pi-hole (broadcasted as DNS by DHCP running on Raspberry Pi, pihole is disabled for now

Did a dns-cache flush on my devices as my last action. Everything seems to run much more smoother right now. Will watching it.

[b1ggi]

Hello,
i have the exact same problem like you described.

I have
- Zyxel VMG3006-D70A DSL Modem
- Opnsense on N5105 chinese firewall from aliexpress
- Telekom DSL 250/40
- private network with Unbound and ipv4 and ipv6 enabled
- guest network without Unbound (cloudflare dns) and v4 and v6 enabled (<- this is fast, but need to test more on more congested times)

I also want to get rid of this, and we can compare our configs if there is some common ground. I can send you some config screenshots after work today.

But maybe the reason is just that:

I think Telekom has some serious Peering problems with everyone who is not willing to do peering at their own locations and wants to get paid for that. For example Cloudflare has not a great backbone connection to Telekom. O2 or 1und1 has good open peering at DE-CIX. its like a walled garden, and the customers are the ones suffering. The problem is not always present, only when their network is more congested. You can try to use a vpn when there is slow loading, and suddenly the internet feels fast again.

[OPNPeta]

Hello,
i have the exact same problem like you described.

...

But maybe the reason is just that:

I think Telekom has some serious Peering problems with everyone who is not willing to do peering at their own locations and wants to get paid for that. For example Cloudflare has not a great backbone connection to Telekom. O2 or 1und1 has good open peering at DE-CIX. its like a walled garden, and the customers are the ones suffering. The problem is not always present, only when their network is more congested. You can try to use a vpn when there is slow loading, and suddenly the internet feels fast again.

Hello @b1ggi,
thanks for your feedback. Yesterday evening I again had bad slow loading times and set up OPNsense in a Proxmox VM to check for a hardware defect of my PCEngines APU4.

With the same result. The same pages always load extremely slowly without coming to an end. Embedded images on the website remain half loaded, at the bottom of the browser only a white page. No timeouts, no 404 error, whatever...

My OPNsense setup is also really really really basic. No VPN, no VLAN, no super special configurations, firewall rules etc. Just Telekom VDSL, IPv4 LAN with DHCP, Unbound-DNS.

The thought that it could also be due to the Telekom/routing/peering... etc. was also on my mind. Because: It's always the same pages that don't load (or only load from time to time). Not random global network problems on various pages.

[OPNPeta]

I think the reason for the slow website access is definitely not an OPNsense issue. Neither unbound DNS, Dnsmasq DNS nor OPNsense in general.

I have made several times a ping at the problematic website/domail ifun.de.
The response time generally was (very?) high, with regular dropouts on some devices, not always. But slow loading or stucking website.

However, since I also have the same problem with another ISP (my workplace has a dedicated line afaik), for example with an LTE/4G Fritzbox 6820v3 router, I assume that the problem is either on the side of the destination URL/domain or basically with Deutsche Telekom (all ISPs are probably Deutsche Telekom).

Using 4G/LTE Fritzbox 6820v3:

Code: [Select]

$ ping ifun.de
PING ifun.de (172.67.179.129): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 172.67.179.129: icmp_seq=3 ttl=50 time=133.068 ms
64 bytes from 172.67.179.129: icmp_seq=4 ttl=50 time=121.438 ms
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
64 bytes from 172.67.179.129: icmp_seq=9 ttl=50 time=154.368 ms
Request timeout for icmp_seq 10
64 bytes from 172.67.179.129: icmp_seq=11 ttl=50 time=141.843 ms
64 bytes from 172.67.179.129: icmp_seq=12 ttl=50 time=115.333 ms
^C
--- ifun.de ping statistics ---
13 packets transmitted, 5 packets received, 61.5% packet loss
round-trip min/avg/max/stddev = 115.333/133.210/154.368/14.003 ms
Using iPhone hotspot:

Code: [Select]

$ ping ifun.de     
PING ifun.de (172.67.179.129): 56 data bytes
64 bytes from 172.67.179.129: icmp_seq=0 ttl=50 time=173.035 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
64 bytes from 172.67.179.129: icmp_seq=5 ttl=50 time=146.799 ms
64 bytes from 172.67.179.129: icmp_seq=6 ttl=50 time=123.930 ms
64 bytes from 172.67.179.129: icmp_seq=7 ttl=50 time=139.072 ms
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
64 bytes from 172.67.179.129: icmp_seq=10 ttl=50 time=165.231 ms
64 bytes from 172.67.179.129: icmp_seq=11 ttl=50 time=136.977 ms
^C
--- ifun.de ping statistics ---
12 packets transmitted, 6 packets received, 50.0% packet loss
round-trip min/avg/max/stddev = 123.930/147.507/173.035/16.853 ms

Code: [Select]

$ traceroute ifun.de
traceroute: Warning: ifun.de has multiple addresses; using 172.67.179.129
traceroute to ifun.de (172.67.179.129), 64 hops max, 40 byte packets
 1  fritz.box (192.168.178.1)  5.899 ms  3.192 ms  3.158 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  80.156.5.67 (80.156.5.67)  83.004 ms  59.682 ms  25.632 ms
 9  h-sb1-i.h.de.net.dtag.de (62.154.49.197)  39.279 ms  52.426 ms  38.748 ms
10  d-sb1-i.d.de.net.dtag.de (62.154.3.61)  141.174 ms  122.424 ms  163.809 ms
11  ams-sb6-i.ams.nl.net.dtag.de (217.239.60.109)  125.050 ms
    217.239.42.113 (217.239.42.113)  138.399 ms  122.960 ms
12  if-ae-0-2.tcore3.njy-newark.as6453.net (216.6.90.14)  138.540 ms  126.983 ms  133.358 ms
13  66.198.70.2 (66.198.70.2)  138.530 ms  150.004 ms *
14  162.158.61.105 (162.158.61.105)  143.686 ms *
    162.158.61.101 (162.158.61.101)  173.196 ms
15  172.67.179.129 (172.67.179.129)  118.694 ms * *

[schmuessla]

Guys,

it is shit peering of DTAG which is well known for decades now and will last until the end of the universe. The internet is full of that and it will never change.
So if you want a good overall internet experience you should pick any DSL provider except DTAG