<div dir="ltr">Thank you David.  As I mentioned in the other thread, I'm not 100% sure if Snowflake is the only service generating excessive DNS queries. But I'll keep an eye on it and let you guys know if there's something unusual.<div><br></div><div>I ran some Wireshark traces after compiling the proxy code on Windows last night.  I didn't see anything unusual. I'll try Linux later.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022 at 8:34 AM David Fifield <<a href="mailto:david@bamsoftware.com">david@bamsoftware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Dec 26, 2022 at 01:43:32PM -0500, Cecylia Bocovich wrote:<br>
> On 12/26/22 00:55, John Selbie wrote:<br>
> > While the Snowflake project has good intentions, it doesn't appear to<br>
> > take my hosting costs into consideration. I'm hoping we can have a good<br>
> > discussion on the following:<br>
> > <br>
> > 1) How many snowflake clients and proxies are active and how many STUN<br>
> > requests are each generating towards <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a><br>
> > <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>>? Do we think the entire worldwide usage of<br>
> > Snowflake could be responsible for millions of STUN queries to<br>
> > <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>> per day?<br>
> > <br>
> > 2) Expected number of DNS queries (it's a 3-day TTL on these DNS<br>
> > entries, so it blows my mind that there are so many redundant requests).<br>
> > Does Pion or any other part of the Snowflake code tend to go direct to<br>
> > the namespace server itself?<br>
> > <br>
> > 3) Removing <a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">stun.stunprotocol.org</a> <<a href="http://stun.stunprotocol.org" rel="noreferrer" target="_blank">http://stun.stunprotocol.org</a>> as the<br>
> > default STUN server.<br>
> > <br>
> > OR...<br>
> > <br>
> > 4) Alternatively, I'm always open to accepting donations to help run the<br>
> > service costs of <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> <<a href="http://stunprotocol.org" rel="noreferrer" target="_blank">http://stunprotocol.org</a>>. I'm<br>
> > definitely not getting rich running this thing.<br>
> <br>
> Thank you for reaching out. This is exactly the right place to discuss this.<br>
> This was an oversight on my part not to reach out to you as the operator of<br>
> our configured default STUN server and I'm very sorry for the unexpected<br>
> increased costs. We can absolutely remove <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> as the default.<br>
<br>
Likewise, thanks for reaching out. Snowflake has grown faster then<br>
expected, in part because of a few crisis situations when it was one of<br>
few unblocked communications channels. Load on STUN servers was not much<br>
of a consideration in the early days when the system was small, but<br>
clearly it's something we need to think about now.<br>
<br>
> 1) I would definitely believe the amount of snowflake traffic to<br>
> <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> to be this high. We have over 100,000 proxies. According to<br>
> recent metrics[0], there are around 8 million matches a day and therefore<br>
> that many WebRTC ICE gathering requests coming from just the proxies. The<br>
> clients use a randomized subset of configured STUN servers, so the number is<br>
> slightly different but it's safe to say they are also generating a few<br>
> million STUN queries to your server.<br>
><br>
> 2) I'm not sure about the DNS queries. It also surprises me that there are<br>
> this many, I'll open an issue to investigate why.<br>
<br>
My guess is that the proxies that fail to cache DNS are standalone<br>
proxies (and to a lesser extent clients). The Go standard library may or<br>
may not cache DNS, depending on how it was compiled and possibly even on<br>
runtime conditions.<br>
<br>
<a href="https://pkg.go.dev/net#hdr-Name_Resolution" rel="noreferrer" target="_blank">https://pkg.go.dev/net#hdr-Name_Resolution</a><br>
        On Unix systems, the resolver has two options for resolving<br>
        names. It can use a pure Go resolver that sends DNS requests<br>
        directly to the servers listed in /etc/resolv.conf, or it can<br>
        use a cgo-based resolver that calls C library routines such as<br>
        getaddrinfo and getnameinfo. ... The resolver decision can be<br>
        overridden by setting the netdns value of the GODEBUG<br>
        environment variable to go or cgo ... or while building the Go<br>
        source tree by setting the netgo or netcgo build tag.<br>
<br>
When I run `GODEBUG=netdns=1 ./proxy`, it says<br>
        go package net: dynamic selection of DNS resolver<br>
Perhaps we should document `go build -tags netcgo` as the way to build<br>
the proxy, in order to use the OS resolver which is more likely to cache<br>
response records.<br>
<br>
> Now for immediate next steps. I've sent an email to people internally to<br>
> start the process of looking into sending some funds your way for the costs.<br>
> We might not get an answer until after everyone is back at work in January.<br>
> In the meantime:<br>
> <br>
> - I'd like to remove <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> as the default STUN server for the<br>
> proxies. The reason we added to our list in the first place was because it<br>
> implements RFC 5780 which we are using on the client side to determine NAT<br>
> matching and filtering types (thank you for this implementation BTW!). The<br>
> proxies no longer use this however, so there's no reason we can't have them<br>
> use any number of other public STUN servers.<br>
> <br>
> - We can remove <a href="http://stunprotocol.org" rel="noreferrer" target="_blank">stunprotocol.org</a> from the list of *default* client STUN<br>
> servers and reserve it for a small subset of users instead. This would<br>
> really cut down on the traffic, but keep it open as an option for clients in<br>
> places that have blocked other industry STUN servers.<br>
<br>
Another thing to consider is reducing the default polling frequency of<br>
standalone proxies and/or increasing the long-polling delay at the<br>
broker.<br>
</blockquote></div>