From a thread on the anti-censorship-team email and the operator of stun.stunprotocol.org
1) I would definitely believe the amount of snowflake traffic to
stunprotocol.org to be this high. We have over 100,000 proxies. According to
recent metrics[0], there are around 8 million matches a day and therefore
that many WebRTC ICE gathering requests coming from just the proxies. The
clients use a randomized subset of configured STUN servers, so the number is
slightly different but it's safe to say they are also generating a few
million STUN queries to your server.
2) I'm not sure about the DNS queries. It also surprises me that there are
this many, I'll open an issue to investigate why.
My guess is that the proxies that fail to cache DNS are standalone
proxies (and to a lesser extent clients). The Go standard library may or
may not cache DNS, depending on how it was compiled and possibly even on
runtime conditions.
https://pkg.go.dev/net#hdr-Name_Resolution
On Unix systems, the resolver has two options for resolving
names. It can use a pure Go resolver that sends DNS requests
directly to the servers listed in /etc/resolv.conf, or it can
use a cgo-based resolver that calls C library routines such as
getaddrinfo and getnameinfo. ... The resolver decision can be
overridden by setting the netdns value of the GODEBUG
environment variable to go or cgo ... or while building the Go
source tree by setting the netgo or netcgo build tag.
When I run GODEBUG=netdns=1 ./proxy, it says
go package net: dynamic selection of DNS resolver
Perhaps we should document go build -tags netcgo as the way to build
the proxy, in order to use the OS resolver which is more likely to cache
response records.
From a thread on the anti-censorship-team email and the operator of stun.stunprotocol.org
1) I would definitely believe the amount of snowflake traffic to stunprotocol.org to be this high. We have over 100,000 proxies. According to recent metrics[0], there are around 8 million matches a day and therefore that many WebRTC ICE gathering requests coming from just the proxies. The clients use a randomized subset of configured STUN servers, so the number is slightly different but it's safe to say they are also generating a few million STUN queries to your server.
2) I'm not sure about the DNS queries. It also surprises me that there are this many, I'll open an issue to investigate why.
My guess is that the proxies that fail to cache DNS are standalone proxies (and to a lesser extent clients). The Go standard library may or may not cache DNS, depending on how it was compiled and possibly even on runtime conditions.
https://pkg.go.dev/net#hdr-Name_Resolution On Unix systems, the resolver has two options for resolving names. It can use a pure Go resolver that sends DNS requests directly to the servers listed in /etc/resolv.conf, or it can use a cgo-based resolver that calls C library routines such as getaddrinfo and getnameinfo. ... The resolver decision can be overridden by setting the netdns value of the GODEBUG environment variable to go or cgo ... or while building the Go source tree by setting the netgo or netcgo build tag.
When I run
GODEBUG=netdns=1 ./proxy
, it says go package net: dynamic selection of DNS resolver Perhaps we should documentgo build -tags netcgo
as the way to build the proxy, in order to use the OS resolver which is more likely to cache response records.