My local dns server -- technitium -- is getting spammed with STUN lookups that are failing

Support
1

I’ve read that syncthing shutdown it’s stun server (stun.syncthing.net doesn't resolve anymore).

Syncthing running on one of my virtual machines is constantly spamming my technitium dns server. In the logs I’m receiving this (these logs are not inclusive):

2025-07-14 18:22:19 Local] DNS Server failed to resolve the request 'stun.syncthing.net.domain.com. A IN' using forwarders: this-server.

TechnitiumLibrary.Net.Dns.DnsClientNoResponseException: DnsClient failed to recursively resolve the request 'stun.syncthing.net.domain.com. A IN': no response from name servers [a.gtld-servers.net, b.gtld-servers.net, c.gtld-servers.net, d.gtld-servers.net, e.gtld-servers.net, f.gtld-servers.net, g.gtld-servers.net, h.gtld-servers.net, i.gtld-servers.net, j.gtld-servers.net, k.gtld-servers.net, l.gtld-servers.net, m.gtld-servers.net] at delegation com.
   at TechnitiumLibrary.Net.Dns.DnsClient.RecursiveResolveAsync(DnsQuestionRecord question, IDnsCache cache, NetProxy proxy, Boolean preferIPv6, UInt16 udpPayloadSize, Boolean randomizeName, Boolean qnameMinimization, Boolean dnssecValidation, NetworkAddress eDnsClientSubnet, Int32 retries, Int32 timeout, Int32 concurrency, Int32 maxStackCount, Boolean minimalResponse, Boolean asyncNsResolution, List`1 rawResponses, CancellationToken cancellationToken) in Z:\Technitium\Projects\TechnitiumLibrary\TechnitiumLibrary.Net\Dns\DnsClient.cs:line 1811
   at TechnitiumLibrary.TaskExtensions.TimeoutAsync[T](Func`2 func, Int32 timeout, CancellationToken cancellationToken) in Z:\Technitium\Projects\TechnitiumLibrary\TechnitiumLibrary\TaskExtensions.cs:line 65
   at TechnitiumLibrary.TaskExtensions.TimeoutAsync[T](Func`2 func, Int32 timeout, CancellationToken cancellationToken) in Z:\Technitium\Projects\TechnitiumLibrary\TechnitiumLibrary\TaskExtensions.cs:line 65
   at DnsServerCore.Dns.DnsServer.DefaultRecursiveResolveAsync(DnsQuestionRecord question, NetworkAddress eDnsClientSubnet, IDnsCache dnsCache, Boolean dnssecValidation, Boolean skipDnsAppAuthoritativeRequestHandlers, CancellationToken cancellationToken) in Z:\Technitium\Projects\DnsServer\DnsServerCore\Dns\DnsServer.cs:line 3492
   at DnsServerCore.Dns.DnsServer.PriorityConditionalForwarderResolveAsync(DnsQuestionRecord question, NetworkAddress eDnsClientSubnet, Boolean advancedForwardingClientSubnet, IDnsCache dnsCache, Boolean skipDnsAppAuthoritativeRequestHandlers, IReadOnlyList`1 conditionalForwarders) in Z:\Technitium\Projects\DnsServer\DnsServerCore\Dns\DnsServer.cs:line 3504
   at DnsServerCore.Dns.DnsServer.RecursiveResolverBackgroundTaskAsync(DnsQuestionRecord question, NetworkAddress eDnsClientSubnet, Boolean advancedForwardingClientSubnet, IReadOnlyList`1 conditionalForwarders, Boolean dnssecValidation, Boolean cachePrefetchOperation, Boolean cacheRefreshOperation, Boolean skipDnsAppAuthoritativeRequestHandlers, TaskCompletionSource`1 taskCompletionSource) in Z:\Technitium\Projects\DnsServer\DnsServerCore\Dns\DnsServer.cs:line 3234
[2025-07-14 18:22:19 Local] [10.0.1.95:38337] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] [10.0.1.95:38337] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] [10.0.1.95:38337] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] [10.0.1.95:38518] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] [10.0.1.95:38518] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] [10.0.1.95:38518] [UDP] QNAME: stun.syncthing.net.domain.com; QTYPE: A; QCLASS: IN; RCODE: ServerFailure; ANSWER: []
[2025-07-14 18:22:19 Local] DNS Server failed to resolve the request 'stun.syncthing.net.domain.com. AAAA IN' using forwarders: this-server.

I’ve consulted documentation where the actual stun servers are located. 10.0.1.95 is an ubuntu installation so hence config.xml is located at /home/kevdog/.config/syncthing/config.xml

Within this file however I’m only finding the following:

<stunServer>default</stunServer>

Where is stun.syncthing.net.domain.com being derived? I don’t have any DNS SRV records for this particular domain. I am running my own discovery server however is this part of the problem?

2

I don’t see anything pointing at domain.com (or any of its subdomains) in the source code of Syncthing. I also did a DNS lookup of all the fallback STUN servers, none were CNAMEs to domain.com either.

Some (stun.counterpath.net, stun.ekiga.net, stun.xten.com) were CNAMEs to stun.counterpath.com though.

SRV look-ups to _stun._udp.syncthing.net (this is hardcoded and not derived from your configured discovery servers), and look-ups to the associated A record (fyc5mja4mz5s0vmz1txx.syncthing.net atm, but the point of the SRV record is that this can change), are normal and expected on Syncthing 1.29.6 and newer.

Are you running an unofficial and/or outdated build of Syncthing by any chance?

3

Sorry to put you through the paces but domain.com was meant to mask my real domain. I’m fairly certain my personal domain is not within your hardcoding either.

In terms of version, I’m running v1.27.2-ds4, Linux (64-bit Intel/AMD) on my Ubuntu server. My discovery servers pull from git. Does the discovery server have any control over the stun server name?

4

It’s a bug in that version that it never checks past the first server, which currently doesn’t exist.

5

Recommended solution is to update I take it?

6

That, but I added a workaround now so that it should resolve (but fail to work, because it still doesn’t exist), and then hopefully move on to the next in the list.

7

Thanks for help. I’m not sure it’s what you did, or when I just upgraded to v1.30.0, however no more dns stun queries are being logged. Curiously, previously I logged all dns queries (without any limits – yeah really dumb I know) and eventually my 4G technitium proxmox lxc container became totally disk limited, which created a bunch of havoc on my network since dns queries couldn’t be returned. Jeez didn’t know the effect. Thanks for update.

1 Like
8

That was my first thought, but it was not looking up the first server. It was looking up something akin to stun.syncthing.net.discovery.syncthing.kevdog.com, if I’m understanding @kevdog correctly, which is not the first server (stun.syncthing.net), nor is it on the list at all.

9

The local DNS server is probably configured to try to qualify names with the local domain.