Talk:Domain name resolution
Covering DNS servers in general
Domain name resolution#Resolvers currently focuses on running a local name server as a resolver. I think it can be expanded to cover DNS servers in general, including authoritative-only servers. See my draft below.
I also added Package and Authoritative columns and merged the legend into the table header.
DNS servers can be authoritative and recursive. If they are neither, they are called stub resolvers and simply forward all queries to another recursive name server. Stub resolvers are typically used to introduce DNS caching on the local host or network. Note that the same can also be achieved with a fully-fledged name server. This section compares the available DNS servers, for a more detailed comparison, refer to Wikipedia.
- Implements a DNSCrypt protocol client.
- Only forwards using DNS over HTTPS when Rescached itself is queried using DNS over HTTPS.
- From  Also, the only supported mode is "opportunistic", which makes DNS-over-TLS vulnerable to "downgrade" attacks. : Note as the resolver is not capable of authenticating the server, it is vulnerable for "man-in-the-middle" attacks.
- From Wikipedia: dnsmasq has limited authoritative support, intended for internal network use rather than public Internet use.
Good work with the tables. I'm just not so sure it's a good idea to cover DNS-servers in general in the same subsection. The whole article is written from a client system perspective and that's appropriate, as a server is out of bounds for most and the info may distract from the KISS solutions for a typical client system. I would move the new info down into the new #Authoritative-only servers, rename that & move it to the end of the article - so it does not mix with desktop usage. Also note some columns may have different meanings for a client or server feature. Further, "authoritative" does not add much to "recursive" in this short context. Hence, I'm wondering if it makes more sense to move the packages which are "authoritative/recursive DNS servers/resolvers" into the new section table in total. --Indigo (talk) 22:10, 2 January 2019 (UTC)
- The fully-fledged servers can just as well be used for a local caching server and there are also scenarios where it makes sense (for example if both caching and DNS over TLS are desired), so I think they should be in the same table as the stub resolvers. And I also think it makes sense to keep authoritative servers next to each other. If the comparison does not fit into the article, perhaps it should be outsourced to a new Comparison of DNS servers article. --Larivact (talk) 22:45, 2 January 2019 (UTC)
- Well, some even run two dns servers; for example since authoritative name servers are frequently abused for DDoS attacks. That is another reason subsumed in my suggestion it is "out of bounds for most". But anyway, I moved sections so that the referred client sections are not in the way. Perhaps wait a bit more (in case of other suggestions) before going ahead as you planned. --Indigo (talk) 15:53, 3 January 2019 (UTC)
- Yes, you can remove the "Fill in the unknowns" sentence. If you'll also add Deadwood to the table, then you could remove the whole expansion template. -- 10:12, 28 February 2019 (UTC)
Some DNS servers flush the cache when the configuration changes
systemd-resolved flush the cache when the network configuration changes. However
dnsmasq with the default setup keeps its cache when the configuration changes. Is this information worth adding to the comparison table? -- Pdc (talk) 12:40, 3 March 2019 (UTC)