https-dns-proxy: init at unstable-20200419 #81365

peterhoeg · 2020-02-29T12:30:34Z

Motivation for this change

Some applications support DNS over HTTPS but using the https-dns-proxy, it is
now available to all devices on a network.

This PR was opened on a machine that used a firewall that resolves everything
via https-dns-proxy, so it works.

Things done

vcunat · 2020-02-29T13:14:21Z

Well, for proxying I'd generally prefer DoT over DoH, but that's certainly nothing against this PR :-)

pvgoran · 2020-03-01T04:02:12Z

Doing random review.

I was able to rebase this branch on nixos-19.09 and run the https-dns-proxy service. However, it did not work out of the box (DNS queries made by, for example, dig @127.0.0.1 -p 5053 github.com timed out).

Turns out this is because I don't have IPv6 connectivity on my machine, and https-dns-proxy only tries to use an IPv6 address for doing upstream queries, unless instructed otherwise.

I think that -4 needs to be added to https-dns-proxy options unless networking.enableIPv6 is true. This can be accomplished by adding https-dns-proxy's own enableIPv6 option which defaults to networking.enableIPv6.

Once I added -4 to extraArgs, DNS resolution worked for me.

vcunat · 2020-03-01T07:45:43Z

Even if networking.enableIPv6 = true (and it is by default), you have no guarantee that IPv6 actually works. For mobile devices that can even change dynamically, and it's my perception that people especially want to encrypt DNS on connections like in a coffee shop, hotel, ... and those in my experience tend not to have IPv6.

pvgoran · 2020-03-01T09:48:12Z

Considering that networking.enableIPv6 is true by default, and it's far more probable to encounter a IPv4-only network rather than IPv6-only network, setting the local enableIPv6 option to false by default makes sense, indeed.

(And maybe it should be called useIPv6, or even connectViaIPv6.)

vcunat · 2020-03-02T07:41:58Z

Yes, unless they implement the recommended approach of trying both protocols in parallel with preference to IPv6.

peterhoeg · 2020-03-02T08:28:38Z

We now have preferIPv4 which is set to true by default. I haven't tried it yet but will be giving it a go tonight.

pvgoran · 2020-03-02T12:54:32Z

I tried the new version. Now it does use -4 by default, but it still doesn't work out of the box. :( However, if I switch provider to "google", it starts working.

Upon further investigation: cloudflare-dns.com has two IPv4 addresses: 104.16.248.249 and 104.16.249.249. 104.16.248.249 one does not work for me:

> curl -H "Host: cloudflare-dns.com" https://104.16.248.249/dns-query -k -v                              ~
*   Trying 104.16.248.249:443...
* TCP_NODELAY set
* connect to 104.16.248.249 port 443 failed: Connection timed out
* Failed to connect to 104.16.248.249 port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to 104.16.248.249 port 443: Connection timed out

Turns out this IP is blocked by the Russian Federation government. :(

For 104.16.249.249, I receive an (empty) response, which is normal, I suppose.

Previously, this PR used Google's 8.8.8.8 for determining DoH provider IP address, and it returns 104.16.249.249 and then 104.16.248.249; so a "good" IP was used. Now, this PR uses Cloudflare's 1.1.1.1 for determining DoH provider's IP address, and it returns 104.16.248.249 and then 104.16.249.249; so a "bad" IP is used.

I don't know what would be a proper solution here. The problem is strictly local, so it could be ignored; on the other hand, it's present for a large territory. Using 8.8.8.8 as a bootstrap DNS server works as a work-around, but it's probably a random effect that shouldn't be relied upon. Defaulting provider to google would make the service work out of the box, but I would rather see cloudflare as a default. The problem would be solved if the https-dns-proxy program somehow tried multiple IPs and used the one that works, but this doesn't look like a trivial enhancement, and is outside the scope of nixpkgs.

vcunat · 2020-03-02T13:54:18Z

Now, this PR uses Cloudflare's 1.1.1.1 for determining DoH provider's IP address, and it returns 104.16.248.249 and then 104.16.249.249; so a "bad" IP is used.

CloudFlare rotates the records randomly on each reply, precisely because some dumb clients always use the first one (even though they shouldn't act that way). We actually discussed this with them.

pvgoran · 2020-03-02T15:45:04Z

CloudFlare rotates the records randomly on each reply, precisely because some dumb clients always use the first one (even though they shouldn't act that way). We actually discussed this with them.

Ok, I tested this, and several consecutive requests to 1.1.1.1 indeed produced results in different order. 8.8.8.8 actually does the same, so I was just lucky the first time, and unlucky the second time.

Mic92 · 2020-03-02T16:26:51Z

pkgs/servers/dns/https-dns-proxy/default.nix

+stdenv.mkDerivation rec {
+  pname = "https_dns_proxy";
+  # there are no stable releases (yet?)
+  version = "git-20200301";


We commonly use this scheme:

Suggested change

version = "git-20200301";

version = "unstable-2020-03-01";

Mic92 · 2020-03-02T16:30:08Z

nixos/modules/services/networking/https-dns-proxy.nix

+  cfg = config.services.https-dns-proxy;
+
+  providerCfg =
+    if cfg.provider == "cloudflare"


I am against hard coding this. Also this limits support to ipv4.
Can we just leave this open? I for example run https://dns.thalheim.io/dns-query.
In an option an example for cloudflare or google could be listed though.
However I would leave it up to to the user to make a choice explicitly.

How about a custom option? So cf, google or custom and you then need to provide the servers yourself?

Instead of using custom, it's IMHO better to just make provider and (something like) dnsUrl mutually exclusive options.

I would not add any provider option at all. I think users should educate themselves, where they sent all their DNS queries to. I would rather link to https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers in the documentation.

Mic92 · 2020-03-02T16:31:26Z

cc @andir

peterhoeg · 2020-03-03T11:55:14Z

I would not add any provider option at all. I think users should educate themselves, where they sent all their DNS queries too.

I can definitely follow your line of thinking but I will argue that making things accessible beats being "ideologically pure" and that it's better to give people something that works out of the box with relatively sane defaults. I mean, why even provide this considering everybody should be using tor? So what I will do is this: 1. change the PR to allow people to specify the upstream servers 2. expand on the description using the link you provided to inform people about the consequence of their choice of upstream provider If someone just does 'enable = true;' things will work. If somebody such as yourself wants to use a specific upstream, that will work too. Everybody is happy, kittens will sing and free money all around.

Mic92 · 2020-03-11T11:09:00Z

I can definitely follow your line of thinking but I will argue that making things accessible beats being "ideologically pure" and that it's better to give people something that works out of the box with relatively sane defaults. I mean, why even provide this considering everybody should be using tor? So what I will do is this: 1. change the PR to allow people to specify the upstream servers 2. expand on the description using the link you provided to inform people about the consequence of their choice of upstream provider If someone just does 'enable = true;' things will work. If somebody such as yourself wants to use a specific upstream, that will work too. Everybody is happy, kittens will sing and free money all around.

ok

peterhoeg · 2020-04-20T05:42:25Z

This hasn't had a very high priority for me, so I've just changed the PR to only include the packaging. The module will come later.

peterhoeg · 2020-04-20T05:45:03Z

@GrahamcOfBorg build https-dns-proxy

peterhoeg requested a review from infinisil as a code owner February 29, 2020 12:30

ofborg bot added 6.topic: nixos 8.has: module (update) 8.has: package (new) 11.by: package-maintainer 10.rebuild-darwin: 0 10.rebuild-linux: 1-10 labels Feb 29, 2020

peterhoeg force-pushed the p/https-dns branch from 27ef410 to 90f99b2 Compare March 2, 2020 07:07

peterhoeg force-pushed the p/https-dns branch 2 times, most recently from f0e3b7a to 6801c08 Compare March 2, 2020 09:35

Mic92 reviewed Mar 2, 2020

View reviewed changes

peterhoeg force-pushed the p/https-dns branch from 6801c08 to 890a7eb Compare March 10, 2020 14:30

peterhoeg force-pushed the p/https-dns branch from 890a7eb to 147590a Compare April 20, 2020 05:28

https-dns-proxy: init at unstable-20200419

93df15d

peterhoeg force-pushed the p/https-dns branch from 147590a to 93df15d Compare April 20, 2020 05:40

peterhoeg changed the title ~~nixos/https-dns-proxy: system level support for DNS over HTTPS~~ https-dns-proxy: init at unstable-20200419 Apr 20, 2020

peterhoeg mentioned this pull request Apr 20, 2020

nixos/https-dns-proxy: system level support for DNS over HTTPS #85599

Merged

9 tasks

peterhoeg merged commit 53c14c4 into NixOS:master Apr 20, 2020

peterhoeg deleted the p/https-dns branch April 20, 2020 06:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

https-dns-proxy: init at unstable-20200419 #81365

https-dns-proxy: init at unstable-20200419 #81365

peterhoeg commented Feb 29, 2020

vcunat commented Feb 29, 2020

pvgoran commented Mar 1, 2020

vcunat commented Mar 1, 2020

pvgoran commented Mar 1, 2020

vcunat commented Mar 2, 2020

peterhoeg commented Mar 2, 2020

pvgoran commented Mar 2, 2020

vcunat commented Mar 2, 2020

pvgoran commented Mar 2, 2020

Mic92 Mar 2, 2020

Mic92 Mar 2, 2020 •

edited

peterhoeg Mar 3, 2020

pvgoran Mar 3, 2020

Mic92 Mar 3, 2020 •

edited

Mic92 commented Mar 2, 2020

peterhoeg commented Mar 3, 2020 via email

Mic92 commented Mar 11, 2020

peterhoeg commented Apr 20, 2020

peterhoeg commented Apr 20, 2020

https-dns-proxy: init at unstable-20200419 #81365

https-dns-proxy: init at unstable-20200419 #81365

Conversation

peterhoeg commented Feb 29, 2020

Motivation for this change

Things done

vcunat commented Feb 29, 2020

pvgoran commented Mar 1, 2020

vcunat commented Mar 1, 2020

pvgoran commented Mar 1, 2020

vcunat commented Mar 2, 2020

peterhoeg commented Mar 2, 2020

pvgoran commented Mar 2, 2020

vcunat commented Mar 2, 2020

pvgoran commented Mar 2, 2020

Mic92 Mar 2, 2020

Choose a reason for hiding this comment

Mic92 Mar 2, 2020 • edited

Choose a reason for hiding this comment

peterhoeg Mar 3, 2020

Choose a reason for hiding this comment

pvgoran Mar 3, 2020

Choose a reason for hiding this comment

Mic92 Mar 3, 2020 • edited

Choose a reason for hiding this comment

Mic92 commented Mar 2, 2020

peterhoeg commented Mar 3, 2020 via email

Mic92 commented Mar 11, 2020

peterhoeg commented Apr 20, 2020

peterhoeg commented Apr 20, 2020

Mic92 Mar 2, 2020 •

edited

Mic92 Mar 3, 2020 •

edited