[BUG] connmand leaks file descriptors / UDP sockets to port 53 during virtual interface routing transitions (wg0)

Hello ConnMan Developers,

I am tracking a structural file descriptor leak in connmand when paired
with out-of-band virtual interfaces (specifically a kernel-space
WireGuard wg0 tunnel managed outside of ConnMan's D-Bus layers). 

The leak has been observed across multiple ARM-based embedded
configurations running the ConnMan daemon package profiles.

### Symptom
When the external virtual interface modifies global system routing table
layers, connmand begins spawning incremental UDP client sockets
targeting the local gateway on port 53. These sockets are abandoned in
an ESTABLISHED or CLOSE_WAIT state and are never closed via system
calls. The accumulation continues unchecked at a constant rate until
hitting the 1024 system file descriptor cap, flatlining system network
capability.

### Diagnostic Evidence (Gathered from active sessions)

1. Active Process Runtime Environment:
/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf

2. File Descriptor State (Steadily climbs to 1024 flatline threshold):
# ls -1 /proc/$(pidof connmand)/fd | wc -l
Output: 372 (and mounting)

3. Socket Allocation Trace (Stuck unique local source ports routing
outbound):
udp        0      0 192.168.178.53:48179    192.168.178.1:53       
ESTABLISHED
udp        0      0 192.168.178.53:48255    192.168.178.1:53       
ESTABLISHED
udp        0      0 192.168.178.53:57314    192.168.178.1:53       
ESTABLISHED
tcp        0      0 192.168.178.53:37104    212.227.81.55:80       
CLOSE_WAIT

4. Active Routing Table Constraints:
0.0.0.0/1 dev wg0 scope link
default dev wg0 scope link
128.0.0.0/1 dev wg0 scope link

### Workaround Insights
Invoking connmand explicitly with the `--nodnsproxy` runtime parameter
cleanly suppresses the rapid-fire port 53 socket accumulation on modern
builds, though internal tracking sockets still exhibit a slow paired
resource leak over time on older versions of the network daemon when the
network interface state changes.

It appears the internal Route Netlink (rtnl) sub-system or the internal
DNS proxy caching engine fails to perform proper handle reclamation
actions when external routing layers override primary paths.

Could anyone look into the resource tracking architecture to check where
these proxy sockets might be missing close() calls during route changes?

Best regards,
Doemela