Talk:Domain name resolution
- 1 Covering DNS servers in general
- 2 Some DNS servers flush the cache when the configuration changes
- 3 Split DNS resolver
- 4 Implement DoT with stunnel on any server
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)
Supported protocols: DNS
- A resolver can resolve domain names using the protocol in question. E.g. dnsmasq and Unbound can resolve domain names over plain old unencrypted DNS over UDP, but dnscrypt-proxy and Stubby can't, they can only connect using encrypted protocols (not counting bootstraping used to resolve the domain name of the encrypted DNS server).
- A server can serve, i.e. answer received domain name queries, over the protocol in question. E.g. Knot Resolver and Unbound can answer queries using DNS over TLS, but systemd-resolved can't.
- "Yes" means that it can act both as a resolver and server.
- -- nl6720 (talk) 09:32, 13 May 2019 (UTC)
- (When I say DNS server, it is about the new column) I had some difficulties understanding how stubby and dnscrypt-proxy could be DNS server without having recursive or authoritative, and how they could not be resolver. Can you confirm that it means that such a DNS server can answer unencrypted DNS queries by resolving them using an encrypted connection to a proper DNS server ? And that they can't resolve encrypted queries ?
- If so, would it be possible to explicit the meaning of the 'server' and 'resolver' keywords for the supported protocols ? Also what about renaming DNS to Unencrypted / Standard DNS, or something more explicit ? -- Apollo22 (talk) 14:54, 13 May 2019 (UTC)
- The Domain name resolution#DNS servers section intro explains how a DNS server can be neither authoritative nor recursive.
- The "DNS" column is for the plain unencrypted DNS over UDP. And yes, dnscrypt-proxy listens on UDP port 53 and answers unencrypted queries, it then forwards them via an encrypted connection to another DNS server. Its DNS server functionality is only needed to use it in
/etc/resolv.conf. The alternative is to do it the way systemd-resolved does, with a NSS module.
- The reason why I added the resolver/server distinction is because the section is titled "DNS servers" and it's useful to know what they support serving. I haven't added a explanation for the terms because I can't think of a good description for them. -- nl6720 (talk) 12:07, 14 May 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)
Split DNS resolver
Mentionning glibc limitation
I mention glibc limitation concerning split dns resolver here because it is the standard DNS resolution mechanism in Linux. I mention it here because it explains why it is required to use a dns resolver. Maybe it should be in a note, but it think the explaination should be inline with the requirements.
- I think it's just another limitation of the glibc resolver, so Domain name resolution#Glibc resolver seems like the place for it. Maybe the entire Split DNS resolver section could be turned into a note and moved to Domain name resolution#Glibc resolver? -- nl6720 (talk) 13:35, 9 May 2019 (UTC)
Replacement of dnsmasq with "use a local resolver"
I mention dnsmasq because I know it supports it, and I don't know for others. It might be interesting to add a column in the DNS servers table. (I didn't have the time when I wrote the edit).
- I don't think dnsmasq does anything special for split DNS (correct me if I'm wrong). All proper DNS servers support forwarding requests to a specific name server for a specific domain. The configuration of the local resolver can be automated with resolvconf. So you basically should be able to use any of the resolvers that have Yes in the resolver column. -- nl6720 (talk) 13:29, 9 May 2019 (UTC)
- While systemd-resolved is indeed unproper, perhaps is was not the best word to describe them. The software that claims to be "DNS servers" should be able to setup forwarding manually. systemd-resolved (AFAIK) can't do that. The automated variant works with resolvers that can be configured with resolvconf, i.e. using openresolv subscribers or systemd-resolvconf. -- nl6720 (talk) 12:56, 12 May 2019 (UTC)
Template remove of Conditional forwarding
1. Does the Talk:Domain_name_resolution#Split_DNS_resolver (talk page section) refers to Domain_name_resolution#Conditional forwarding (main article section)? —This unsigned comment is by Regid (talk) 16:10, 23 May 2019. Please sign your posts with ~~~~!
- Yes it does, sorry about the confusion, my entrypoint was NetworkManager and NetworkManager called it 'split DNS'. Apollo22 (talk) 18:41, 23 May 2019 (UTC)
2. As for the template:remove for Domain_name_resolution#Conditional forwarding: Though I didn't work out all the details, I am quite sure that BIND's view configuration option will be able to handle conditional forwarding. Which is why it is not a pointless section, and does not deserves removing. If BIND can do it, others might do as well. Regid (talk) 00:13, 24 May 2019 (UTC)
- I am not sure we should put any server specific configuration here, but maybe links to the related section of each server (Bind#Conditional forwarding, dnsmasq#Conditional forwarding). Apollo22 (talk) 18:41, 23 May 2019 (UTC)
- I too think the Domain_name_resolution wiki entry is not the right place to put server specific configuration. The section Bind#Conditional forwarding, or Bind#Views, or whatever the right name is, doesn't exists at the time of this writing. For Unbound, it might be the already exists Unbound#Forwarding_queries. Regid (talk) 00:13, 24 May 2019 (UTC)
Implement DoT with stunnel on any server
Can't we use stunnel with any of the listed servers ? I am not sure if it is possible to forward every queries from the server to stunnel, or how to make every answer from the server go through stunnel (maybe use iptables ?) -- Apollo22 (talk) 21:01, 25 May 2019 (UTC)