Difference between revisions of "Talk:Alternative DNS services"

From ArchWiki
Jump to navigation Jump to search
(Future of the page: re)
(Draft 2: Domain name resolution#Privacy and security: DNSSEC also cannot be done without server support, see w:Public_recursive_name_server#List_of_public_DNS_service_operators)
Line 71: Line 71:
 
You need to trust your DNS server to treat your queries confidentially. Before using a third party service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties. If you do not trust the DNS service of your ISP, there are various [[Wikipedia:Public recursive name server#List of public DNS service operators|alternative DNS services]] available, some of which also have [[#Alternative DNS service clients|dedicated clients]]. Alternatively you can run your own [[#Resolvers|recursive name server]].
 
You need to trust your DNS server to treat your queries confidentially. Before using a third party service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties. If you do not trust the DNS service of your ISP, there are various [[Wikipedia:Public recursive name server#List of public DNS service operators|alternative DNS services]] available, some of which also have [[#Alternative DNS service clients|dedicated clients]]. Alternatively you can run your own [[#Resolvers|recursive name server]].
  
To secure your communication with a remote DNS server you can use an encrypted protocol, like [[Wikipedia:DNS over TLS|DNS over TLS]], [[Wikipedia:DNS over HTTPS|DNS over HTTPS]] or [[Wikipedia:DNSCrypt|DNSCrypt]], provided that both the server and your [[#Resolvers|resolver]] support the protocol. To verify that responses are actually from authoritative name servers, you can validate [[DNSSEC]], see [[#Resolvers]] for what resolvers support it.
+
To secure your communication with a remote DNS server you can use an encrypted protocol, like [[Wikipedia:DNS over TLS|DNS over TLS]], [[Wikipedia:DNS over HTTPS|DNS over HTTPS]] or [[Wikipedia:DNSCrypt|DNSCrypt]], provided that both the server and your [[#Resolvers|resolver]] support the protocol. To verify that responses are actually from authoritative name servers, you can validate [[DNSSEC]], provided that both the server and your [[#Resolvers|resolver]] support it.
  
 
Be aware client software, such as major web browsers, may also (start to) implement some of the protocols. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/#trr-and-doh]
 
Be aware client software, such as major web browsers, may also (start to) implement some of the protocols. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/#trr-and-doh]

Revision as of 19:14, 1 January 2019

Future of the page

Another alternative could be to refocus this page on Arch solutions and non-commercial DNS. -- Kewl (talk) 18:42, 10 November 2018 (UTC)

What are "Arch solutions"? --Larivact (talk) 18:48, 10 November 2018 (UTC)
This is an open question, we may present ways to select the most secure and fastest DNS for a given location using Arch tools for example. -- Kewl (talk) 19:03, 10 November 2018 (UTC)
Such information could be incorporated into Domain name resolution. --Larivact (talk) 19:07, 10 November 2018 (UTC)
I also think so, then some information of the DNS Alternative page could be used in this new section in Domain name resolution. --Kewl (talk) 19:11, 10 November 2018 (UTC)
wikipedia clearly is an unreliable source. The ArchWiki can do better than that! Keep the article! Once a real good ARCH package for OpenNIC is shipped with major distros, OpenNIC will become more important! UBF6 (talk) 09:03, 20 November 2018 (UTC)
The takeaway of this short talk is that it is rather a candidate for merging than for archiving. -- Kewl (talk) 11:00, 20 November 2018 (UTC)
I disagree because the only things I see worth merging are the opennic-up App template and the Wikipedia link in See also. --Larivact (talk) 16:35, 20 November 2018 (UTC)
The ArchWiki is not more reliable than Wikipedia. If anything it's the opposite because Wikipedia requires sources, which we do not do at all. --Larivact (talk) 16:10, 20 November 2018 (UTC)
Most content on ArchWiki you can verify yourself and having source for that would be redundant. We often add links to the relevant sources when needed to prove some claim or give more information. Often we get new wiki contributors because something on our pages turns out to be more or less incorrect and we got just the right type of audience that wants to contribute and fix it. I don't think one wiki is worse than another, it would probably depend on the contributor and where one puts their effort in. -- Svito (talk) 18:04, 20 November 2018 (UTC)
Given above discussion, my proposal for this article is to (a) make a note at the beginning referring to the wikipedia article for its (lately grown, see Nov17) table with details such as privacy policy references, offered services, etc; (b) keep watching the entries here stay neutral and short, quoting references for more info; optionally (c) suggest moving it to a subpage of Domain name resolution, referring it from (maybe) a new subsection in the main article as Kewl suggests.
My take on archiving would be to start proposing that again once the info gets markedly outdated/unmaintained.
Objections? --Indigo (talk) 19:16, 20 November 2018 (UTC)
As I understand, everything in Alternative DNS services apart from opennic-upAUR and "Wikipedia:Public recursive name server#List of public DNS service operators" is useless (i.e. not good enough compared to the list on Wikipedia). So I propose to merge those two relevant bits into Domain name resolution#Privacy, rename it to Domain name resolution#Alternative DNS services and also rewrite the section. See proposed draft below. -- nl6720 (talk) 08:41, 31 December 2018 (UTC)
I agree with the merge but think your draft can be improved, I'll start a new one below yours. --Larivact (talk) 09:57, 31 December 2018 (UTC)
I really don't like the word "Privacy" in the section title. What's so private about sending your DNS queries a third-party server? And I hope "confidentiality" isn't meant "hiding from the ISP", because the ISP has more than one way to track the user.
I'd like to keep Template:Warning because reading the privacy policy is essential, and it should be explicitly stated that connecting to a third-party server means trusting it. If you want to add the words "security" and "integrity", then I think DNSSEC must be mentioned. -- nl6720 (talk) 11:05, 31 December 2018 (UTC)
DNS queries are private data and thus a concern of privacy. Confidentiality is meant as hiding DNS queries from everybody whom they don't concern. I don't regard privacy policies as more important than the rest of the section. --Larivact (talk) 12:39, 31 December 2018 (UTC)
"from everybody whom they don't concern" is quite a broad category. Some might say it includes everyone in w:Public recursive name server#List of public DNS service operators. -- nl6720 (talk) 13:04, 31 December 2018 (UTC)
Well, if you choose to use a third party DNS server, they obviously need to be able to read your queries. --Larivact (talk) 00:21, 1 January 2019 (UTC)
I agree with nl6720 on the section title, but my consequence is different in that I believe your exchange shows there is a need for both section headings. To me this argument starts from it being far from ideal to list commercial services under a "Privacy and security" heading in the context. In turn I agree that under said header a warning is indeed overdoing it, but in combination with listing services it indeed is warranted. --Indigo (talk) 18:25, 1 January 2019 (UTC)
We do not want to list services at all, Wikipedia does that already and there is no reason for us to duplicate that. --Larivact (talk) 18:42, 1 January 2019 (UTC)
I was referring to the packages you two listed in the draft. And to the wikipedia argument I want to re-iterate that it is a different wiki, far less accessible & with a different focus than ours. How about another up-to-date moderated alternative list to link? --Indigo (talk) 19:11, 1 January 2019 (UTC)
I think my draft is ready to be merged. --Larivact (talk) 00:28, 1 January 2019 (UTC)
Thanks. For now there are more pro keeping than against. Let's wait if there is more feedback. --Indigo (talk) 18:25, 1 January 2019 (UTC)
Alright, I merged the improvements that are independent of this page's future. --Larivact (talk) 18:37, 1 January 2019 (UTC)

Draft 1: Domain name resolution#Alternative DNS services

Since DNS is not encrypted, in an untrusted network or with a malicious ISP you can get subjected to DNS hijacking. In such an environment, to ensure you receive correct DNS responses, you would need to connect to a trusted third-party nameserver and use an encrypted protocol to prevent DNS modification en route.

Doing all that requires setting up a resolver that supports an encrypted protocol, like DNS over TLS, DNS over HTTPS or DNSCrypt, and connecting it to a trusted DNS server. Be aware client software, such as major web browsers, may also (start to) implement one of the protocols. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[1]

A list of public DNS services can be found in Wikipedia:Public recursive name server#List of public DNS service operators.

Warning: Most DNS servers keep a log of IP addresses and sites visited on a more or less temporary basis. The data collected can be used to perform various statistical studies. Personally-identifying information have value and can also be rented or sold to third parties. Before using a third-party DNS service, check their privacy policy for information about how user data is handled.

Some DNS service usage can be simplified by using a dedicated tool. E.g.:

  • opennic-up — Automates the renewal of the DNS servers with the most responsive OpenNIC servers
https://github.com/kewlfft/opennic-up || opennic-upAUR
  • dingo — A DNS client for Google DNS over HTTPS
https://github.com/pforemski/dingo || dingo

Draft 2: Domain name resolution#Privacy and security

The DNS protocol is unencrypted and does not account for confidentiality, integrity or authentication. Meaning, if you use an untrusted network or a malicious ISP, your DNS queries can be eavesdropped and the responses manipulated. Furthermore DNS servers can conduct DNS hijacking.

You need to trust your DNS server to treat your queries confidentially. Before using a third party service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties. If you do not trust the DNS service of your ISP, there are various alternative DNS services available, some of which also have dedicated clients. Alternatively you can run your own recursive name server.

To secure your communication with a remote DNS server you can use an encrypted protocol, like DNS over TLS, DNS over HTTPS or DNSCrypt, provided that both the server and your resolver support the protocol. To verify that responses are actually from authoritative name servers, you can validate DNSSEC, provided that both the server and your resolver support it.

Be aware client software, such as major web browsers, may also (start to) implement some of the protocols. While the encryption of queries may often be seen as a bonus, it also means the software sidetracks queries around the system resolver configuration.[2]

Alternative DNS service clients

For some alternative DNS services there are dedicated tools / resolvers available:

  • opennic-up — Automates the renewal of the DNS servers with the most responsive OpenNIC servers
https://github.com/kewlfft/opennic-up || opennic-upAUR
  • dingo — A DNS client for Google DNS over HTTPS
https://github.com/pforemski/dingo || dingo

Comments

Ad first paragraph: I think it would be better if the second sentence listed conditions (untrusted network or a malicious ISP) before the scary words (eavesdropped and manipulated). Meaning, if you use an untrusted network or a malicious ISP, your DNS queries can be eavesdropped and the responses manipulated. -- nl6720 (talk) 11:26, 31 December 2018 (UTC)

Done. --Larivact (talk) 12:22, 31 December 2018 (UTC)

DNSSEC should be more than an afterthought :( -- nl6720 (talk) 11:26, 31 December 2018 (UTC)

Suggestion: "you can use DNSSEC" -> "you can validate DNSSEC". Passthrough counts as using. If the local resolver doesn't validate it, then it is up to individual applications, which is ineffective. -- nl6720 (talk) 12:19, 31 December 2018 (UTC)
Done, thank you very much for this insight. I don't know much about DNSSEC and wasn't aware of passthrough. --Larivact (talk) 12:29, 31 December 2018 (UTC)
AFAIK it's just a bit that gets passed on, Authenticated Data (AD). Also, I advise you to not believe all the second hand hearsay I repeat, that will end badly :D -- nl6720 (talk) 12:37, 31 December 2018 (UTC)
Don't worry, I researched it.[3]. --Larivact (talk) 12:48, 31 December 2018 (UTC)

Ad subsection: Just call them "tools". It will be easier to expand if more of them appear. -- nl6720 (talk) 11:26, 31 December 2018 (UTC)

Tools for services are generally clients. --Larivact (talk) 12:22, 31 December 2018 (UTC)

I suggest replacing "recursive name server" with "recursive resolver". Since it will be running locally, the resolver functionality is more important. -- nl6720 (talk) 12:06, 31 December 2018 (UTC)

Actually, it doesn't need to run locally. -- nl6720 (talk) 12:21, 31 December 2018 (UTC)
The way I understand these terms is that every nameserver is also a resolver. The only resolver we have that is not also a nameserver is glibc, which doesn't support recursion so "name server" appropriate. --Larivact (talk) 12:22, 31 December 2018 (UTC)
That's how I understand it too, It's just that most people don't think of the local resolvers as DNS servers. I'm still not certain if "recursive name server" is correct, it's the resolver part that does the recursive query, no the server part... Let's keep it as it is until someone smarter comes along. -- nl6720 (talk) 12:30, 31 December 2018 (UTC)
I am quite sure because Wikipedia agrees: w:Name server#Recursive query and w:Public recursive name server. --Larivact (talk) 12:45, 31 December 2018 (UTC)