Future of the page
- 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)
- 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 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 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.
- "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)
- 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)
- 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)
- 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)
- 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'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 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)
- 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.
Third-party DNS servers
There are various third-party DNS services available, some of which also have dedicated software:
- dingo — A DNS client for Google DNS over HTTPS
- opennic-up — Automates the renewal of the DNS servers with the most responsive OpenNIC servers
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)
- 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)
- 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)
Tools vs. clients
Recursive name server vs. resolver resolver
- 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)
DNSSEC server support
- DNSSEC also cannot be done without server support
- 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 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 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)
..., 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: ...
- Why if it is already addressed in the section above (#Privacy and security)? --Larivact (talk) 10:21, 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)
- 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)
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)
- 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)
- #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)