DNS resolution

[anbotero]

Hello.

I’m curious about some DNS things that have been happening to our setup (colleague set it up, but he’s working on other stuff at the moment).

We setup an AWS machine (Ubuntu 18.04) to set Algo in, and we just wanted people in our team to connect to the VPN, and have access to some internal systems (we did the Subnet and Security Groups tuning ourselves).

1. Where do the DNS = value in peer/client configuration come from? I checked dnscrypt-proxy and Algo own folder/settings, and it didn’t find that value anywhere. Checked ip address and related too on the server, to no avail. Only place it appears on it’s when it generates peer configuration files. I just started checking this project so it might be something easy from Ansible, but I cannot find it (and I haven’t touched Ansible).
2. I’m curious because for some clients the configuration file works right away, but others (a lot) don’t. Connectivity works to the VPN server, but as soon as they connect, domain name resolution dies for them. They can ping 8.8.8.8 for example, but no name resolution, neither for anything inside VPN/VPC (AWS network) nor Internet. I tried adding a new DNS server to entries and it works, but I don’t yet understand why initially for some clients it does and not for others. So before it was DNS = <ip-i-dont-know-where-it-comes-from>, and it would fail for some people, and with DNS = <ip-i-dont-know-where-it-comes-from>, 8.8.8.8 now it works for pretty much all of us. Do you know why this might be? Should I set this secondary DNS here or somewhere in the server, like in dnscrypt_servers? It’s already setup to cloudflare there. It looks like a local issue, though.
3. I saw another discussion here about Split Tunnel. So let me get this straight, so I can understand better if what I’m doing is correct: We connect to VPN, so ALL local machine name resolution happens on the server first? Like, I set AllowedIPs to our AWS Subnet CIDR, so in order for the system to know what I’m trying to access is a VPN-only resource, it would need to get resolve the domain on the VPN server, right? But then all of my local machine DNS resolution is actually happening on the VPN server as well, so it knows what’s VPN and what’s Internet?
4. Since I restricted AllowedIPs, should I also include there the IP that appears in DNS =?

We just want our people to access internal resources, and that such access is the only thing that passes through Algo server. It’s an internal resource with an IP in X CIDR range? VPN. It’s something not trying to access our AWS Subnet CIDR range? Use these Y DNS servers.

Just curious if you’ve have had to deal with these client (apparently) issues. If it’s any help, most of our clients use the Apple Store WireGuard official application, and when I tried it on Archlinux, I had to run/enable systemd-resolved before running Wireguard connection, otherwise exactly same issue as I commented about no DNS resolution would happen to me. I’m just curious that I see so few issues on name resolution on these discussions, so I’m not sure if we did something bad on the server or what.

Thanks for tolerating the lots of newbie and sometimes ignorant inquiries! 😬

[davidemyers]

Here's how DNS works on Algo by default:

The DNS IP addresses in the WireGuard config files are randomly generated for each AlgoVPN server. They point to an instance of dnscrypt-proxy running on the server (see ip address show dev lo), which in turn securely forwards DNS queries to the servers defined in dnscrypt_servers.

A WireGuard client will send all DNS queries to the servers defined in DNS in the config file.

So if you're changing AllowedIPs from the Algo default and blocking access to the dnscrypt-proxy addresses you may have problems.

If you need to use your own DNS servers then you might want to change the defaults. If you set dns_encryption: false when you deploy then dnscrypt-proxy is not used and the clients use the DNS servers defined in dns_servers directly. If you've already deployed then you can edit the WireGuard config files and change DNS to point to your chosen DNS servers.

[anbotero]

Hey, thanks for the prompt response!

Two further inquiries:

1. ip address show dev lo values none match with the DNS = value our configurations files get. This happens in two different installations we have (Dev and Prod, so to speak), different AWS accounts/machines. None of the values on ip address show match the value generated in DNS =. dnscrypt-proxy configuration files also do not mention this IP anywhere.
2. But if I get it right, even though it works for some, and it doesn’t for others, if I had a Subnet range like 172.19.0.0/16, and the DNS = value is 172.21.157.16, then I should set AllowedIPs like AllowedIPs = 172.19.0.0/16, 172.21.157.16/32, am I correct?

Thanks again!

[davidemyers]

Do you have any 172.* addresses on lo? How about in the listen_addresses setting in /etc/dnscrypt-proxy/dnscrypt-proxy.toml?

Have you changed the hostname of this instance since Algo was deployed?

I've only used the default AllowedIPs with Algo, but I would think just allowing 172.19.0.0/16 would work.

[anbotero]

1. Yes, the 172.* address in lo is the one assigned to the machine in AWS Subnet, but it’s not even the same range as the one that appears in DNS =. listen_addresses setting actually has that lo IP in it, not the one in DNS =. Machine/listen IP: 172.18.14.100, DNS IP: 172.19.157.16.
2. Interesting, yes, the hostname in AWS is generated indicating the IP assigned, and it’s actually different to ALL the ranges previously mentioned, haha.

Looks like I’m just going to install Algo myself. The hostname thing makes me doubt a little bit now what my colleague did on these boxes. Perhaps he had other issues and tried lots of stuff which poisoned a little bit its configuration, so to speak. Still, if you happen to recollect anything else that might be going on, I’ll keep checking this.

Thanks!

[davidemyers]

I asked about the hostname because of bug #1783 where the generated address can change unexpectedly. Maybe that's what happened.

[davidemyers]

One more thought. I don't know much about how Arch is configured but systemd-resolved is capable of split DNS so depending on how you configured things it might be routing DNS requests to the DNS server that was in effect before you brought up WireGuard, not the unreachable one on the AlgoVPN server.