Talk:Alternative DNS services

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-up^AUR 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 agree that the subsection doesn't fit, and updated my draft. How is Wikipedia less accessible? We use the same software. Do you know any curated list alternatives? I don't. --Larivact (talk) 19:30, 1 January 2019 (UTC)

I agree with the redirection flag, IMO linking to Wikipedia for a list of services is sufficient. -- Lahwaacz (talk) 19:41, 1 January 2019 (UTC)

There's also https://dnscrypt.info/public-servers/, but it is not as good as the Wikipedia's list. -- nl6720 (talk) 09:57, 2 January 2019 (UTC)

Thanks, not as good as wikipedia's. I missed the question regarding accessibility above: one has to distinguish between read and write access to wikipedia. w:Censorship of Wikipedia gives an idea about the first, the latter is more difficult to evaluate. But most users of proxy/vpn services are barred from contributing to (and by) wikipedia; that alone is in the 8-digit range of internet users. --Indigo (talk) 18:42, 9 January 2019 (UTC)

Interesting, I didn't know about w:Wikipedia:Open proxies. --Larivact (talk) 19:17, 9 January 2019 (UTC)

To be fair, we don't know if some countries or ISPs censor the ArchWiki - the same (in)accessibility arguments may apply just as well as for Wikipedia. And I don't see how the amount of Wikipedia users is relevant, since the Arch community, including all potential ArchWiki readers and editors, is not even remotely as large. -- Lahwaacz (talk) 22:43, 9 January 2019 (UTC)

Sure, I don't want to over-emphasize that side; I mentioned it to help with one rationale for allergies. We likely (hopefully) all agree it's not the primary rationale for the list at hand: that being Arch users merely using the section/page as a KISS way to share a moderated list of what the individual contributors/maintainers saw as a quality/useful DNS service in the past. --Indigo (talk) 17:12, 10 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)

The previous sentence was let's wait, not let's go... Lahwaacz (talk) 19:30, 1 January 2019 (UTC)

I interpreted it as let's wait on what we do with this page. My draft may not be perfect but it is definitely better than the current Domain name resolution#Privacy.--Larivact (talk) 19:34, 1 January 2019 (UTC)

I agree that the draft is better than the current page. I support the merge. -- nl6720 (talk) 09:18, 9 January 2019 (UTC)

Section merged and page redirected. Closing this. --Larivact (talk) 17:04, 9 January 2019 (UTC)

I'm at a loss why you redirected the article now, while you wrote above you want to merge the #Draft 2: Domain name resolution#Privacy replacement? --Indigo (talk) 18:42, 9 January 2019 (UTC)

I find the Domain name resolution page pretty damn good now, so let's at least close the draft below. -- Lahwaacz (talk) 20:36, 9 January 2019 (UTC)

Oh, it has sure grown well, yes. Yet, the TOC of DNS is problematic with too many top level sections. For example, do you really see #Third-party DNS servers is best placed in the main DNS article, while we have an Alternative DNS services page? Why? --Indigo (talk) 22:10, 9 January 2019 (UTC)

I don't think that 8 top-level sections is too many, especially since 4 of them don't have any subsection. As for the placement of #Third-party DNS servers, that depends on whether we should keep this page. Or, as Kewl mentioned above, whether Domain name resolution#Third-party DNS servers can be considered as the result of merging Alternative DNS services to Domain name resolution, using Wikipedia as an external data source with superior content. -- Lahwaacz (talk) 22:43, 9 January 2019 (UTC)

Well, I suggest the TOC other than the third-party section is best to cover in DNS talk. Also, I don't want to be the only one holding this up and want to acknowledge that everyone proposing redirection here has invested time and effort into the article previously.

Looking over the wikipedia list I miss two of the nine entries on ours. These were silently accepted casualties, removed in error, or discussed and I missed that, or is there information they won't make it into the wikipedia list? Just to know, not to create extra work. --Indigo (talk) 17:12, 10 January 2019 (UTC)

I've added the two missing entries to Wikipedia. -- Lahwaacz (talk) 22:21, 16 January 2019 (UTC)

Even better, thank you. --Indigo (talk) 22:33, 16 January 2019 (UTC)

They will just be removed (as they already were earlier) because of lacking notability / self-citations. w:Talk:Public recursive name server#Notability of public name server providers. Reopening. --Larivact (talk) 05:20, 17 January 2019 (UTC)

Draft 2: Domain name resolution#Privacy replacement

Privacy and security

The DNS protocol is unencrypted and does not account for confidentiality, integrity or authentication, so 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. DNS servers are provided by ISPs and third-parties. Alternatively you can run your own recursive name server, which however takes more effort. If you use a DHCP client in untrusted networks, be sure to set static name servers to avoid using and being subject to arbitrary DNS servers. 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 upstream 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 upstream server(s) and your resolver support it.

Be aware that 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.[1]

Third-party DNS servers

Note: Before using a third-party DNS service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties.

There are various third-party DNS services available, some of which also have dedicated software:

• dingo — A DNS client for Google DNS over HTTPS

https://github.com/pforemski/dingo || dingo

• opennic-up — Automates the renewal of the DNS servers with the most responsive OpenNIC servers

https://github.com/kewlfft/opennic-up || opennic-up^AUR

Draft comments

Wording

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

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.[2]. --Larivact (talk) 12:48, 31 December 2018 (UTC)

How about moving the sentence about DNSSEC validation to the first paragraph, after DNS hijacking is mentioned? -- nl6720 (talk) 10:07, 2 January 2019 (UTC)

I like the current separation: the 1st paragraph explains shortcomings and the 2nd introduces technologies to overcome the shortcomings. --Larivact (talk) 10:41, 2 January 2019 (UTC)

Tools vs. clients

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)

My point was that opennic-up^AUR is not a DNS client, but I guess it could be called a client of sorts for the DNS service. -- nl6720 (talk) 10:48, 7 January 2019 (UTC)

Good point, I added "or tools" to avoid confusion. --Larivact (talk) 11:24, 7 January 2019 (UTC)

Recursive name server vs. resolver resolver

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)

DNSSEC server support

Ad Special:Diff/561295:

DNSSEC also cannot be done without server support

Yes but that formulation doesn't really fit if you run your own recursive name server because then you have multiple authoritative servers. --Larivact (talk) 19:23, 1 January 2019 (UTC)

Then fix the formulation. The statement about server support should still be there though, because the draft is intended to replace the Alternative DNS services page and DNSSEC support is not obvious. -- Lahwaacz (talk) 19:36, 1 January 2019 (UTC)

I don't quite know how. Alternative DNS services does not explain DNSSEC but I agree that it's not obvious --Larivact (talk) 19:39, 1 January 2019 (UTC)

Done. --Larivact (talk) 19:54, 1 January 2019 (UTC)

I don't pretend to understand DNSSEC, but setting up a local recursive DNS server and self-signing all responses regardless of what has been received from other DNS servers does not sound secure to me. -- Lahwaacz (talk) 20:07, 1 January 2019 (UTC)

Well the authoritative name servers will obviously still need to support DNSSEC. You can set up a local recursive DNS server that handles the DNSSEC validation and use it with a resolver like glibc that does not support DNSSEC. --Larivact (talk) 20:16, 1 January 2019 (UTC)

I too admit to not knowing very much of this. If I understand w:Domain Name System Security Extensions#Recursive name servers correctly, validating resolvers recursively verify the signatures starting from DNS root. So, "self-signing all responses regardless of what has been received from other DNS servers" can only happen with a malicious server, but the sentence is specifically about running your own recursive resolver. -- nl6720 (talk) 09:51, 2 January 2019 (UTC)

I restored your formulation and refined it more elegantly. --Larivact (talk) 16:20, 7 January 2019 (UTC)

Title

Are there still objections to the section title Privacy and security? --Larivact (talk) 19:43, 1 January 2019 (UTC)

I still don't like it. I could agree with the title, if the paragraph about connecting to remote DNS servers, the Wikipedia link and the tools would be placed in a separate section (not subsection) below it, e.g. Domain name resolution#Alternative DNS services. -- nl6720 (talk) 10:02, 2 January 2019 (UTC)

I agree and updated my draft. Thanks for your suggestions, I appreciate them.--Larivact (talk) 10:51, 2 January 2019 (UTC)

Service lists

How about adding links to [3] and [4], so that Wikipedia is not our only source of DNS services? E.g.:

..., there are various alternative DNS services available. A list of them can be found in Wikipedia:Public recursive name server#List of public DNS service operators, https://dnscrypt.info/public-servers and https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers. Some of the DNS services also have dedicated clients: ...

-- nl6720 (talk) 09:55, 7 January 2019 (UTC)

I find the DNSCrypt list quite useless because it does not show addresses / link websites. Your second list is quite short (only 3 providers), lacks sources and confuses the Cloudflare FAQ with their privacy policy. --Larivact (talk) 11:04, 7 January 2019 (UTC)

I didn't say the lists are good, just that they are an alternative for people allergic to Wikipedia. -- nl6720 (talk) 11:10, 7 January 2019 (UTC)

I don't think that we should cater to people with irrational allergies. --Larivact (talk) 11:56, 7 January 2019 (UTC)

No objections from me. -- nl6720 (talk) 12:04, 7 January 2019 (UTC)

Untrusted networks

I think that "untrusted networks", e.g. public wifi, should be somehow mentioned in #Third-party DNS servers. -- nl6720 (talk) 09:56, 7 January 2019 (UTC)

Why if it is already addressed in the section above (#Privacy and security)? --Larivact (talk) 10:21, 7 January 2019 (UTC)

True, but untrustworthy ISP is mentioned in both. I just thought that public wifi would serve as a good example for a situation in which one would want to use an encrypted connection to a third-party DNS server. -- nl6720 (talk) 10:44, 7 January 2019 (UTC)

Secure DNS does make an untrusted network secure. If you do not check the green padlock in your browser or your email client falls back to plaintext when STARTTLS fails, DNS over anything and DNSSEC won't help you.--Larivact (talk) 11:19, 7 January 2019 (UTC)

Secure DNS in a untrusted network will make the DNS somewhat secure (depending how the local resolver is configured). My original point was about DNS hijacking and DNS cache poisoning. The issue with the current text "DNS service of your ISP" is that, the ISP's DNS server might not even be involved. Local networks run their own DNS servers, and (untrusted/public) networks might serve incorrect DNS either from the network's DNS server or a malicious party in the network. -- nl6720 (talk) 11:51, 7 January 2019 (UTC)

Thanks for elaborating. I added a sentence about DHCP to the Note. --Larivact (talk) 12:46, 7 January 2019 (UTC)

I don't know if it's important enough for a Template:Note, but I'm glad it's mentioned. Thanks.

One minor nitpick: If you use DHCP; the user can usually only control the client side, so "using DHCP" sounds too grand for me. How about If you use a DHCP client? -- nl6720 (talk) 13:06, 7 January 2019 (UTC)

Changed. --Larivact (talk) 13:12, 7 January 2019 (UTC)

Thanks. -- nl6720 (talk) 13:15, 7 January 2019 (UTC)

With Special:Diff/562252 this has been undone. Now #Third-party DNS servers only mentions avoiding the ISP's DNS servers and not the local network's. -- nl6720 (talk) 16:29, 7 January 2019 (UTC)

I just removed the problematic wording. It was redundant anyway. --Larivact (talk) 16:42, 7 January 2019 (UTC)

Ok. Though now the section is very brief. -- nl6720 (talk) 16:50, 7 January 2019 (UTC)

Third-party

The draft uses the term third-party as if it included ISPs but it just hit me that ISPs are probably 2nd parties. Is there a better term for something that is not yours? --Larivact (talk) 12:57, 7 January 2019 (UTC)

Which instance of "third-party" do you find problematic? -- nl6720 (talk) 13:16, 7 January 2019 (UTC)

Every instance. When you search the internet for "Third-party DNS server", it is always meant as not yours (first-party) and not from your ISP (2nd-party). How about renaming the 2nd section to Other party DNS servers and explaining 1st, 2nd and 3rd parties in the section intro? The "alternative DNS services" link should then be renamed to "third-party DNS servers". --Larivact (talk) 13:25, 7 January 2019 (UTC)

"Other party DNS servers" would just make it very confusing. Can you even think of a good and understandable explanation for the 1st, 2nd and 3rd parties? I think it's better to evaluate the occurrences of "third-party" one by one and see what we can think of. -- nl6720 (talk) 13:38, 7 January 2019 (UTC)

Thanks for breaking it down. My main gripe was that the DHCP sentence also applies to 2nd-parties but now that I moved it that is resolved. So there was only one inaccurate use, which I fixed so this can be closed. --Larivact (talk) 17:06, 7 January 2019 (UTC)

If you use a third-party DNS server, be sure to check its privacy policy.

I don't see a problem here. You evaluate the 2nd party (ISP) and its policies when you sign the contract with it. -- nl6720 (talk) 13:43, 7 January 2019 (UTC)

To use DNSSEC with a third-party name server, it needs to be supported by both the server and your resolver.

Suggestion: change it to: To use DNSSEC, it needs to be supported by both the name server and your resolver. -- nl6720 (talk) 13:41, 7 January 2019 (UTC)

Resolved by Special:Diff/562252/562257. --Larivact (talk) 16:22, 7 January 2019 (UTC)

#Third-party DNS servers

#Alternative DNS services or #Alternative DNS servers? This obviously doesn't involve the ISP's DNS servers. -- nl6720 (talk) 13:45, 7 January 2019 (UTC)

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.

Replace "third-party service" with "DNS service". Before using a DNS service, check its privacy policy for information on how user data is handled. User data has value and can be sold to other parties. -- nl6720 (talk) 13:46, 7 January 2019 (UTC)

Not needed because as you said: "You evaluate the 2nd party (ISP) and its policies when you sign the contract with it." --Larivact (talk) 16:28, 7 January 2019 (UTC)