Understanding how Unbound listen on Port 53

Question

I have installed unbound on Debian Buster. Now I wonder why unbound listens 2 times on each Protocol.

netstat -tulpn

tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1150/unbound        
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1150/unbound        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      605/sshd: /usr/sbin 
tcp        0      0 127.0.0.1:8953          0.0.0.0:*               LISTEN      1150/unbound        
tcp6       0      0 :::22                   :::*                    LISTEN      605/sshd: /usr/sbin 
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1150/unbound        
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1150/unbound   

Can anyone help me understand this?

Answer 1

Unbound uses the SO_REUSEPORT option to allow multiple/processes threads to share the same listening port.

SO_REUSEPORT(since Linux 3.9)

          Permits multiple AF_INET or AF_INET6 sockets to be bound
          to an identical socket address.  This option must be set
          on each socket (including the first socket) prior to
          calling bind(2) on the socket.  To prevent port hijacking,
          all of the processes binding to the same address must have
          the same effective UID.  This option can be employed with
          both TCP and UDP sockets.

          For TCP sockets, this option allows accept(2) load
          distribution in a multi-threaded server to be improved by
          using a distinct listener socket for each thread.  This
          provides improved load distribution as compared to
          traditional techniques such using a single accept(2)ing
          thread that distributes connections, or having multiple
          threads that compete to accept(2) from the same socket.

          For UDP sockets, the use of this option can provide better
          distribution of incoming datagrams to multiple processes
          (or threads) as compared to the traditional technique of
          having multiple processes compete to receive datagrams on
          the same socket.