privacyguides
/
privacytools.io
Archived
1
0
Fork 0
Code Issues 304 Pull Requests 47 Activity

Add Encrypted DNS providers table #1097

Merged
nitrohorse merged 23 commits from add-dns-table into master 2019-08-09 15:00:57 +00:00
Conversation 17 Commits 23 Files Changed 2 +300 -13
nitrohorse commented 2019-08-05 04:46:17 +00:00 (Migrated from github.com)
Copy Link

Description

Resolves: #1077
Resolves: #1068
Resolves: #1070

<!-- PLEASE READ OUR [CONTRIBUTING GUIDELINES](https://github.com/privacytoolsIO/privacytools.io/blob/master/.github/CONTRIBUTING.md) BEFORE SUBMITTING --> ## Description Resolves: #1077 Resolves: #1068 Resolves: #1070
netlify[bot] commented 2019-08-05 04:46:59 +00:00 (Migrated from github.com)
Copy Link

Deploy preview for privacytools-io ready!

Built with commit 115c8939815cc3fe87e34836a1244563833a6232

https://deploy-preview-1097--privacytools-io.netlify.com

Deploy preview for *privacytools-io* ready! Built with commit 115c8939815cc3fe87e34836a1244563833a6232 https://deploy-preview-1097--privacytools-io.netlify.com
netlify[bot] commented 2019-08-05 04:47:33 +00:00 (Migrated from github.com)
Copy Link

Deploy preview for privacytools-io ready!

Built with commit 9f661d8cae

https://deploy-preview-1097--privacytools-io.netlify.com

Deploy preview for *privacytools-io* ready! Built with commit 9f661d8cae45c7d1126430cdd017671e2461c912 https://deploy-preview-1097--privacytools-io.netlify.com
nitrohorse commented 2019-08-05 04:56:30 +00:00 (Migrated from github.com)
Copy Link

@Mikaela I think we'll want to clarify criteria for adding a DNS provider to the list and also whether any that I've listed should be removed.

@Mikaela I think we'll want to clarify criteria for adding a DNS provider to the list and also whether any that I've listed should be removed.
Mikaela (Migrated from github.com) requested changes 2019-08-05 10:40:56 +00:00
Mikaela (Migrated from github.com) left a comment

I love it, but have just a few change suggestions

I love it, but have just a few change suggestions
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-05 10:15:55 +00:00

But it will give you a better privacy.

In the future hopefully, but currently the sites you access get leaked by IP address and SNI. I think a better wording would be:

But it will prevent DNS hijacking

another benefit is that it could make tracking your activity by a LAN watcher a bit more difficult, but I don't know what is the state of the tools that monitor SNI and IP addresses connected to.

> But it will give you a better privacy. In the future hopefully, but currently the sites you access get leaked by IP address and SNI. I think a better wording would be: > But it will prevent DNS hijacking another benefit is that it could make tracking your activity by a LAN watcher a bit more difficult, but I don't know what is the state of the tools that monitor SNI and IP addresses connected to.
Mikaela (Migrated from github.com) commented 2019-08-05 10:22:23 +00:00

I would prefer saying ? or unknown or U/K instead of N/A which I think gives the wrong impression.

I would prefer saying `?` or `unknown` or `U/K` instead of `N/A` which I think gives the wrong impression.
Mikaela (Migrated from github.com) commented 2019-08-05 10:27:08 +00:00

Another note, as you seem to list IPv4 and IPv6, it should be noted that those generally aren't encrypted if people happen to add them.

Another note, as you seem to list IPv4 and IPv6, it should be noted that those generally aren't encrypted if people happen to add them.
Mikaela (Migrated from github.com) commented 2019-08-05 10:29:08 +00:00

Note that their "insecure" DNS doesn't have DNSSEC either.

Note that their "insecure" DNS doesn't have DNSSEC either.
Mikaela (Migrated from github.com) commented 2019-08-05 10:29:26 +00:00

(see the DNSSEC comment)

(see the DNSSEC comment)
Mikaela (Migrated from github.com) commented 2019-08-05 10:32:35 +00:00

Isn't this also some as with applied privacy or where do you set the border between Y and Some?

I am looking at https://appliedprivacy.net/privacy-policy/ and https://quad9.net/policy/

Isn't this also some as with applied privacy or where do you set the border between Y and Some? I am looking at https://appliedprivacy.net/privacy-policy/ and https://quad9.net/policy/
Mikaela (Migrated from github.com) commented 2019-08-05 10:37:11 +00:00

Could we defiate from the usual "Worth Mentioning" and instead be "Worth Mentioning and additional information"?

Could we defiate from the usual "Worth Mentioning" and instead be "Worth Mentioning and additional information"?
Mikaela (Migrated from github.com) commented 2019-08-05 10:39:51 +00:00

I think the "default" link should be https://support.google.com/android/answer/9089903 (?hl=en to force language if you wish) instead as that blog doesn't even tell where to enable it.

I think the "default" link should be https://support.google.com/android/answer/9089903 (`?hl=en` to force language if you wish) instead as that blog doesn't even tell where to enable it.
Mikaela (Migrated from github.com) reviewed 2019-08-05 10:46:51 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-05 10:46:50 +00:00

Oh and there isn't the note that we cannot verify that providers actually follow their privacy policies?

Don't rely on a "no log" policy.

I guess I was thinking of something more explicit.

~~Oh and there isn't the note that we cannot verify that providers actually follow their privacy policies?~~ > Don't rely on a "no log" policy. I guess I was thinking of something more explicit.
Mikaela commented 2019-08-05 11:03:58 +00:00 (Migrated from github.com)
Copy Link

I think we'll want to clarify criteria for adding a DNS provider to the list and also whether any that I've listed should be removed.

What I am thinking about:

  • supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785
  • preferably doesn't keep logs, but I would say that "some" are fine, but I guess that needs definition as currently we seem to disagree on it (AppliedPrivacy/Quad9)?
  • preferably supports DNSSEC, but in optimal case the user would be validating that locally e.g. with unbound or dnssec-trigger. Whether that works is again a different question as e.g. OpenDNS (at least used to) strips queries by Unbound for DNSSEC validation breaking everything.

The server locations are again a question mark, should they be outside of 14 eyes? But I would argue that location matters with DNS servers as there is the question of speed (which may matter more to average user) and possibly CDN optimization. Then devices (especially phones/tablets) also travel which may be a bonus for anycast, but if I recall correctly OpenNIC is worried about that being centralization.

I think Quad9 currently has the widest anycast network and I wonder if delisting it would send traffic to dns.google or cloudflare-dns.com, but I respect your decision if you think it's better to delist it.

Which actually leads to question, do you think Cloudflare DNS should be listed or is it established as too big by #374 and some comments in #785 ? I am aware that many people in /r/privacytoolsio and possibly elsewhere in the community are using it. And that leads to a question should there be a warning about Cloudflare in addition to Google?

> I think we'll want to clarify criteria for adding a DNS provider to the list and also whether any that I've listed should be removed. What I am thinking about: * supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785 * preferably doesn't keep logs, but I would say that "some" are fine, but I guess that needs definition as currently we seem to disagree on it (AppliedPrivacy/Quad9)? * preferably supports DNSSEC, but in optimal case the user would be validating that locally e.g. with unbound or dnssec-trigger. Whether that works is again a different question as e.g. OpenDNS (at least used to) strips queries by Unbound for DNSSEC validation breaking everything. The server locations are again a question mark, should they be outside of 14 eyes? But I would argue that location matters with DNS servers as there is the question of speed (which may matter more to average user) and possibly CDN optimization. Then devices (especially phones/tablets) also travel which may be a bonus for anycast, but if I recall correctly OpenNIC is worried about that being centralization. I think Quad9 currently has the widest anycast network and I wonder if delisting it would send traffic to `dns.google` or `cloudflare-dns.com`, but I respect your decision if you think it's better to delist it. Which actually leads to question, do you think Cloudflare DNS should be listed or is it established as too big by #374 and some comments in #785 ? I am aware that many people in /r/privacytoolsio and possibly elsewhere in the community are using it. And that leads to a question should there be a warning about Cloudflare in addition to Google?
👍 1
Mikaela (Migrated from github.com) requested changes 2019-08-05 12:58:31 +00:00
Mikaela (Migrated from github.com) left a comment

I remembered ambiguosiity in filtering and wonder if it should be addressed more clearly.

I remembered ambiguosiity in filtering and wonder if it should be addressed more clearly.
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-05 12:53:26 +00:00

Ads, trackers, malicious domains?

Ads, trackers, malicious domains?
Mikaela (Migrated from github.com) commented 2019-08-05 12:56:16 +00:00

" Filtered some ads, trackers, malware", some wildcards domains and international non-ASCII domains which can be a problem.

I don't know how common they are, but I can think of two, I don't know if one of them still exists though, but they are likely more common in different countries.

" Filtered some ads, trackers, malware", some wildcards domains and international non-ASCII domains which can be a problem. * https://github.com/ookangzheng/blahdns#default-blocked-wildcard-domain I don't know how common they are, but I can think of two, I don't know if one of them still exists though, but they are likely more common in different countries.
Mikaela (Migrated from github.com) commented 2019-08-05 12:57:00 +00:00

Malicious domain filtering.

Malicious domain filtering.
Mikaela (Migrated from github.com) commented 2019-08-05 12:57:46 +00:00

Ads depending on server choice? https://github.com/notracking/hosts-blocklists

Ads depending on server choice? https://github.com/notracking/hosts-blocklists
_includes/sections/dns.html
@ -43,0 +59,4 @@
</thead>
<tbody>
<tr>
<td data-value="AdGuard">
Mikaela (Migrated from github.com) commented 2019-08-05 12:52:44 +00:00

I just remember that this should possibly be more explicitly explained in the table, what is being filtered?

I just remember that this should possibly be more explicitly explained in the table, what is being filtered?
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:30:13 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:30:13 +00:00

But it will prevent DNS hijacking

Good point, I stole that alert from the VPN page 😅 I can change that to "but it will prevent DNS hijacking and spoofing."

Another note, as you seem to list IPv4 and IPv6, it should be noted that those generally aren't encrypted if people happen to add them.

Good catch; I think since this table is specifically for encrypted DNS I'll remove those from being included in the protocols.

I guess I was thinking of something more explicit.

I'm wondering if adding something like "We also cannot verify that the below providers actually follow their own privacy policies so use caution." is really needed? Wouldn't this apply then to most everything then? I'm not sure...

> But it will prevent DNS hijacking Good point, I stole that alert from the VPN page :sweat_smile: I can change that to "but it will prevent DNS hijacking and spoofing." > Another note, as you seem to list IPv4 and IPv6, it should be noted that those generally aren't encrypted if people happen to add them. Good catch; I think since this table is specifically for encrypted DNS I'll remove those from being included in the protocols. > I guess I was thinking of something more explicit. I'm wondering if adding something like "We also cannot verify that the below providers actually follow their own privacy policies so use caution." is really needed? Wouldn't this apply then to most everything then? I'm not sure...
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:36:35 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:36:35 +00:00

What about this:

Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking and spoofing, and make your DNS queries harder to share with third parties.

We could also add to it a disclaimer at privacy policy validation but I'm not sure what the right wording would be at the moment.

What about this: > Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking and spoofing, and make your DNS queries harder to share with third parties. We could also add to it a disclaimer at privacy policy validation but I'm not sure what the right wording would be at the moment.
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:41:17 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:41:17 +00:00

Gotcha; ok, removed since it doesn't really make sense to include it in this table.

Gotcha; ok, removed since it doesn't really make sense to include it in this table.
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:41:53 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:41:53 +00:00

Good callout; I'll go with ? unless someone feels stronger about another method 😄

Good callout; I'll go with `?` unless someone feels stronger about another method :smile:
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:48:05 +00:00
_includes/sections/dns.html
@ -43,0 +59,4 @@
</thead>
<tbody>
<tr>
<td data-value="AdGuard">
nitrohorse (Migrated from github.com) commented 2019-08-06 04:48:05 +00:00

Good catch! Okay, will update to "Ads, trackers, malicious domains" rather than a boolean.

Good catch! Okay, will update to "Ads, trackers, malicious domains" rather than a boolean.
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:49:43 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:49:43 +00:00

Good catch! We can add a warning tooltip for this.

Good catch! We can add a warning tooltip for this.
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:56:07 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:56:07 +00:00

Good catch, you're right!

Good catch, you're right!
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:56:58 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:56:57 +00:00

Nice, thanks!

Nice, thanks!
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:59:00 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:59:00 +00:00

You're right; will update to "some" for consistency.

You're right; will update to "some" for consistency.
nitrohorse (Migrated from github.com) reviewed 2019-08-06 04:59:15 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 04:59:15 +00:00

Updated!

Updated!
nitrohorse commented 2019-08-06 05:30:40 +00:00 (Migrated from github.com)
Copy Link

What I am thinking about:

  • supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785

That makes sense; it would also disqualify UncensoredDNS since they only support DoT.

  • preferably doesn't keep logs, but I would say that "some" are fine, but I guess that needs definition as currently we seem to disagree on it (AppliedPrivacy/Quad9)?

Yeah, I agree that "some" is fine in certain cases like Applied Privacy and Quad9. Based on their polices, Applied Privacy and Q9 both log and aggregate metrics based primarily on counts and not IP address (which they treat as PII).

  • preferably supports DNSSEC, but in optimal case the user would be validating that locally e.g. with unbound or dnssec-trigger. Whether that works is again a different question as e.g. OpenDNS (at least used to) strips queries by Unbound for DNSSEC validation breaking everything.

Good callout. AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think, while both Cloudflare and Google provide DNSSEC, OpenDNS currently does not. So I guess in AdGuard's case it's "partial" DNSSEC support since theoretically a third of queries wouldn't be validated? This was also mentioned in a Reddit thread which AdGuard responded as:

This is, in fact, a valid concern. We will consider removing OpenDNS from the list of our upstream servers. Thank you for the suggestion.

Interestingly, a product manager from OpenDNS also replied on that thread:

I can confirm that we are working on partial DNSSEC support...rather than give up the filtering that makes our DNS resolvers unique, we've chosen to limit DNSSEC validation to upstream queries in order to provide data authenticity for data received from authorities, and then continue to support DNSCrypt as the means to provide data authenticity and authentication for clients connecting to us.

If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial."

The server locations are again a question mark, should they be outside of 14 eyes? But I would argue that location matters with DNS servers as there is the question of speed (which may matter more to average user) and possibly CDN optimization. Then devices (especially phones/tablets) also travel which may be a bonus for anycast, but if I recall correctly OpenNIC is worried about that being centralization.
I think Quad9 currently has the widest anycast network and I wonder if delisting it would send traffic to dns.google or cloudflare-dns.com, but I respect your decision if you think it's better to delist it.

I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare.

Which actually leads to question, do you think Cloudflare DNS should be listed or is it established as too big by #374 and some comments in #785 ? I am aware that many people in /r/privacytoolsio and possibly elsewhere in the community are using it.

From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 and Cloudflare (especially with Mozilla partnering with CF) (and maybe even nextdns). We need to decide where the balance and compromise is. I see value in including these US-based providers but understand if PTIO as a whole would rather have a minimum "outside of the US" rule.

And that leads to a question should there be a warning about Cloudflare in addition to Google?

I think regardless of including CF or not, we could add a snippet about Google in the top warning banner?

...If you are currently using Google or your ISP's DNS resolver, you should pick an alternative here.

> What I am thinking about: > > * supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785 That makes sense; it would also disqualify [UncensoredDNS](https://blog.uncensoreddns.org/) since they only support DoT. > * preferably doesn't keep logs, but I would say that "some" are fine, but I guess that needs definition as currently we seem to disagree on it (AppliedPrivacy/Quad9)? Yeah, I agree that "some" is fine in certain cases like Applied Privacy and Quad9. Based on their polices, Applied Privacy and Q9 both log and aggregate metrics based primarily on counts and not IP address (which they treat as PII). > * preferably supports DNSSEC, but in optimal case the user would be validating that locally e.g. with unbound or dnssec-trigger. Whether that works is again a different question as e.g. OpenDNS (at least used to) strips queries by Unbound for DNSSEC validation breaking everything. Good callout. AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think, while both Cloudflare and Google provide DNSSEC, OpenDNS currently does not. So I guess in AdGuard's case it's "partial" DNSSEC support since theoretically a third of queries wouldn't be validated? This was also mentioned in a [Reddit thread](https://www.reddit.com/r/Adguard/comments/bbb9md/adguard_dns_doesnt_validate_dnssec_signatures/) which AdGuard responded as: >> This is, in fact, a valid concern. We will consider removing OpenDNS from the list of our upstream servers. Thank you for the suggestion. Interestingly, a product manager from OpenDNS [also replied on that thread](https://www.reddit.com/r/Adguard/comments/bbb9md/adguard_dns_doesnt_validate_dnssec_signatures/em3hozo/): >> I can confirm that we are working on partial DNSSEC support...rather than give up the filtering that makes our DNS resolvers unique, we've chosen to limit DNSSEC validation to upstream queries in order to provide data authenticity for data received from authorities, and then continue to support DNSCrypt as the means to provide data authenticity and authentication for clients connecting to us. If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial." > The server locations are again a question mark, should they be outside of 14 eyes? But I would argue that location matters with DNS servers as there is the question of speed (which may matter more to average user) and possibly CDN optimization. Then devices (especially phones/tablets) also travel which may be a bonus for anycast, but if I recall correctly OpenNIC is worried about that being centralization. > I think Quad9 currently has the widest anycast network and I wonder if delisting it would send traffic to `dns.google` or `cloudflare-dns.com`, but I respect your decision if you think it's better to delist it. I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare. > Which actually leads to question, do you think Cloudflare DNS should be listed or is it established as too big by #374 and some comments in #785 ? I am aware that many people in /r/privacytoolsio and possibly elsewhere in the community are using it. From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 _and_ Cloudflare (especially with [Mozilla partnering with CF](https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/)) (and maybe even [nextdns](https://www.nextdns.io/privacy)). We need to decide where the balance and compromise is. I see value in including these US-based providers but understand if PTIO as a whole would rather have a minimum "outside of the US" rule. > And that leads to a question should there be a warning about Cloudflare in addition to Google? I think regardless of including CF or not, we could add a snippet about Google in the top warning banner? > ...If you are currently using Google or your ISP's DNS resolver, you should pick an alternative here.
Mikaela (Migrated from github.com) reviewed 2019-08-06 09:25:51 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-06 09:25:50 +00:00

Sounds good, but I would add third party or something in front of spoofing as that is what the filtering DNS providers do and you have to trust them unless the zone is DNSSEC signed and you run a local DNSSEC validator (which I don't think is done by anyone on Android/iOS while it's somewhat rare also on desktops).

Sounds good, but I would add third party or something in front of spoofing as that is what the filtering DNS providers do and you have to trust them unless the zone is DNSSEC signed and you run a local DNSSEC validator (which I don't think is done by anyone on Android/iOS while it's somewhat rare also on desktops).
Mikaela commented 2019-08-06 09:40:26 +00:00 (Migrated from github.com)
Copy Link

supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785

That makes sense; it would also disqualify UncensoredDNS since they only support DoT.

Sorry, I was thinking / more of as "or" here and I would be fine with UncensoredDNS as the readers are going to see clearly that it's DoT-only and not consider it for their DoH requirement, but might take it for Android, thanks to your table :)

AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think

What is the source for this? I find it worrying as I would expect DNS providers to perform name resolution by themselves querying the root servers when they don't know which are the authoritative nameservers. Was the word recurse?

If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial."

I guess this is the best solution for now

I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare.

I don't think it's a good solution, because there are a lot of people in the US who also need DNS (who doesn't need DNS?) and using foreign resolvers could lead to slower speeds and content delivery happening from foreign instead of local datacenters and causing slower speeds.

From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 and Cloudflare (especially with Mozilla partnering with CF) (and maybe even nextdns).

I guess we have to include them in that case. Can we at least have a warning "a big part of the internet is in Cloudflare's networks and it's a problem considering decentralization" or similar?

I think regardless of including CF or not, we could add a snippet about Google in the top warning banner?

👍 I am not entirely sure on "your ISP" part as I think they are more reliable in some countries, but then again they don't currently support DoT/DoH, but I hope in the future they will and if they have a good privacy policy, I guess we can include them or link elsewhere for comparsion of them assuming they are going to only serve their own customers?

>> supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785 > That makes sense; it would also disqualify UncensoredDNS since they only support DoT. Sorry, I was thinking / more of as "or" here and I would be fine with UncensoredDNS as the readers are going to see clearly that it's DoT-only and not consider it for their DoH requirement, but might take it for Android, thanks to your table :) > AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think What is the source for this? I find it worrying as I would expect DNS providers to perform name resolution by themselves querying the root servers when they don't know which are the authoritative nameservers. Was the word recurse? > If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial." I guess this is the best solution for now > I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare. I don't think it's a good solution, because there are a lot of people in the US who also need DNS (who doesn't need DNS?) and using foreign resolvers could lead to slower speeds and content delivery happening from foreign instead of local datacenters and causing slower speeds. > From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 and Cloudflare (especially with Mozilla partnering with CF) (and maybe even nextdns). I guess we have to include them in that case. Can we at least have a warning "a big part of the internet is in Cloudflare's networks and it's a problem considering decentralization" or similar? > I think regardless of including CF or not, we could add a snippet about Google in the top warning banner? :+1: I am not entirely sure on "your ISP" part as I think they are more reliable in some countries, but then again they don't currently support DoT/DoH, but I hope in the future they will and if they have a good privacy policy, I guess we can include them or link elsewhere for comparsion of them assuming they are going to only serve their own customers?
👍 1
Mikaela (Migrated from github.com) requested changes 2019-08-06 09:47:44 +00:00
Mikaela (Migrated from github.com) left a comment

Sorry, I forgot to look at the code and preview after my previous comments, I think this will be great 👍

However reading the table I spotted that DNSCrypt is twice misspelled as DNScrypt which makes it seem a bit unclear to me.

Sorry, I forgot to look at the code and preview after my previous comments, I think this will be great :+1: However reading the table I spotted that `DNSCrypt` is twice misspelled as `DNScrypt` which makes it seem a bit unclear to me.
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-06 09:45:42 +00:00

Inconsistency, some parts say DNSCrypt some DNScrypt (note the c / C), DNSCrypt appears to be the upstream spelling judging by https://dnscrypt.info/

Inconsistency, some parts say DNSCrypt some DNScrypt (note the `c` / `C`), DNSCrypt appears to be the upstream spelling judging by https://dnscrypt.info/
Mikaela (Migrated from github.com) commented 2019-08-06 09:46:15 +00:00

Inconsistency, some parts say DNSCrypt some DNScrypt (note the c / C), DNSCrypt appears to be the upstream spelling judging by https://dnscrypt.info/

Inconsistency, some parts say DNSCrypt some DNScrypt (note the `c` / `C`), DNSCrypt appears to be the upstream spelling judging by https://dnscrypt.info/
Mikaela (Migrated from github.com) reviewed 2019-08-06 09:57:05 +00:00
_includes/sections/dns.html
@ -43,0 +56,4 @@
<th data-sortable="true">Filtering</th>
<th data-sortable="true">Source Code</th>
</tr>
</thead>
Mikaela (Migrated from github.com) commented 2019-08-06 09:57:05 +00:00

Now I also realized that we don't expand what do DoH/DoT/DNSCrypt mean? Maybe they should have a short paragraph in the additional information in the bottom.

DNS over TLS (DoT) is a <explain https://en.wikipedia.org/wiki/Request_for_Comments_(identifier) here or just say RFC?> for encrypted DNS on a dedicated port 853, DNS over HTTPS (DoH) is similar, but uses HTTPS instead being indistinguishable from "normal" HTTPS traffic on port 443 and DNSCrypt is an older regardless robust method of encrypting DNS.

Would we also need to give examples on what supports what? I guess the page already mentions DNSCrypt-proxy (possibly also as supporting DoH which it does) and Android 9 supports TLS, but would Firefox need to be mentioned or is it enough for #785 to refer to the table? I think it may be a non-issue.

Sorry, my head isn't still working that well and I am not sure if this works as a base for you to improve.

Now I also realized that we don't expand what do DoH/DoT/DNSCrypt mean? Maybe they should have a short paragraph in the additional information in the bottom. > DNS over TLS (DoT) is a \<explain https://en.wikipedia.org/wiki/Request_for_Comments_(identifier) here or just say RFC?\> for encrypted DNS on a dedicated port 853, DNS over HTTPS (DoH) is similar, but uses HTTPS instead being indistinguishable from "normal" HTTPS traffic on port 443 and DNSCrypt is an older regardless robust method of encrypting DNS. Would we also need to give examples on what supports what? I guess the page already mentions DNSCrypt-proxy (possibly also as supporting DoH which it does) and Android 9 supports TLS, but would Firefox need to be mentioned or is it enough for #785 to refer to the table? I think it may be a non-issue. <small>Sorry, my head isn't still working that well and I am not sure if this works as a base for you to improve.</small>
Mikaela (Migrated from github.com) reviewed 2019-08-06 10:02:48 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-06 10:02:48 +00:00

Sorry, another small nitpick, but is there a particular reason for old.reddit.com privacy-wise or are you one of those people who are used to it and want to resist the change? I am just thinking on how the new interface is better on small screens (phones)?

Sorry, another small nitpick, but is there a particular reason for old.reddit.com privacy-wise or are you one of those people who are used to it and want to resist the change? I am just thinking on how the new interface is better on small screens (phones)?
Mikaela commented 2019-08-06 12:15:19 +00:00 (Migrated from github.com)
Copy Link

Feedback from friends:

I find the term "DNS provider" slightly confusing as it's rather overloaded. Not sure if I can come up with a better one that doesn't sound like technical mumbo-jumbo.

I really think there ought to be a paragraph about how DNS resolvers are different service from authoritative DNS hosts. And perhaps something about setting up your own as that's really easy, especially if you have *wrt device for a router already.

We have issues for the later already, #1055 and privacytoolsio/guides.privacytools.io#9

The sorting is weird, if you sort by Protocol, it's alphabetic and DoH, DoT should rank higher than just DoH. When sorted by filtering, ? should rank the same as N.

I don't know if that is easy to fix?

Edit:

with the protocols you could maybe get the len() of the CSV
and then do alpha as a secondary sort

Feedback from friends: * * * * * > I find the term "DNS provider" slightly confusing as it's rather overloaded. Not sure if I can come up with a better one that doesn't sound like technical mumbo-jumbo. > > I really think there ought to be a paragraph about how DNS resolvers are different service from authoritative DNS hosts. And perhaps something about setting up your own as that's really easy, especially if you have *wrt device for a router already. We have issues for the later already, #1055 and privacytoolsio/guides.privacytools.io#9 * * * * * *The sorting is weird, if you sort by Protocol, it's alphabetic and DoH, DoT should rank higher than just DoH. When sorted by filtering, ? should rank the same as N.* I don't know if that is easy to fix? Edit: > with the protocols you could maybe get the len() of the CSV > and then do alpha as a secondary sort
👍 1 👀 1
nitrohorse (Migrated from github.com) reviewed 2019-08-06 23:39:00 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-06 23:39:00 +00:00

https://i.reddit.com has the least amount of trackers with ‘old’ next and then the new UI having the most. “i” looks horrible on desktops so maybe we just stick with the new UI since it’s more user-friendly to all devices?

https://i.reddit.com has the least amount of trackers with ‘old’ next and then the new UI having the most. “i” looks horrible on desktops so maybe we just stick with the new UI since it’s more user-friendly to all devices?
nitrohorse commented 2019-08-07 01:20:14 +00:00 (Migrated from github.com)
Copy Link

supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785

That makes sense; it would also disqualify UncensoredDNS since they only support DoT.

Sorry, I was thinking / more of as "or" here and I would be fine with UncensoredDNS as the readers are going to see clearly that it's DoT-only and not consider it for their DoH requirement, but might take it for Android, thanks to your table :)

Ah, yeah, that makes sense 👍

AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think

What is the source for this? I find it worrying as I would expect DNS providers to perform name resolution by themselves querying the root servers when they don't know which are the authoritative nameservers. Was the word recurse?

If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial."

I guess this is the best solution for now

Huh, this is interesting. From some testing a month or two ago DNS results would return resolvers for Cloudflare/Google/OpenDNS which AdGuard after filtering, forwards requests to. But checking now, it looks like that isn't happening anymore; I'm connecting to a single Anycast resolver hosted on Vultr with DNSSEC support. I also can't find any official documentation in their FAQ regarding their upstream providers, so I'm inclined to change their DNSSEC value to Y and remove the warning.

I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare.

I don't think it's a good solution, because there are a lot of people in the US who also need DNS (who doesn't need DNS?) and using foreign resolvers could lead to slower speeds and content delivery happening from foreign instead of local datacenters and causing slower speeds.

Yeah, I agree with you; I think there's value in removing the location criteria for DNS.

From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 and Cloudflare (especially with Mozilla partnering with CF) (and maybe even nextdns).

I guess we have to include them in that case. Can we at least have a warning "a big part of the internet is in Cloudflare's networks and it's a problem considering decentralization" or similar?

Yeah, I think that'd be good. I can add a new row for Cloudflare with a warning. What do you think of nextdns? It's fairly new, but arguably on par with a "hobby project" at the moment I guess which wouldn't disqualify it in that regard. It's unique though in that it markets itself as "Cloudflare + Pi-hole capabilities."

I think regardless of including CF or not, we could add a snippet about Google in the top warning banner?

+1 I am not entirely sure on "your ISP" part as I think they are more reliable in some countries, but then again they don't currently support DoT/DoH, but I hope in the future they will and if they have a good privacy policy, I guess we can include them or link elsewhere for comparsion of them assuming they are going to only serve their own customers?

Yeah, good callout, I can remove the ISP part unless someone things otherwise.

> > > supports encrypted DNS (DoT/DoH/DNSCrypt), especially DoH as required by #785 > > > That makes sense; it would also disqualify UncensoredDNS since they only support DoT. > > Sorry, I was thinking / more of as "or" here and I would be fine with UncensoredDNS as the readers are going to see clearly that it's DoT-only and not consider it for their DoH requirement, but might take it for Android, thanks to your table :) Ah, yeah, that makes sense :+1: > > AdGuard relies on Cloudflare, Google, and OpenDNS as upstream DNS providers, I think > > What is the source for this? I find it worrying as I would expect DNS providers to perform name resolution by themselves querying the root servers when they don't know which are the authoritative nameservers. Was the word recurse? > > If we still want to include AdGuard, I've added a tooltip to that table cell and updated the value to "Partial." > > I guess this is the best solution for now Huh, this is interesting. From some testing a month or two ago DNS results would return resolvers for Cloudflare/Google/OpenDNS which AdGuard after filtering, forwards requests to. But checking now, it looks like that isn't happening anymore; I'm connecting to a single Anycast resolver hosted on Vultr with DNSSEC support. I also can't find any official documentation in their [FAQ](https://kb.adguard.com/en/dns) regarding their upstream providers, so I'm inclined to change their DNSSEC value to `Y` and remove the warning. > > I wonder if rather than 'outside of 14 eyes' we'd go with what the VPN providers table uses, "outside of the US"? That would disqualify Quad9 though and others like Cloudflare. > > I don't think it's a good solution, because there are a lot of people in the US who also need DNS (who doesn't need DNS?) and using foreign resolvers could lead to slower speeds and content delivery happening from foreign instead of local datacenters and causing slower speeds. Yeah, I agree with you; I think there's value in removing the location criteria for DNS. > > From my perspective, I think if our criteria would allow "inside" the US (essentially no location criteria), we would be inclined to include Quad9 and Cloudflare (especially with Mozilla partnering with CF) (and maybe even nextdns). > > I guess we have to include them in that case. Can we at least have a warning "a big part of the internet is in Cloudflare's networks and it's a problem considering decentralization" or similar? Yeah, I think that'd be good. I can add a new row for Cloudflare with a warning. What do you think of [nextdns](https://www.nextdns.io/)? It's fairly new, but arguably on par with a "hobby project" at the moment I guess which wouldn't disqualify it in that regard. It's unique though in that it markets itself as "Cloudflare + Pi-hole capabilities." > > I think regardless of including CF or not, we could add a snippet about Google in the top warning banner? > > +1 I am not entirely sure on "your ISP" part as I think they are more reliable in some countries, but then again they don't currently support DoT/DoH, but I hope in the future they will and if they have a good privacy policy, I guess we can include them or link elsewhere for comparsion of them assuming they are going to only serve their own customers? Yeah, good callout, I can remove the ISP part unless someone things otherwise.
👍 1
nitrohorse (Migrated from github.com) reviewed 2019-08-07 01:24:59 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 01:24:59 +00:00

I think since there doesn't appear to be partial support but rather full support for DNSSEC now we can just remove this.

I think since there doesn't appear to be partial support but rather full support for DNSSEC now we can just remove this.
nitrohorse (Migrated from github.com) reviewed 2019-08-07 05:41:16 +00:00
_includes/sections/dns.html
@ -43,0 +56,4 @@
<th data-sortable="true">Filtering</th>
<th data-sortable="true">Source Code</th>
</tr>
</thead>
nitrohorse (Migrated from github.com) commented 2019-08-07 05:41:16 +00:00

Great callout -- what do you think about something like this for the terms (viewable also from the preview deployment: https://deploy-preview-1097--privacytools-io.netlify.com/)

terms

And something like this for mentioning clients?

worth

I think we should call out Firefox supporting DoH but am wondering how you think something like this would be.

Great callout -- what do you think about something like this for the terms (viewable also from the preview deployment: https://deploy-preview-1097--privacytools-io.netlify.com/) ![terms](https://user-images.githubusercontent.com/1514352/62597507-d0ac2c00-b8d5-11e9-9e2b-502db4ca7daa.png) And something like this for mentioning clients? ![worth](https://user-images.githubusercontent.com/1514352/62597535-e588bf80-b8d5-11e9-931e-adc4e0ee05e5.png) I think we should call out Firefox supporting DoH but am wondering how you think something like this would be.
nitrohorse (Migrated from github.com) reviewed 2019-08-07 05:43:53 +00:00
_includes/sections/dns.html
@ -43,0 +111,4 @@
<td>Anycast (based in <span class="flag-icon flag-icon-us"></span> US)</td>
<td>
<a data-toggle="tooltip" data-placement="bottom" data-original-title="https://www.cloudflare.com/privacypolicy/" href="https://www.cloudflare.com/privacypolicy/">
<img alt="WWW" src="/assets/img/layout/www.png" width="35" height="35">
nitrohorse (Migrated from github.com) commented 2019-08-07 05:43:53 +00:00

@Mikaela you'll notice I've added CF + nextdns for discussion here.

@Mikaela you'll notice I've added CF + nextdns for discussion here.
nitrohorse commented 2019-08-07 06:13:32 +00:00 (Migrated from github.com)
Copy Link

Feedback from friends:

I find the term "DNS provider" slightly confusing as it's rather overloaded. Not sure if I can come up with a better one that doesn't sound like technical mumbo-jumbo.
I really think there ought to be a paragraph about how DNS resolvers are different service from authoritative DNS hosts. And perhaps something about setting up your own as that's really easy, especially if you have *wrt device for a router already.

We have issues for the later already, #1055 and privacytoolsIO/guides.privacytools.io#9

Hmm, that's a good point... let's save that for later; we should address that though.

The sorting is weird, if you sort by Protocol, it's alphabetic and DoH, DoT should rank higher than just DoH. When sorted by filtering, ? should rank the same as N.

Okay, I resolved the ?/N oddity so they're treated the same. I can't figure out right now how to custom sort by length and then alphanumerically but I have a hack in place where I give only "DoT" values, "DoH" as the sort value... 😓

> Feedback from friends: > > > I find the term "DNS provider" slightly confusing as it's rather overloaded. Not sure if I can come up with a better one that doesn't sound like technical mumbo-jumbo. > > I really think there ought to be a paragraph about how DNS resolvers are different service from authoritative DNS hosts. And perhaps something about setting up your own as that's really easy, especially if you have *wrt device for a router already. > > We have issues for the later already, #1055 and [privacytoolsIO/guides.privacytools.io#9](https://github.com/privacytoolsIO/guides.privacytools.io/issues/9) Hmm, that's a good point... let's save that for later; we should address that though. > > _The sorting is weird, if you sort by Protocol, it's alphabetic and DoH, DoT should rank higher than just DoH. When sorted by filtering, ? should rank the same as N._ > Okay, I resolved the `?/N` oddity so they're treated the same. I can't figure out right now how to custom sort by length and then alphanumerically but I have a hack in place where I give only "DoT" values, _"DoH"_ as the sort value... :sweat:
❤️ 1
Mikaela (Migrated from github.com) reviewed 2019-08-07 06:52:56 +00:00
Mikaela (Migrated from github.com) left a comment

I don't have hard comments on the rest.

I don't have hard comments on the rest.
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 06:33:14 +00:00 
          <a href="https://cloudflare-dns.com/dns/">Cloudflare</a>

1.1.1.1 is IPv4-only and I don't think we should hardcode it as there are already some IPv6-only networks in the world even if there are transition mechanisms.

```suggestion <a href="https://cloudflare-dns.com/dns/">Cloudflare</a> ``` 1.1.1.1 is IPv4-only and I don't think we should hardcode it as there are already some IPv6-only networks in the world even if there are transition mechanisms.
Mikaela (Migrated from github.com) commented 2019-08-07 06:33:33 +00:00

(now I also finally learned to make suggestions)

(now I also finally learned to make suggestions)
Mikaela (Migrated from github.com) commented 2019-08-07 06:44:00 +00:00

But where do they actually document the DoT and DoH addresses?

But where do they actually document the DoT and DoH addresses?
Mikaela (Migrated from github.com) commented 2019-08-07 06:47:20 +00:00

Is it also enabled by default already?

Is it also enabled by default already?
_includes/sections/dns.html
@ -43,0 +56,4 @@
<th data-sortable="true">Filtering</th>
<th data-sortable="true">Source Code</th>
</tr>
</thead>
Mikaela (Migrated from github.com) commented 2019-08-07 06:30:23 +00:00

👍 looks good

:+1: looks good
_includes/sections/dns.html
@ -43,0 +191,4 @@
<td>Anycast (based in <span class="flag-icon flag-icon-us"></span> US)</td>
<td>
<a data-toggle="tooltip" data-placement="bottom" data-original-title="https://www.nextdns.io/privacy" href="https://www.nextdns.io/privacy">
<img alt="WWW" src="/assets/img/layout/www.png" width="35" height="35">
Mikaela (Migrated from github.com) commented 2019-08-07 06:51:01 +00:00

I have a small problem with them, but apparently my problem doesn't even apply with encrypted DNS, so I have no problem :)

I have a small problem with them, but apparently my problem doesn't even apply with encrypted DNS, so I have no problem :) * https://forum.privacytools.io/t/secure-dns-alternative-nextdns-io/691/4?u=mikaela
nitrohorse (Migrated from github.com) reviewed 2019-08-07 06:55:03 +00:00
_includes/sections/dns.html
@ -43,0 +111,4 @@
<td>Anycast (based in <span class="flag-icon flag-icon-us"></span> US)</td>
<td>
<a data-toggle="tooltip" data-placement="bottom" data-original-title="https://www.cloudflare.com/privacypolicy/" href="https://www.cloudflare.com/privacypolicy/">
<img alt="WWW" src="/assets/img/layout/www.png" width="35" height="35">
nitrohorse (Migrated from github.com) commented 2019-08-07 06:55:03 +00:00

Todo: add warning

Todo: add warning
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:15:36 +00:00
_includes/sections/dns.html
@ -43,0 +111,4 @@
<td>Anycast (based in <span class="flag-icon flag-icon-us"></span> US)</td>
<td>
<a data-toggle="tooltip" data-placement="bottom" data-original-title="https://www.cloudflare.com/privacypolicy/" href="https://www.cloudflare.com/privacypolicy/">
<img alt="WWW" src="/assets/img/layout/www.png" width="35" height="35">
nitrohorse (Migrated from github.com) commented 2019-08-07 07:15:35 +00:00

Updated and linked to https://codeberg.org/crimeflare/cloudflare-tor/ which looks more up-to-date compared to https://notabug.org/themusicgod1/cloudflare-tor/src/master.

Updated and linked to https://codeberg.org/crimeflare/cloudflare-tor/ which looks more up-to-date compared to https://notabug.org/themusicgod1/cloudflare-tor/src/master.
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:18:00 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 07:18:00 +00:00

Hmm... I'm not 100% sure but I think not yet -- they're still conducting studies: https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/

Hmm... I'm not 100% sure but I think not yet -- they're still conducting studies: https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-https-doh-update-detecting-managed-networks-and-user-choice/
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:18:28 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 07:18:28 +00:00

Hmm good point! Need to find that...

Hmm good point! Need to find that...
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:20:20 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 07:20:20 +00:00

I guess both are documented here? https://developers.cloudflare.com/1.1.1.1/dns-over-https/

I guess both are documented here? https://developers.cloudflare.com/1.1.1.1/dns-over-https/
Mikaela (Migrated from github.com) approved these changes 2019-08-07 07:20:25 +00:00
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:21:42 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 07:21:42 +00:00

You think that should be added here, that it's not enabled by default right now?

You think that should be added here, that it's not enabled by default right now?
nitrohorse (Migrated from github.com) reviewed 2019-08-07 07:32:56 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 07:32:55 +00:00

@Mikaela would you be able to double-check that they don’t support QNAME Min?

@Mikaela would you be able to double-check that they don’t support QNAME Min?
Mikaela (Migrated from github.com) reviewed 2019-08-07 07:41:09 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 07:41:09 +00:00

Not as easily as the previous one as it's not listed in DNSCrypt-proxy, but I can reconfigure my Unbound, I guess.

Not as easily as the previous one as it's not listed in DNSCrypt-proxy, but I can reconfigure my Unbound, I guess.
Mikaela (Migrated from github.com) reviewed 2019-08-07 07:47:06 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 07:47:06 +00:00

I receive

└┌(%:~)┌- dig +short txt qnamemintest.internet.nl @127.0.0.1
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("

when I configure Unbound with

# NOTE! Requires Unbound 1.7.3 or newer! Debian 9 has 1.6.0
# cp of forwards.conf updated to DNS over TLS time with  a lot took from
# https://www.ctrl.blog/entry/unbound-tls-forwarding.html

server:
  # Debian ca-certificates location
  tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
  # ctrl.blog says this is the Fedora location
  #tls-cert-bundle: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# Forward queries to
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 91.239.100.100@853#anycast.censurfridns.dk
    forward-addr: 2001:67c:28a4::@853#anycast.censurfridns.dk

and have commented qname-minimization.conf

server:
    # Send minimum amount of information to upstream servers to enhance
    # privacy. Only sends minimum required labels of the QNAME and sets
    # QTYPE to NS when possible.

    # See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for
    # details.

    #qname-minimisation: yes
I receive ``` └┌(%:~)┌- dig +short txt qnamemintest.internet.nl @127.0.0.1 a.b.qnamemin-test.internet.nl. "NO - QNAME minimisation is NOT enabled on your resolver :(" ``` when I configure Unbound with ``` # NOTE! Requires Unbound 1.7.3 or newer! Debian 9 has 1.6.0 # cp of forwards.conf updated to DNS over TLS time with a lot took from # https://www.ctrl.blog/entry/unbound-tls-forwarding.html server: # Debian ca-certificates location tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt # ctrl.blog says this is the Fedora location #tls-cert-bundle: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # Forward queries to forward-zone: name: "." forward-tls-upstream: yes forward-addr: 91.239.100.100@853#anycast.censurfridns.dk forward-addr: 2001:67c:28a4::@853#anycast.censurfridns.dk ``` and have commented qname-minimization.conf ``` server: # Send minimum amount of information to upstream servers to enhance # privacy. Only sends minimum required labels of the QNAME and sets # QTYPE to NS when possible. # See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for # details. #qname-minimisation: yes ```
Mikaela (Migrated from github.com) reviewed 2019-08-07 07:49:11 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 07:49:11 +00:00

wait, that is entirely different DNS provider I just tested? Let's try this again

wait, that is entirely different DNS provider I just tested? Let's try this again
Mikaela (Migrated from github.com) reviewed 2019-08-07 07:50:28 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 07:50:28 +00:00

I forgot that the studies exist and I am not sure, maybe mention that Mozilla is testing it with small subset of users?

I forgot that the studies exist and I am not sure, maybe mention that Mozilla is testing it with small subset of users?
Mikaela (Migrated from github.com) reviewed 2019-08-07 07:51:33 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 07:51:33 +00:00

No, it's the same DNS provider, but they just confusingly use different domain for their anycast DoT than website.

No, it's the same DNS provider, but they just confusingly use different domain for their anycast DoT than website.
Mikaela commented 2019-08-07 08:56:17 +00:00 (Migrated from github.com)
Copy Link

I am not sure if the source_code file needs updating in this case as you already linked sources everywhere.

https://deploy-preview-1097--privacytools-io.netlify.com/classic/#icanndns also seems to work directly as it wasn't a new page that was added.

I am not sure if the source_code file needs updating in this case as you already linked sources everywhere. https://deploy-preview-1097--privacytools-io.netlify.com/classic/#icanndns also seems to work directly as it wasn't a new page that was added.
Mikaela (Migrated from github.com) reviewed 2019-08-07 09:16:37 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-07 09:16:37 +00:00 
          <a href="https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/">Cloudflare</a> <span class="badge badge-warning" data-toggle="tooltip" title="Cloudflare is one of the world's largest networks, and a problem considering anonymity and decentralization."><a href="https://codeberg.org/crimeflare/cloudflare-tor/"><i class="fas fa-exclamation-triangle"></i></a></span>

based on your comment I missed for a page that actually documents where to find DoT/DoH without being so much of an advertisement.

```suggestion <a href="https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/">Cloudflare</a> <span class="badge badge-warning" data-toggle="tooltip" title="Cloudflare is one of the world's largest networks, and a problem considering anonymity and decentralization."><a href="https://codeberg.org/crimeflare/cloudflare-tor/"><i class="fas fa-exclamation-triangle"></i></a></span> ``` based on your comment I missed for a page that actually documents where to find DoT/DoH without being so much of an advertisement.
Mikaela (Migrated from github.com) requested changes 2019-08-07 09:17:49 +00:00
Mikaela (Migrated from github.com) left a comment

to prevent accidental merge befre everything is talked about and @nitrohorse feels confident. I will also set the WIP-do-not-merge-label for him to remove

to prevent accidental merge befre everything is talked about and @nitrohorse feels confident. I will also set the WIP-do-not-merge-label for him to remove
nitrohorse (Migrated from github.com) reviewed 2019-08-07 13:49:56 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-07 13:49:56 +00:00

Thank you!

Thank you!
Mikaela commented 2019-08-07 15:42:16 +00:00 (Migrated from github.com)
Copy Link

#1111 reminded me, what is the difference between an association and non-profit?

#1111 reminded me, what is the difference between an association and non-profit?
nitrohorse commented 2019-08-07 16:26:18 +00:00 (Migrated from github.com)
Copy Link

#1111 reminded me, what is the difference between an association and non-profit?

Yeah, from my understanding in CZ.NIC’s context, it’s not technically a non-profit but rather a formal type of collective? https://en.m.wikipedia.org/wiki/Voluntary_association

> #1111 reminded me, what is the difference between an association and non-profit? Yeah, from my understanding in CZ.NIC’s context, it’s not technically a non-profit but rather a formal type of collective? https://en.m.wikipedia.org/wiki/Voluntary_association
😕 1
nitrohorse (Migrated from github.com) reviewed 2019-08-08 03:59:51 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 03:59:51 +00:00

Hmm what do you think about:

Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking, and make your DNS requests harder to track, filter, and share with third parties. If you are currently using Google as your DNS resolver, you should pick an alternative here.

Hmm what do you think about: > Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. **But it will prevent DNS hijacking, and make your DNS requests harder to track, filter, and share with third parties.** If you are currently using Google as your DNS resolver, you should pick an alternative here.
nitrohorse (Migrated from github.com) reviewed 2019-08-08 04:59:02 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 04:59:02 +00:00

Updated to cloudflare-dns.com/dns 👍

Updated to cloudflare-dns.com/dns :+1:
nitrohorse (Migrated from github.com) reviewed 2019-08-08 05:20:40 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 05:20:40 +00:00

What do you think about:

Firefox comes with built-in DoH support with Cloudflare set as the default resolver, but can be configured to use any DoH resolver. Currently Mozilla is conducting studies before enabling DoH by default for all US-based Firefox users.

What do you think about: > Firefox comes with built-in DoH support with Cloudflare set as the default resolver, but can be configured to use any DoH resolver. Currently Mozilla is conducting studies before enabling DoH by default for all US-based Firefox users.
nitrohorse (Migrated from github.com) reviewed 2019-08-08 05:23:38 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 05:23:38 +00:00

Found their docs:

Found their docs: - DoH: https://developers.cloudflare.com/1.1.1.1/dns-over-https/ - DoT: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/
nitrohorse (Migrated from github.com) reviewed 2019-08-08 05:24:44 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 05:24:44 +00:00

I wonder if https://cloudflare-dns.com/dns/ is good enough to link here? Isn't super helpful though because users have to dig into their docs to find these.

I wonder if https://cloudflare-dns.com/dns/ is good enough to link here? Isn't super helpful though because users have to dig into their docs to find these.
nitrohorse (Migrated from github.com) reviewed 2019-08-08 05:32:36 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 05:32:36 +00:00

Added DNS-over-Tor.

Added [DNS-over-Tor](https://new.blog.cloudflare.com/welcome-hidden-resolver/).
nitrohorse (Migrated from github.com) reviewed 2019-08-08 05:35:57 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-08 05:35:56 +00:00

@Mikaela - now that Cloudflare and the Foundation of Applied Privacy include DNS-over-Tor, (for consistency I changed Applied Privacy's "DNS-over-Onion" to "Tor"), I've added this new term description. Thoughts?

@Mikaela - now that Cloudflare and the Foundation of Applied Privacy include DNS-over-Tor, (for consistency I changed Applied Privacy's "DNS-over-Onion" to "Tor"), I've added this new term description. Thoughts?
Mikaela (Migrated from github.com) reviewed 2019-08-08 08:33:48 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-08 08:33:47 +00:00

I am otherwise fine, but a small issue is that the filtering may be done by the provider and even intentionally if the user is after adblocking.

I am otherwise fine, but a small issue is that the filtering may be done by the provider and even intentionally if the user is after adblocking.
Mikaela (Migrated from github.com) reviewed 2019-08-08 08:39:13 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-08 08:39:13 +00:00

👍 but where does "US-based Firefox users" come from? I don't think I have heard of that criteria before connected to this issue.

Users that do not wish to participate in this study can opt-out by typing “about:studies’ in the navigation bar, looking for an active study titled “Detection Logic for DNS-over-HTTPS”, and disabling it. (Not all users will receive this study, so don’t be alarmed if you can’t find it.) Users may also opt out of participating in any future studies from this page.

As always, we are committed to maintaining a transparent relationship with our users. We believe that DoH significantly improves the privacy of our users. As we move toward a rollout of DoH to all United States-based Firefox users, we intend to provide explicit mechanisms allowing users and local DNS administrators to opt-out.

from your link.

:+1: ~~but where does "US-based Firefox users" come from? I don't think I have heard of that criteria before connected to this issue.~~ > Users that do not wish to participate in this study can opt-out by typing “about:studies’ in the navigation bar, looking for an active study titled “Detection Logic for DNS-over-HTTPS”, and disabling it. (Not all users will receive this study, so don’t be alarmed if you can’t find it.) Users may also opt out of participating in any future studies from this page. > > As always, we are committed to maintaining a transparent relationship with our users. We believe that DoH significantly improves the privacy of our users. As we move toward a rollout of DoH to all United States-based Firefox users, we intend to provide explicit mechanisms allowing users and local DNS administrators to opt-out. from your link.
Mikaela (Migrated from github.com) reviewed 2019-08-08 08:43:38 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-08 08:43:38 +00:00

I don't think it's good enough to link here as they advertise their own app instead of the open source apps we suggest (including Android 9+'s native support) and they don't even tell the addresses. The only link to DoT again is in "how to integrate" section which I think is more aimed at device manufacturers or something in my opinion.

I think it would be OK to link at if we didn't have a focus on encrypted DNS, but the plain DNS makes no sense in my opinion as it could be hijacked, read and everything making it unfit as a privacy tool.

I don't think it's good enough to link here as they advertise their own app instead of the open source apps we suggest (including Android 9+'s native support) and they don't even tell the addresses. The only link to DoT again is in "how to integrate" section which I think is more aimed at device manufacturers or something in my opinion. I think it would be OK to link at if we didn't have a focus on encrypted DNS, but the plain DNS makes no sense in my opinion as it could be hijacked, read and everything making it unfit as a privacy tool.
Mikaela (Migrated from github.com) reviewed 2019-08-08 08:49:46 +00:00
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-08 08:49:45 +00:00

I think Cloudflare and Foundation of Applied Privacy mean different things with it.

For Cloudflare it's a normal DoH resolver which has a valid EV certificate.

For FoAP

This is a TCP (not DoT or DoH) endpoint. Transport level encryption is provided by the onion layer.

I think Firefox at least is not going to accept it as it requires a valid certificate for DoH and only .onions can have a EV certificate, so I wonder if it would be better to not mention DNS-over-Tor at all as it currently seems to be restricted only for bigger players, but I guess it's interesting to follow in case the situation improves in the future.

Do you know what kind of software would take the FoAP link? I know Firefox/TorBrowser are fine with Cloudflare's and dnscrypt-proxy has a support for it.

I think Cloudflare and Foundation of Applied Privacy mean different things with it. For Cloudflare it's a normal DoH resolver which has a valid EV certificate. For FoAP > This is a TCP (not DoT or DoH) endpoint. Transport level encryption is provided by the onion layer. I think Firefox at least is not going to accept it as it requires a valid certificate for DoH and only .onions can have a EV certificate, so I wonder if it would be better to not mention DNS-over-Tor at all as it currently seems to be restricted only for bigger players, but I guess it's interesting to follow in case the situation improves in the future. Do you know what kind of software would take the FoAP link? I know Firefox/TorBrowser are fine with Cloudflare's and dnscrypt-proxy has a support for it.
ghbjklhv1 (Migrated from github.com) reviewed 2019-08-08 21:54:19 +00:00
ghbjklhv1 (Migrated from github.com) left a comment

I understand the initiative, but it doesn't make sense under the current state of DNS.
Here are some notes:

Only 2 support DNS-Over TOR: Only Cloudflare and Foundation for Applied Privacy use TOR.
None use I2p: None of the recommendations use, i2p.
Maybe not a huge issue, but I would like to see more of this.
Only OpenNic has a larger list of TLDs:
Only OpenNic supports uncommon TLDs like .bit.
https://www.wikipedia.org/wiki/OpenNIC#OpenNIC_namespaces

In my opinion, the current state of DNS sucks.

IMO, we need to inform them by adding tabs like supports i2p, Supports TOR, Uses Free Software, and Supports NameCoin. Preferably, requiring them to at least use/support one of these.

Edit: Why isn't OpenNic listed?

I understand the initiative, but it doesn't make sense under the current state of DNS. Here are some notes: _______________ **Only 2 support DNS-Over TOR**: Only Cloudflare and Foundation for Applied Privacy use TOR. **None use I2p**: None of the recommendations use, i2p. Maybe not a huge issue, but I would like to see more of this. **Only OpenNic has a larger list of TLDs**: Only OpenNic supports uncommon TLDs like .bit. https://www.wikipedia.org/wiki/OpenNIC#OpenNIC_namespaces _________________ In my opinion, the current state of DNS sucks. IMO, we need to inform them by adding tabs like `supports i2p`, `Supports TOR`, `Uses Free Software`, and `Supports NameCoin`. Preferably, requiring them to at least use/support one of these. ______________________ **Edit**: Why isn't OpenNic listed?
ghbjklhv1 commented 2019-08-08 21:59:36 +00:00 (Migrated from github.com)
Copy Link

What might be a better idea is to instead have a sortable table of no logging OpenNic Servers.
Basically anybody can host a OpenNic server, so it is very democratic. :)

What might be a better idea is to instead have a sortable table of `no logging` OpenNic Servers. Basically anybody can host a OpenNic server, so it is very democratic. :)
Mikaela commented 2019-08-08 22:10:09 +00:00 (Migrated from github.com)
Copy Link

Only 2 support DNS-Over TOR: Only Cloudflare and Foundation for Applied Privacy use TOR.

And the two that do support DNS over Tor mean two different things by it (https://github.com/privacytoolsIO/privacytools.io/pull/1097/#discussion_r311923362) and the original DNS over Tor would mean

DNSPort [address:]port|auto [isolation flags]
    If non-zero, open this port to listen for UDP DNS requests, and resolve them anonymously. This port only handles A, AAAA, and PTR
    requests---it doesn’t handle arbitrary DNS request types. Set the port to "auto" to have Tor pick a port for you. This directive
    can be specified multiple times to bind to multiple addresses/ports. See SocksPort for an explanation of isolation flags. (Default:
    0)

from man torrc.

None use I2p: None of the recommendations use, i2p.

Do you have any recommendations that support DNS over I2P? I am not aware of any and I think Nitrohorse would have suggested them if he knew.

Only OpenNic has a larger list of TLDs:
Only OpenNic supports uncommon TLDs like .bit.
https://www.wikipedia.org/wiki/OpenNIC#OpenNIC_namespaces

This is a separate issue, but do those have valid SSL certitificates or are they all plain text? We are already recommending OpenNIC on the top of the page though.

In my opinion, the current state of DNS sucks.

I guess there is always room for improvement.

IMO, we need to inform them by adding tabs like supports i2p, Supports TOR, Uses Free Software, and Supports NameCoin. Preferably, requiring them to at least use/support one of these.

I don't see additional value of them.

Edit: Why isn't OpenNic listed?

Because it's already listed. https://www.privacytools.io/providers/dns/#dns

What might be a better idea is to instead have a sortable table of 'no logging' OpenNic Servers.
Basically anybody can host a OpenNic server, so it is very democratic. :)

OpenNIC doesn't fullfil our requirement of supporting DNS over TLS or DNS over HTTPS, I have opened an issue at https://github.com/opennic/opennic-web/issues/68. OpenNIC servers are also already listed at https://servers.opennic.org/ (see also the previous link).

> Only 2 support DNS-Over TOR: Only Cloudflare and Foundation for Applied Privacy use TOR. And the two that do support DNS over Tor mean two different things by it (https://github.com/privacytoolsIO/privacytools.io/pull/1097/#discussion_r311923362) and the original DNS over Tor would mean ``` DNSPort [address:]port|auto [isolation flags] If non-zero, open this port to listen for UDP DNS requests, and resolve them anonymously. This port only handles A, AAAA, and PTR requests---it doesn’t handle arbitrary DNS request types. Set the port to "auto" to have Tor pick a port for you. This directive can be specified multiple times to bind to multiple addresses/ports. See SocksPort for an explanation of isolation flags. (Default: 0) ``` from `man torrc`. > None use I2p: None of the recommendations use, i2p. Do you have any recommendations that support DNS over I2P? I am not aware of any and I think Nitrohorse would have suggested them if he knew. > Only OpenNic has a larger list of TLDs: > Only OpenNic supports uncommon TLDs like .bit. > https://www.wikipedia.org/wiki/OpenNIC#OpenNIC_namespaces This is a separate issue, but do those have valid SSL certitificates or are they all plain text? We are already recommending OpenNIC on the top of the page though. > In my opinion, the current state of DNS sucks. I guess there is always room for improvement. > IMO, we need to inform them by adding tabs like supports i2p, Supports TOR, Uses Free Software, and Supports NameCoin. Preferably, requiring them to at least use/support one of these. I don't see additional value of them. > Edit: Why isn't OpenNic listed? Because it's already listed. https://www.privacytools.io/providers/dns/#dns > What might be a better idea is to instead have a sortable table of 'no logging' OpenNic Servers. > Basically anybody can host a OpenNic server, so it is very democratic. :) OpenNIC doesn't fullfil our requirement of supporting DNS over TLS or DNS over HTTPS, I have opened an issue at https://github.com/opennic/opennic-web/issues/68. OpenNIC servers are also already listed at https://servers.opennic.org/ (see also the previous link).
👍 1
nitrohorse (Migrated from github.com) reviewed 2019-08-09 02:13:58 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 02:13:58 +00:00

Hmm that's true... the wording is a bit misleading since filtering can be by choice or not. Will think of something a bit clearer.

Hmm that's true... the wording is a bit misleading since filtering can be by choice or not. Will think of something a bit clearer.
nitrohorse (Migrated from github.com) reviewed 2019-08-09 02:17:15 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 02:17:15 +00:00

Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking, and make your DNS requests harder to eavesdrop on, tamper with, and share with third parties. If you are currently using Google as your DNS resolver, you should pick an alternative here.

Not sure if that makes it a bit clearer?

> Note: Using an encrypted DNS provider will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking, **and make your DNS requests harder to eavesdrop on, tamper with, and share with third parties.** If you are currently using Google as your DNS resolver, you should pick an alternative here. Not sure if that makes it a bit clearer?
nitrohorse (Migrated from github.com) reviewed 2019-08-09 02:24:43 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 02:24:43 +00:00

Yeah, it's kind of annoying that there isn't a general page with both DoH and DoT endpoints listed that's also bookmark-able; I think the best we could link to would be the DoH page: https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/

cf

Users would then see the DoT page available on the left sidebar 😕

Yeah, it's kind of annoying that there isn't a general page with both DoH and DoT endpoints listed that's also bookmark-able; I think the best we could link to would be the DoH page: https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/ ![cf](https://user-images.githubusercontent.com/1514352/62749654-b5176180-ba4c-11e9-9fd1-1ad9619341cc.png) Users would then see the DoT page available on the left sidebar :confused:
nitrohorse (Migrated from github.com) reviewed 2019-08-09 02:26:17 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 02:26:17 +00:00

I wonder if it would be better to not mention DNS-over-Tor at all...

Yeah, I think that'd be best for now until we decide a more consistent way to list it without confusing users (including me 😅). Thanks for catching this!

> I wonder if it would be better to not mention DNS-over-Tor at all... Yeah, I think that'd be best for now until we decide a more consistent way to list it without confusing users (including me :sweat_smile:). Thanks for catching this!
nitrohorse commented 2019-08-09 03:17:31 +00:00 (Migrated from github.com)
Copy Link

IMO, we need to inform them by adding tabs like supports i2p, Supports TOR, Uses Free Software, and Supports NameCoin

Thanks for the suggestions, @ghbjklhv1! I don't think a table with this criteria should override this table. Rather be in addition to possibly (or in the future add additional columns)? We'll need to iterate over and clarify DNS-over-Tor/I2P + NameCoin support more (I'm still learning), and I think having this table for encrypted ICANN DNS resolvers that support DoH/DoT/DNSCrypt is valuable for PTIO users now (and also a good launching point for enhancing the DNS page overall).

> IMO, we need to inform them by adding tabs like supports i2p, Supports TOR, Uses Free Software, and Supports NameCoin Thanks for the suggestions, @ghbjklhv1! I don't think a table with this criteria should override _this_ table. Rather be in addition to possibly (or in the future add additional columns)? We'll need to iterate over and clarify DNS-over-Tor/I2P + NameCoin support more (I'm still learning), and I think having this table for encrypted ICANN DNS resolvers that support DoH/DoT/DNSCrypt is valuable for PTIO users now (and also a good launching point for enhancing the DNS page overall).
👍 1
nitrohorse (Migrated from github.com) reviewed 2019-08-09 03:21:37 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 03:21:36 +00:00

Removed for now.

Removed for now.
nitrohorse commented 2019-08-09 03:35:55 +00:00 (Migrated from github.com)
Copy Link

I am not sure if the source_code file needs updating in this case as you already linked sources everywhere.

Ah, good catch -- I don't mind; I think it'll be useful to add 👍

> I am not sure if the source_code file needs updating in this case as you already linked sources everywhere. Ah, good catch -- I don't mind; I think it'll be useful to add :+1:
👍 1
nitrohorse (Migrated from github.com) reviewed 2019-08-09 05:58:28 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 05:58:28 +00:00

I've updated the code with this change for easier previewing.

I've updated the code with this change for easier previewing.
nitrohorse (Migrated from github.com) reviewed 2019-08-09 05:59:39 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 05:59:39 +00:00

Updated Cloudflare's link to point to https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/ until we figure out something better.

Updated Cloudflare's link to point to https://developers.cloudflare.com/1.1.1.1/dns-over-https/request-structure/ until we figure out something better.
Mikaela (Migrated from github.com) reviewed 2019-08-09 09:46:02 +00:00
Mikaela (Migrated from github.com) left a comment

I have some small comments, but am impatient to get this merged. How about you @blacklight447-ptio ?

I have some small comments, but am impatient to get this merged. How about you @blacklight447-ptio ?
_includes/sections/dns.html
Mikaela (Migrated from github.com) commented 2019-08-09 09:37:14 +00:00 
  <strong>Note: Using an encrypted DNS resolver will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking, and make your DNS requests harder to eavesdrop on and tamper with. If you are currently using Google's DNS resolver, you should pick an alternative here.</strong>

I think sharing implies consent and there is nothing that could prevent the DNS resolver from sharing it to third parties (except their policies, but some like Quad9 do say to share anonymized data).

I guess this line is not going to be perfect, so I would be fine with merging like this too.

```suggestion <strong>Note: Using an encrypted DNS resolver will not make you anonymous, nor hide your internet traffic from your Internet Service Provider. But it will prevent DNS hijacking, and make your DNS requests harder to eavesdrop on and tamper with. If you are currently using Google's DNS resolver, you should pick an alternative here.</strong> ``` I think sharing implies consent and there is nothing that could prevent the DNS resolver from sharing it to third parties (except their policies, but some like Quad9 do say to share anonymized data). I guess this line is not going to be perfect, so I would be fine with merging like this too.
Mikaela (Migrated from github.com) commented 2019-08-09 09:38:31 +00:00

Should this say?

        <td data-value="No">?</td>
Should this say? ```suggestion <td data-value="No">?</td> ```
Mikaela (Migrated from github.com) commented 2019-08-09 09:40:44 +00:00

data-value=doh DoT?

data-value=doh DoT?
Mikaela (Migrated from github.com) commented 2019-08-09 09:41:00 +00:00 
    <li>DNSCrypt - An older yet robust method of encrypting DNS.</li>
```suggestion <li>DNSCrypt - An older yet robust method of encrypting DNS.</li> ```
source_code.md
@ -272,2 +274,3 @@
- NoTrack: https://github.com/quidsup/notrack
Namecoin: https://github.com/namecoin
- Namecoin: https://github.com/namecoin
Mikaela (Migrated from github.com) commented 2019-08-09 09:43:33 +00:00

You missed https://github.com/s-s/dnscloak ?

You missed https://github.com/s-s/dnscloak ?
blacklight447 commented 2019-08-09 10:31:05 +00:00 (Migrated from github.com)
Copy Link

I'm fine with the merge, on the cloudflare thing, most critisms seem to be mostly speculation. I dislike them for captchaing tor users, but they do seem to improve the situation by design alt SVC onions. They also do a lot of other good stuff like rolling out encrypted sni.

I'm fine with the merge, on the cloudflare thing, most critisms seem to be mostly speculation. I dislike them for captchaing tor users, but they do seem to improve the situation by design alt SVC onions. They also do a lot of other good stuff like rolling out encrypted sni.
👍 1
nitrohorse (Migrated from github.com) reviewed 2019-08-09 14:47:13 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 14:47:13 +00:00

Going to stay with https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/ 👍

Going to stay with https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1/ :+1:
nitrohorse (Migrated from github.com) reviewed 2019-08-09 14:49:18 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 14:49:18 +00:00

Good point! Updated to:

But it will prevent DNS hijacking, and make your DNS requests harder for third parties to eavesdrop on and tamper with.
Which we can always change later on 👍

Good point! Updated to: > But it will prevent DNS hijacking, and make your DNS requests harder for third parties to eavesdrop on and tamper with. Which we can always change later on :+1:
nitrohorse (Migrated from github.com) reviewed 2019-08-09 14:50:04 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 14:50:03 +00:00

Good catch! Will update.

Good catch! Will update.
nitrohorse (Migrated from github.com) reviewed 2019-08-09 14:55:42 +00:00
_includes/sections/dns.html
nitrohorse (Migrated from github.com) commented 2019-08-09 14:55:41 +00:00

Yeah, this is the "hack" I mentioned for "DoT" values when sorted to be grouped with "DoH" values. Don't really like it myself but it's what I could figure out for now.

Yeah, this is the "hack" I mentioned for "DoT" values when sorted to be grouped with "DoH" values. Don't really like it myself but it's what I could figure out for now.
Mikaela (Migrated from github.com) approved these changes 2019-08-09 15:00:26 +00:00
Mikaela (Migrated from github.com) left a comment

👍

:+1:
This repo is archived. You cannot comment on pull requests.
Reviewers
No reviewers
Mikaela
Labels
Clear labels   
🔍🤖 Search Engines

   
approved

approved, waiting for a PR

  
dependencies

Pull requests that update a dependency file

  
duplicate

   
feedback wanted

   
high priority

   
I2P

The Invisible Internet Project (I2P)

  
iOS

   
low priority

   
OS

Operating Systems

  
Self-contained networks

   
Social media

   
stale

A label for stalebot if it gets added

  
streaming

Anything related to media streaming.

  
todo

   
Tor

Anything covering the Tor network

  
WIP

active work in progress, do not merge or PR (yet)!

  
wontfix

Issues or bugs that will not be fixed and/or do not have significant impact on the project.

  
XMPP

Extensible Messaging and Presence Protocol

  
[m]

Matrix protocol

  
₿ cryptocurrency

   
ℹ️ help wanted

   
↔️ file sharing

   
⚙️ web extensions

Browser Extension related issues

  
✨ enhancement

   
❌ software removal

   
💬 discussion

   
🤖 Android

   
🐛 bug

   
💢 conflicting

   
📝 correction

Correction of content on the website

  
🆘 critical

   
📧 email

   
🔒 file encryption

   
📁 file storage

   
🦊 Firefox

Firefox & forks, about:config etc.

  
💻 hardware

   
🌐 hosting

   
🏠 housekeeping

Anything primarily related to site cleanup.

  
🔐 password managers

   
🧰 productivity tools

   
🔎 research required

   
🌐 Social News Aggregators

   
🆕 software suggestion

   
👥 team chat

   
🔒 VPN

Virtual Private Network

  
🌐 website issue

*Technical* issues with the website.

  
🚫 Windows

   
👁️ browsers

   
🖊️ digital notebooks

   
🗄️ DNS

Domain Name System

  
🗨️ instant messaging (im)

   
🇦🇶 translations

Anything covering a translated version of the site

No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1097
No description provided.
Delete Branch "add-dns-table"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?