AdguardTeam / AdguardTeam/dnsproxy
Set keepalive to clean up CLOSE_WAIT dot connections.
- Dominant language
- Go
- Stars
- 3.3k
- Forks
- 343
- PR merge metrics
- No merged PRs in 30d
Description
Currently `dot` use simple slice to maintain existing connections. There is no logic about checking connections to clean up invalid connections.
```go
type dnsOverTLS struct {
// conns stores the connections ready for reuse. Don't use [sync.Pool]
// here, since there is no need to deallocate these connections.
//
// TODO(e.burkov, ameshkov): Currently connections just stored in FILO
// order, which eventually makes most of them unusable due to timeouts.
// This leads to weak performance for all exchanges coming across such
// connections.
conns []net.Conn
}
```
However public dns like google or Cloudflare will RST or FIN on server side frequently. I got a lot of FIN_WAIT_2 and CLOSE_WAIT in AdGuard side. Following logs are due to dns server send FIN and wait for ACK FIN from dnsproxy.
```logs
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33412
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33420
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33428
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33460
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33492
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33424
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33442
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33476
tcp FIN-WAIT-2 0 0 8.8.4.4:853 10.79.1.72:33444
```
Since there is no good connection pool and no async way to check in another thread for this.
A workaround of this in linux system is using keepalive to reduce the waiting time to 15secs, i.e.
```log
TCP_KEEPALIVE_TIME = 6s
TCP_KEEPALIVE_INTERVAL = 3s
TCP_KEEPALIVE_RETRIES=3
```
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.