Outline-client: Pls stop hardcoding DNS resolver in client

[mrphs]

I've raised this problem a long while ago privately but considering it hasn't changed, I'm assuming it has been forgotten, hence opening this ticket.

Outline shouldn't hard-code DNS resolver in the client. Especially when using OpenDNS. Ideally, this should be an option that is set by the outline manager. Otherwise outline should route the DNS through outline-server. This has a few reasons:

• OpenDNS is known to interfere with traffic and arbitrary filter, block or drop some requests. They always block Tor, sometimes they block Signal. And that's what a lot journalists need these days to communicate with each other and their sources. That is, if you want to continue to brand outline as a tool for safer journalism.

• I use outline to help people bypass censorship in various repressive countries. Bypassing one censor to hit another doesn't seem like an ideal situation.

• This interferes with the principles of open and decentralized web, which I believe are the underlying principles of having any services run self hosted.

• System administrators should have control over where their users' traffic is routing through.

• This has a great impact on the privacy of the users.

• This leads to people following nonstandard workarounds and potentially shooting themselves in the foot if they don't know what they're doing.

[Kolahzary]

I totally agree with this request, Here in I.R.Iran i can't use Outline on my Android because government censored hard-coded DNS Servers inside outline client, I don't know how they do that but months ago DNS stopped working for mobile phones which run Outline. (means if I turn on Outline, apps which use DNS to resolve their server's IP address will stop working, but some apps like Telegram works because they have IP address of their servers hard-coded inside them)

By the way I'm currently using Simple DNSCrypt + Shadowsocks client on my Laptop and it works perfectly.

[alalamav]

Thank you for your feedback. We are open to considering this feature request.
Since the client could easily override the DNS server set by the server admin (many apps use custom DNS resolvers), we are thinking of making a configurable option in the client. Perhaps the admin could set the default resolver in the invite.

[mrphs]

@alalamav Thanks for the response. I'd argue that those "many apps" you mentioned aren't probably routing the entire traffic of the device.

To be perfectly clear... I think it's ideal if it's configurable in "outline manager" and optionally possible to override by "outline client" if the users wishes to. Otherwise, considering most end users might not even know what DNS is, and that they already have trusted admin with their traffic, it might make sense to let the admin decide where the DNS requests should go.

[alalamav]

@mrphs, your proposal sounds reasonable to me.

The point I was trying to make is that there is no guarantee that a given app will use the system resolver set by Outline. They can always make DNS requests to the resolver of their choice and indeed many apps do.

[mvonweis]

Hi, this has become quite urgent as of today. I'm operating four servers in three different countries, and OpenDNS has stopped responding to all of them.

[modib]

@alalamav

1. An app not using system resolver is beyond the control of the user without port 53 traffic forwarding, so it could be ignored for now.
2. The Outline client should always rely on outline server to provide a list of DNS servers to be configured for client. The server can have a default list like the opendns servers or 9.9.9.9 that could be easily changed via outline manager. For non-technical users setting custom DNS servers via client is not something they should have to know. Technical users will always know how to override it.
3. Truly stealth option would be to embed a DNS-over-https(DoH) client with a localhost resolver on client side querying a DoH server on outline server side that uses an upstream DNS server configurable via outline manager. e.g. https://github.com/m13253/dns-over-https

[mvonweis]

I don't think Shadowsocks has a mechanism for setting the DNS servers, as it seems to be only a transparent proxy. The client needs to somehow understand which DNS servers to use. The Outline developers have made the simplest possible choice: the DNS servers are hardcoded into the Outline client. If these servers don't work for you, you're out of luck.

The simplest solution I can see is to make the DNS IP addresses changeable through extra URL arguments such as "?dns1=9.9.9.9&dns2=1.1.1.1". This looks sensible to me and is also backwards-compatible.

There could also be a UI element or a json/xml/plist file for users to manually change the DNS servers on the client side. You could also add to the server Docker image a simple httpd daemon that returns a dnsconfig.json file that the client can parse. And if I've understood SS properly (possibly not) you could also set up dnsmasq on the server Docker image, and hardcode the client to use this instead.

This is mostly a problem on the Mac where overriding Outline's default DNS servers is a tough exercise. I'd rather fix the problem properly than write scripts to work around it.

[Omoeba]

Just make a script called “routedns.sh” in your root directory using sudo nano /root/routedns.sh And paste in the following

#!/bin/bash

/sbin/iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to “outline-server-external-ipv4”:53;
/sbin/iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to “outline-server-external-ipv4”:53;
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE;
/sbin/ip6tables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to [“outline-server-external-IPv6”]:53;
/sbin/ip6tables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to [“outline-server-external-IPv6”]:53;
/sbin/ip6tables -t nat -A POSTROUTING -j MASQUERADE

exit 0

And then type sudo chmod +x /root/routedns.sh

Then type sudo nano /etc/rc.local And paste in this

#!/bin/bash

bash /root/routedns.sh

exit 0

Finally, type sudo chmod +x /etc/rc.local And enable rc-local by typing sudo systemctl enable rc-local

This will route all dns traffic to the outline server. I tested this on a DigitalOcean Ubuntu 18.04 droplet. This might not work on other vps providers and distros.

[modib]

@mvonweis The README on outline-server says

This repository has all the code needed to create and manage Outline servers on DigitalOcean. An Outline server runs instances of Shadowsocks proxies and provides an API used by the Outline Manager application.

Outline server install script installs 2 containers - the API for outline manager and the shadowsocks server.

The outline manager API can be extended to also allow defining a default set of nameservers that could be served to all the outline clients.

@Omoeba Thanks for the shell script but I don't think it fits neatly in the way outline-server, outline-manager and outline-client has been designed. Plus the script is not portable to windows and mac.

[Omoeba]

@modib what do you mean by not portable?

[mvonweis]

@modib Correct, but this requires modifying three components instead of one. The Manager app is so limited that out only works for trivial setups.

@omoeba The iptables script only works on Linux. Porting it to Mac or Windows requires rewriting the whole script.

[Omoeba]

The script is meant to be run on the server, not the client.

[asteriskyg]

Just make a script called “routedns.sh” in your root directory using sudo nano /root/routedns.sh And paste in the following

#!/bin/bash

/sbin/iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to “outline-server-external-ipv4”:53;
/sbin/iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to “outline-server-external-ipv4”:53;
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE;
/sbin/ip6tables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to [“outline-server-external-IPv6”]:53;
/sbin/ip6tables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to [“outline-server-external-IPv6”]:53;
/sbin/ip6tables -t nat -A POSTROUTING -j MASQUERADE

exit 0

And then type sudo chmod +x /root/routedns.sh

Then type sudo nano /etc/rc.local And paste in this

#!/bin/bash

bash /root/routedns.sh

exit 0

Finally, type sudo chmod +x /etc/rc.local And enable rc-local by typing sudo systemctl enable rc-local

This will route all dns traffic to the outline server. I tested this on a DigitalOcean Ubuntu 18.04 droplet. This might not work on other vps providers and distros.

@Omoeba I'm sorry but I'm not good at iptables... so could you write some example codes with example ip for me?

[Omoeba]

@ASTERISK-Git this will route all dns to cloudflare’s DNS at https://1.1.1.1/dns/

#!/bin/bash

/sbin/iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 1.1.1.1:53;
/sbin/iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 1.1.1.1:53;
/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE;
/sbin/ip6tables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to [2606:4700:4700::1111]:53;
/sbin/ip6tables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to [2606:4700:4700::1111]:53;
/sbin/ip6tables -t nat -A POSTROUTING -j MASQUERADE

exit 0

[fortuna]

I hear the need to specify the DNS resolver to be used. That should be specified by the managers, as general users don't know how to do that.

I like the idea of the server running its own resolver. Then the client could be changed to try :53 first. Or perhaps a special address like dns.local, since Shadowsocks allows for domain addresses.

What should this server resolver look like? I see at least two options:

• A full recursive resolver, so you don't actually depend on any third party resolver and no extra configuration is needed. This may hurt performance or require extra memory.
• A stub resolver that talks to a third-party resolver. This requires the manager to specify the resolver somehow. Or perhaps we use the system resolver of the host machine.

Thoughts?

cc: @bemasc

[fortuna]

Clarifying some implementation options.

DNS Wiring

A) Run a stub resolver on the Client's localhost that forwards the queries to dns.local (or some other pre-defined domain) via a Shadowsocks proxy connection. The server would intercept dns.local and forward to the designated resolver. Configure the VPN to use the localhost address as the DNS resolver.
B) Configure the VPN to use as the primary DNS resolver. Change server to resolve DNS on :53 using the designated resolver.
C) Fetch some DNS config with the address of the designated resolver from the server on connection and configure the VPN with that.
D) Hardcode the designated DNS resolver on the invite. Can't be changed later.

In A-C the Client needs to check if the resolver supports DNS resolution. For backward compatibility, we can check that in the connectivity test and fallback to the existing behavior on failure. Similar to how we fallback DNS to TCP if UDP is blocked.

(D) is probably the easiest, but cannot be changed.
(C) is probably a good compromise of simplicity and flexibility
A-B is compatible with third-party Shadowsocks clients that allow specifying the IP of the resolver.

Server designated resolver

There are a few options for the designated resolver:
A) Run own recursive resolver
B) Use the host's system resolver
C) Use a third-party resolver, specified somehow by the admin. This is similar to (B), since the admin can change the system resolver.

[bemasc]

One interesting consideration here is that, if the VPN advertises the IP of a good third-party resolver, Android DoT and Chrome DoH might be able to upgrade to encrypted DNS. This improves the user's privacy with respect to the proxy server, and also has nontrivial performance and reliability implications (perhaps good, perhaps bad).

I think the best balance of simplicity and flexibility might be to place the proxy's recommended DNS server in a shadowsocks online-config JSON blob, and avoid changing the behavior of ss:// access keys (which would continue to use client-hardcoded resolvers).

One tricky thing here is that Chrome DoH needs to see the third-party IP as the configured DNS server, so we would need to reconfigure the VPN interface after receiving the latest shadowsocks config.