V2 testing

[mosajjal]

Since v2 is rapidly developing, let's use this discussion thread to talk about new features and nice to haves :)

[mosajjal]

@prooshani I made some changes to the way configuration is working in v2. some config parameters changed and has been made more concise. please test using the latest commit in v2 branch and let me know if you're still having issues with binding DoT, DoH and DoQ (as per your comments #35)

[mosajjal]

are you using the latest commit? use this to install the latest v2 commit on your machine:

go install github.com/mosajjal/sniproxy@3928575947b2d8631497200dcd1e2f04d967e5df

this usually installs it on your /home/USER/go/bin/ directory. you can run it from there. alternatively, you can clone the repo and build it manually:

git clone https://github.com/mosajjal/sniproxy.git
cd sniproxy
git checkout v2
CGO_ENABLED=0 go build . 
./sniproxy --defaultconfig /tmp/conf.yaml

[prooshani]

After installing new v2 commit:

UDP,TCP and TLS starts to resolve correctly.
However, HTTPS and QUIC are still returning error.

At service start I have an Error related to quic:
failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size for details.

[yaser-k]

which version of go should I use to build?
snap install go # version 1.20.4, or
apt install golang-go # version 2:1.180ubuntu2
apt install gccgo-go # version 2:1.180ubuntu2

I assume id part of (go install github.com/mosajjal/sniproxy@3928575947b2d8631497200dcd1e2f04d967e5df) change for each commit is it right?

[prooshani]

Go installation is straight forward.
Look at their site according to your server OS.

[mosajjal]

@yaser-k haven't tested sniproxy against gccgo. only golang-go is tested. snap works too

[prooshani]

at the yaml conf file enabling DoT is missed:

bind_dns_over_udp: "0.0.0.0:53"
# enable DNS over TCP. empty disables it. example: "127.0.0.1:53"
bind_dns_over_tcp: "0.0.0.0:53"
# enable DNS over TLS. empty disables it. example: "127.0.0.1:853"
bind_dns_over_tls: "0.0.0.0:853"
# enable DNS over QUIC. empty disables it. example: "127.0.0.1:8853"
bind_dns_over_quic: "0.0.0.0:8853"

I don't know if it is by design or just a simple missing environment param.

[prooshani]

I need to address DoH for my own purpose and will check the solution you suggested at #32 .
But, I was checking their repo which looks quite old and do't know if it is a good idea or I should find another workaround for DoH!
If it help these repo to check that solution I am going into it.

[prooshani]

Check result:
The error is:
level=WARN msg="write tcp .xx.xx.xx:55316->yy.yy.yy.yy:853: write: broken pipe" service=https

yy.yy.yy.yy is my custom upstream resolver's IP.
The service indicates that the query is looking for DoH but the connection to the upstream and sniproxy looks not esablished and receives Broken Pipe.

The DNS client returned this error:

Error! The SSL connection could not be established, see inner exception. Received an unexpected EOF or 0 bytes from the transport stream.
I am using letsencrypt SSL certificate for this server. Is there any measurement I need to comply with due to the fact that #32 suggestion is for v1 and we are testing v2?

[prooshani]

you can set up a DoH server as a workaround using what I've explained in #32

@mosajjal
Did you tested this #32 solution?
I saw you mentioned that you have been not tested it yet.
I have tried numerous scenarios with absolute no luck.
I think this will not gonna work as a workaround for DoH.
Your suggestion for DoH server indicates that the doh-server should open the 8053 port to accept the https connection on this port and then upstream the request to the local sniproxy on udp port 53 and then return the DNS result back down to the client ovet https. Am I right?
If yes,
1- 8053 is not a standard HTTPS port to work with. Some clients and routers may struggle working on this port.
2- SSL Certificate for reverse-proxy won't work on the same IP.

I don't know, maybe I have done something wrong but the solution from #32 was not successful for me.

[prooshani]

I am going to test this as a plan B

[mosajjal]

the reverse proxy option in general is not tested and I'll probably rewrite it for v2. I might even consider changing ACLs to cater for reverse proxy. DoH will benefit from it as a result.

[prooshani]

This is the service log for quic queries:

level=ERROR msg="dns: overflowing header size" service=dns
WARN[0027] QUIC stream accept: timeout: no recent network activity 

which looks related to the buffer size of quic .

[prooshani]

using core udp buffer size increase resolved the error message about quic buffer size:

sysctl -w net.core.rmem_max=2500000
However, it did not affect the outcome positively and still getting error on quic queries:

INFO[0011] DNS query unpack: dns: bad rdata             
time=2023-05-05T04:40:17.568+03:30 level=INFO msg="returned sniproxy address for domain" service=dns fqdn=.
time=2023-05-05T04:40:17.578+03:30 level=ERROR msg="dns: overflowing header size" service=dns
WARN[0016] QUIC stream accept: timeout: no recent network activity 

[mosajjal]

my assumption is, this is due to the fact that my DoQ implementation uses localhost:53 as upstream DOS (over UDP) and that causes the overflow. it's currently a bug. Although I don't know many clients that actually support DoQ currently so on paper it shouldn't be a major issue?

[prooshani]

my assumption is, this is due to the fact that my DoQ implementation uses localhost:53 as upstream DOS (over UDP) and that causes the overflow. it's currently a bug. Although I don't know many clients that actually support DoQ currently so on paper it shouldn't be a major issue?

On paper yes, but I believe sooner than later DoQ can beat other encrypted DNS protocols due to its nature.
For now, it can flag as a not immediate issue.
I am using other DNS servers which are using port 853 shared with tls without any conflict or issue.
Using port 8853 has its issues for some cilents.

[mosajjal]

I think the original draft of DoQ was over port 8853, now they've changed it to 853. Either way it's configurable. I'm thinking of potentially updating the underlying library to support better DNS upstream. Maybe even dnscrypt

[prooshani]

dnscrypt and/or tor transparent redirect can increase the security of queries drastically however, I am not aware of its performance and implementation consequences.

[mosajjal]

dnscrypt automatically does a benchmark for speed and chooses the fastest server. it will be an opt-in option if ever implemented.

[prooshani]

Please consider fixing a typo issue at line 19 of config.default.yaml as below:
bind_http : "0.0.0.0:80"

it should be (there is an space before : which is not ok regarding YAML file's guidelines):
bind_http: "0.0.0.0:80"

[mosajjal]

oh yep for sure

[prooshani]

About upstream_dns...

If the server's nameserver sets to 127.0.0.1, which is correct configuration when we are using local resolvers, then the upstream_dns environment parameter only accepts IP addresses and url's will cause termination of the service due to runtime error:

time=2023-05-05T13:56:34.804+03:30 level=INFO msg="starting sniproxy" version=v2 commit=none
time=2023-05-05T13:56:34.805+03:30 level=INFO msg="server info" public_ip=xx.xx.xx.xx
time=2023-05-05T13:56:34.805+03:30 level=ERROR msg="Could not automatically determine public IPv6. you should provide it manually using --publicIPv6"
time=2023-05-05T13:56:34.806+03:30 level=ERROR msg="lookup upstream.dns.url on 127.0.0.1:53: read udp 127.0.0.1:41823->127.0.0.1:53: read: connection refused"
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xa6670b]

goroutine 1 [running]:
main.main()
	/tmp/sniproxy/main.go:420 +0x1bab

While it is an expected behavior, due to the fact that internal resolver is not up an running before starting sniproxy dns server itself, I hope it could be pinpointed with a default resolver so as to prevent these runtime error.
One resolution could be using a default resolver (8.8.8.8, 1.1.1.1 or 9.9.9.9) as a safeguard to resolve upstream dns url if the resolv.conf or systemd/resolved.conf are pointing to localhost as the server's nameserver.
It is just a suggestion and don't have any idea about its drawbacks though.

[mosajjal]

falling back has some consequences... especially on non-linux instances. I think a potential dnscrypt could solve this though. I need to think about what'll work best. at this moment, I consider this out-of-scope.

[prooshani]

I assume runtime errors should never consider as out-of-scope!
Fallback DNS, as is accessible on systemd/resolved.conf can be a good solution.
It can be an environment value. Coupled with some warning and notes about localhost nameserver can address runtime issue.

[mosajjal]

if the server is misconfigured, it should panic and exit. I'm happy to entertain the idea of multiple upstream DNS servers, but not resorting back to OS-level resolve. Not only that's complicated to implement, in many cases it leads to DNS leaks to the ISP, and unexpected behaviors from routers etc.

[prooshani]

Agreed.
I don't know if it is a good manner to check configuration before starting the service avoiding runtime panics and suggest the root of misconfiguration in some points.
I am working with some other DNS solutions which offer configuration checks so, I think if this kind of obvious misconfigs wont address at some points you may increasingly face new issues in your inbox from end-users which don't have knowledge about how DNS servers and its configuration should adjust to avoid panics.
I believe code authors should write codes for grade 5 end-users to make their own life easier.

[mosajjal]

I rewrote a few things and added a native DoH inside a new ACL called "override". right now the upstream of it is hardcoded to Google's one. also removed the reverse proxy option altogether since it was inconsistent. since I'm losing track of which convo is against which version, I created a new thread for v2-alpha3 here: #43. if you navigate to releases you can directly download the binary as well. no more building from scratch. please use alpha3 and post your tests there