Major DNS Bug 23.01 with Quad9 on SSL

Jimbohello

I found a new bug !

With version 23.01 i have only 50% of download bandwich ! Upload is ok 100%

I put back 22.05 and 2.6.0(community edition)
Download and upload reach 100%

Chelsio 520 on lan side
Intel pro nic on wan side

I mean that a weird bug
Maybe netgate should not code with a non existent freebsd 14 version mention « CURRENT » when it’s not even officially out as release date yet

https://www.freebsd.org/releng/
https://www.freebsd.org/releases/14.0R/schedule/

Maybe netgate pull out freebsd 14 from kinder suprise candy !

imo is based on freebsd release info

Thnk

So i stick to community for now

SteveITS

@jimbohello There are a few threads already for Chelsio.

https://forum.netgate.com/topic/177885/upgrade-to-23-01-wan-speed-halved/

https://forum.netgate.com/topic/177972/download-speeds-cut-in-half/

stephenw10

Yup, that's a separate issue. But do you have a T520-SO by any chance?

Jimbohello

@stephenw10

em0@pci0:1:0:0:	class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82574L Gigabit Network Connection'
    class      = network
    subclass   = ethernet
t5iov0@pci0:2:0:0:	class=0x020000 card=0x00001425 chip=0x50011425 rev=0x00 hdr=0x00
    vendor     = 'Chelsio Communications Inc'
    device     = 'T520-CR Unified Wire Ethernet Controller'
    class      = network
    subclass   = ethernet
t5iov1@pci0:2:0:1:	class=0x020000 card=0x00001425 chip=0x50011425 rev=0x00 hdr=0x00
    vendor     = 'Chelsio Communications Inc'
    device     = 'T520-CR Unified Wire Ethernet Controller'
    class      = network
    subclass   = ethernet
t5iov2@pci0:2:0:2:	class=0x020000 card=0x00001425 chip=0x50011425 rev=0x00 hdr=0x00
    vendor     = 'Chelsio Communications Inc'
    device     = 'T520-CR Unified Wire Ethernet Controller'
    class      = network
    subclass   = ethernet
t5iov3@pci0:2:0:3:	class=0x020000 card=0x00001425 chip=0x50011425 rev=0x00 hdr=0x00
    vendor     = 'Chelsio Communications Inc'
    device     = 'T520-CR Unified Wire Ethernet Controller'
    class      = network
    subclass   = ethernet
t5nex0@pci0:2:0:4:	class=0x020000 card=0x00001425 chip=0x54011425 rev=0x00 hdr=0x00
    vendor     = 'Chelsio Communications Inc'
    device     = 'T520-CR Unified Wire Ethernet Controller'
    class      = network
    subclass   = ethernet

stephenw10

Ok. Unfortunately it doesn't appear to affect the one Chelsio NIC I have available.
You could add that data point to the other thread.

w0w

It seems to me that this problem no longer appears on version 23.05

stephenw10

Ah, well that would be a very interesting result. Can anyone else hitting this verify that?

defunct78

Running the SG-1100, I have been fighting this problem for a while. I did notice the problem self resolved once I applied all the recommended patches on 23.01 and reboot. I have not gone in and attempted to figure out which one or combo fixes it, with a 1100 it is just too slow

Curious to know if this solution helps anyone else.

JonH

@defunct78 I'm running 23.01-Release on SG-5100. I'm still plagued with this issue and today I threw up my hands and reverted to port 53 and disabled python mode in both the resolver & pfBlocker.

I am now watching to see how my system responds.

Gertjan

@jonh

The reverse on my side :
I'm using a 23.01-Release on SG-4100.

I changed from default resolving to forwarding to quad9 :

As per instructions :

and then :

So :
Python mode (of course)
DNSSEC : of course not
Forwarding : that's what this all about : Yes
TLS : over TLS using port 853.

[suspicious mode : ON]
Look at the number of open TCP connections .... every one of them has an opened TLS state.
Nice .... but is it ?
These TLS connections are established by pfSense, not some LAN device.
To fire of a classic DNS request, using UDP, thousands of code lines are needed to handle the request, answers etc.
For TLS : that will be hundreds of thousands per connection - and I'm probably still not even close. Because now, it's TCP, far more complex as UDP, and then ... TLS.
To (re)build a TLS connections, entropy is going through the drain fast.
I never really found a way to measure available entropy, but what I know : if this one goes to zero, my web multi home server becomes slow. Note that the processor of my web (mail, bind, etc) server uses a quad core Intel(R) Xeon(R) CPU 3Ghz, way more power as my pfSense (a 4100).

Instead of using the word 'bug' or 'problem' I use this, which permits to to see more clearly what's going on.
Note that I've switched from resolving mode to forwarding mode over TLS on May 4,2023 @08h00.

On the other hand : I was forwarding to 1.1.1.1 and friends for a week or two.
Using TLS of course. I've found no (unbound or DNS) issues what so ever.

Probably important :
My IPv4 and IPv6 are, afaik, without issues.

[suspicious mode : OFF]

Now, let's wait for thread the subject "Major DNS Bug 23.01 with Quad9 on SSL" to happen.

stephenw10

I would argue this is a bug because the same load in 22.05 did not cause any problems even in much larger environments.

However has anyone verified that this still happens in 23.05?
We have one report saying that after upgrading the problem was solved.

Steve

N0m0fud

@stephenw10

I have been using pfSense w/ Unbound configured for DNS over TLS forwarding for years. Recently, it appears that there is a serious issue with the resolver. I get intermittent errors with the following:

2023-05-04 10:24:53.905770-05:00 unbound 3136 [3136:2] debug: comm point listen_for_rw 46 0
2023-05-04 10:24:53.905752-05:00 unbound 3136 [3136:3] debug: comm point listen_for_rw 47 0
2023-05-04 10:24:53.905719-05:00 unbound 3136 [3136:1] debug: comm point listen_for_rw 48 0
2023-05-04 10:24:53.882272-05:00 unbound 3136 [3136:1] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 10:24:53.882209-05:00 unbound 3136 [3136:3] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 10:24:53.882148-05:00 unbound 3136 [3136:1] debug: serviced send timer

Eventually, DNS queires from devices with IPv6 addresses fail causing mobile apps to crash on the connected device. The errors happen with or without pfBlocker DNSBL active

I can restart the Unbound service, it will work for a while then the errors return.

Also get this now with DNSBL:

servicewatchdog_cron.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1683215282] unbound[54733:0] debug: creating udp4 socket 192.168.246.1 53 [1683215282] unbound[54733:0] error: bind: address already in use [1683215282] unbound[54733:0] fatal error: could not open ports'

stephenw10

Are you using Quad9? Are you running 23.01? can you test 23.05?

SteveITS

@n0m0fud Have you disabled DNSSEC and/or DNS over TLS as discussed above?

re: watchdog and DNSBL...pfBlocker updates and DHCP registrations will restart unbound so watchdog should not try to also start it. It can end up starting twice which is presumably why it is saying the address/port is already in use. Same thing with Suricata/Snort or other services that restart as part of normal behavior.

N0m0fud

@stephenw10 Running 23.05 forwarding to Cloudflare. Its definitely an IPv6 issue. DNS does not resolve via DNS over TLS on IPv6 Interfaces. I rebooted the router which kills IPv6 for a time after the reboot. Everything worked fine until the IPv6 addresses activated and RADV started. Logs:

2023-05-04 11:01:43.286399-05:00 kernel - cannot forward src fe80:2::1ab4:30ff:fe03:3db, dst 2604:2d80:b208:f300:201:2eff:fe5a:6a7c, nxt 17, rcvif re1, outif re0
2023-05-04 11:01:07.981963-05:00 kernel - cannot forward src fe80:2::557:1ce2:51f6:763c, dst 2600:1402:b800:1a::6847:8fc5, nxt 6, rcvif re1, outif re0
2023-05-04 11:01:07.981902-05:00 kernel - cannot forward src fe80:2::557:1ce2:51f6:763c, dst 2600:1402:b800:1a::6847:8fd0, nxt 6, rcvif re1, outif re0

AND

2023-05-04 11:00:29.311174-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 89 0
2023-05-04 11:00:29.311008-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 92 0
2023-05-04 11:00:29.310857-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 91 0
2023-05-04 11:00:29.310710-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 85 0
2023-05-04 11:00:29.310546-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 86 0
2023-05-04 11:00:29.310400-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 87 0
2023-05-04 11:00:29.310242-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 90 0
2023-05-04 11:00:29.310094-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 84 0
2023-05-04 11:00:29.309943-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 88 0
2023-05-04 11:00:29.309776-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 81 0
2023-05-04 11:00:29.309627-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 82 0
2023-05-04 11:00:29.309463-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 83 0
2023-05-04 11:00:29.309314-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 77 0
2023-05-04 11:00:29.309160-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 80 0
2023-05-04 11:00:29.308995-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 79 0
2023-05-04 11:00:29.308839-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 78 0
2023-05-04 11:00:29.308673-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 76 0
2023-05-04 11:00:29.308519-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 73 0
2023-05-04 11:00:29.308369-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 75 0
2023-05-04 11:00:29.308191-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 67 0
2023-05-04 11:00:29.307997-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 70 0
2023-05-04 11:00:29.307829-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 61 0
2023-05-04 11:00:29.307696-05:00 unbound 52706 [52706:3] debug: comm point listen_for_rw 74 0
2023-05-04 11:00:29.307645-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 63 0
2023-05-04 11:00:29.307402-05:00 unbound 52706 [52706:1] debug: comm point listen_for_rw 69 0
2023-05-04 11:00:29.307354-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 62 0
2023-05-04 11:00:29.307164-05:00 unbound 52706 [52706:1] debug: comm point listen_for_rw 72 0
2023-05-04 11:00:29.307124-05:00 unbound 52706 [52706:2] debug: comm point listen_for_rw 66 0
2023-05-04 11:00:29.307052-05:00 unbound 52706 [52706:3] debug: comm point listen_for_rw 64 0
2023-05-04 11:00:29.306942-05:00 unbound 52706 [52706:1] debug: comm point listen_for_rw 65 0
2023-05-04 11:00:29.306894-05:00 unbound 52706 [52706:2] debug: comm point listen_for_rw 68 0
2023-05-04 11:00:29.306849-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 57 0
2023-05-04 11:00:29.306696-05:00 unbound 52706 [52706:1] debug: comm point listen_for_rw 71 0
2023-05-04 11:00:29.306664-05:00 unbound 52706 [52706:2] debug: comm point listen_for_rw 59 0
2023-05-04 11:00:29.306647-05:00 unbound 52706 [52706:3] debug: comm point listen_for_rw 60 0
2023-05-04 11:00:29.306475-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 54 0
2023-05-04 11:00:29.306241-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 53 0
2023-05-04 11:00:29.306079-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 55 0
2023-05-04 11:00:29.305913-05:00 unbound 52706 [52706:2] debug: comm point listen_for_rw 58 0
2023-05-04 11:00:29.305895-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 51 0
2023-05-04 11:00:29.305794-05:00 unbound 52706 [52706:3] debug: comm point listen_for_rw 56 0
2023-05-04 11:00:29.305412-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 52 0
2023-05-04 11:00:29.305247-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 50 0
2023-05-04 11:00:29.305075-05:00 unbound 52706 [52706:0] debug: comm point listen_for_rw 49 0
2023-05-04 11:00:29.294142-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.294112-05:00 unbound 52706 [52706:0] debug: tcp bound to src ip4 173.21.178.244 port 0 (len 16)
2023-05-04 11:00:29.294090-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.294056-05:00 unbound 52706 [52706:0] debug: tcp bound to src ip6 2604:2d80:8419:0:35e5:332b:4cf:e696 port 0 (len 28)
2023-05-04 11:00:29.294034-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.293995-05:00 unbound 52706 [52706:0] debug: comm point start listening 89 (-1 msec)
2023-05-04 11:00:29.293989-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.293941-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.293899-05:00 unbound 52706 [52706:0] debug: comm point start listening 87 (-1 msec)
2023-05-04 11:00:29.293871-05:00 unbound 52706 [52706:0] debug: tcp bound to src ip4 173.21.178.244 port 0 (len 16)
2023-05-04 11:00:29.293850-05:00 unbound 52706 [52706:0] debug: the query is using TLS encryption, for an unauthenticated connection
2023-05-04 11:00:29.293810-05:00 unbound 52706 [52706:0] debug: comm point start listening 85 (-1 msec)
2023-05-04 11:00:29.293777-05:00 unbound 52706 [52706:0] debug: tcp bound to src ip6 2604:2d80:8419:0:35e5:332b:4cf:e696 port 0 (len 28)

Customer Unbound Options:

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
forward-addr: 2606:4700:4700::64@853
forward-addr: 2606:4700:4700::6400@853

All Ips are pingable. The IPs are Cloudflare.

Not sure what's going on here.

stephenw10

If you set Unbound to use v4 interfaces for Outbound traffic only does that resolve it?

N0m0fud

@stephenw10 Only way to do that is manually edit and save the config file. The GUI only allows selection of physical interfaces. Not IP addresses.

jimp

2023-05-04 11:01:07.981902-05:00 kernel - cannot forward src fe80:2::557:1ce2:51f6:763c, dst 2600:1402:b800:1a::6847:8fd0, nxt 6, rcvif re1, outif re0

What has fe80:2::557:1ce2:51f6:763c? It shouldn't be trying to send traffic to a GUA address from LL, it's invalid.

What shows in the unbound config for interface binding(s)?

N0m0fud

@stephenw10 And restarting the service overrides my manual changes. This used to work fine until about 2 months ago. I know its local DNS as I can manually set the DNS on mobile devices that are showing the issue and the app failure problem goes away.

N0m0fud

@jimp Here is the Unbound.conf:

##########################

Unbound Configuration

##########################

Server configuration

server:

chroot: /var/unbound
username: "unbound"
directory: "/var/unbound"
pidfile: "/var/run/unbound.pid"
use-syslog: yes
port: 53
verbosity: 4
hide-identity: yes
hide-version: yes
harden-glue: yes
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
module-config: "python validator iterator"
unwanted-reply-threshold: 10000000
num-queries-per-thread: 2048
jostle-timeout: 200
infra-keep-probing: yes
infra-host-ttl: 900
infra-cache-numhosts: 20000
outgoing-num-tcp: 50
incoming-num-tcp: 50
edns-buffer-size: 4096
cache-max-ttl: 86400
cache-min-ttl: 0
harden-dnssec-stripped: yes
msg-cache-size: 512m
rrset-cache-size: 1024m
qname-minimisation: yes

num-threads: 4
msg-cache-slabs: 4
rrset-cache-slabs: 4
infra-cache-slabs: 4
key-cache-slabs: 4
outgoing-range: 4096
#so-rcvbuf: 4m
auto-trust-anchor-file: /var/unbound/root.key
prefetch: yes
prefetch-key: yes
use-caps-for-id: no
serve-expired: yes
aggressive-nsec: yes

Statistics

Unbound Statistics

statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes

TLS Configuration

tls-cert-bundle: "/etc/ssl/cert.pem"
tls-port: 853
tls-service-pem: "/var/unbound/sslcert.crt"
tls-service-key: "/var/unbound/sslcert.key"

Interface IP addresses to bind to

interface: 192.168.246.1
interface: 192.168.246.1@853
interface: 2604:2d80:b204:b00:201:2eff:fe5a:6a7c
interface: 2604:2d80:b204:b00:201:2eff:fe5a:6a7c@853
interface: 127.0.0.1
interface: 127.0.0.1@853
interface: ::1
interface: ::1@853

Outgoing interfaces to be used

outgoing-interface: 173.21.178.244
outgoing-interface: 2604:2d80:8419:0:c4a9:d993:4305:fa3e

DNS Rebinding

For DNS Rebinding prevention

private-address: 127.0.0.0/8
private-address: 10.0.0.0/8
private-address: ::ffff:a00:0/104
private-address: 172.16.0.0/12
private-address: ::ffff:ac10:0/108
private-address: 169.254.0.0/16
private-address: ::ffff:a9fe:0/112
private-address: 192.168.0.0/16
private-address: ::ffff:c0a8:0/112
private-address: fd00::/8
private-address: fe80::/10

Access lists

include: /var/unbound/access_lists.conf

Static host entries

include: /var/unbound/host_entries.conf

dhcp lease entries

include: /var/unbound/dhcpleases_entries.conf

Domain overrides

include: /var/unbound/domainoverrides.conf

Unbound custom options

server:
tls-upstream: yes
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
#forward-addr: 2606:4700:4700::64@853
#forward-addr: 2606:4700:4700::6400@853
#forward-addr: 149.112.112.11@853
#forward-addr: 9.9.9.11@853
#forward-addr: 2620:fe::11@853
#forward-addr: 2620:fe::fe:11@853
#forward-addr: 52.205.50.148@853

Remote Control Config

include: /var/unbound/remotecontrol.conf

Python Module

python:
python-script: pfb_unbound.py