Talk:Domain name resolution

From ArchWiki
Jump to navigation Jump to search

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.

--Larivact (talk) 19:18, 2 January 2019 (UTC)

Resolver performance

The Glibc resolver does not cache queries. If you want local caching use systemd-resolved or set up a local caching DNS server and use 127.0.0.1 as your name server.

Tip:
  • The drill or dig lookup utilities report the query time.
  • A router usually sets its own caching resolver as the network's DNS server thus providing DNS cache for the whole network.
  • If it takes too long to switch to the next DNS server you can try decreasing the timeout.

DNS servers

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.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Fill in the unknowns. Add deadwoodAUR. (Discuss in Talk:Domain name resolution#)
Name Package Authoritative
/ Recursive
Cache resolvconf Validates
DNSSEC
DNS
over TLS
DNS
over HTTPS
dnscrypt-proxy1 dnscrypt-proxy No Yes No No No Yes
Rescached rescached-gitAUR No Yes Yes No No Limited2
Stubby stubby No No No Yes Yes No
systemd-resolved systemd No Yes Yes Yes Insecure3 No
dnsmasq dnsmasq Partial4 Yes Yes Yes No No
BIND bind Yes Yes Yes Yes ? ?
Knot Resolver knot-resolverAUR Yes Yes No Yes Yes No
MaraDNS maradnsAUR Yes Yes No No No No
pdnsd pdnsd Yes Permanent Yes No No No
PowerDNS Recursor powerdns-recursor Yes Yes No Yes ? ?
Unbound unbound Yes Yes Yes Yes Yes No
  1. Implements a DNSCrypt protocol client.
  2. Only forwards using DNS over HTTPS when Rescached itself is queried using DNS over HTTPS.[1]
  3. From resolved.conf(5): Note as the resolver is not capable of authenticating the server, it is vulnerable for "man-in-the-middle" attacks.[2] Also, the only supported mode is "opportunistic", which makes DNS-over-TLS vulnerable to "downgrade" attacks.[3]
  4. From Wikipedia: dnsmasq has limited authoritative support, intended for internal network use rather than public Internet use.

Authoritative-only servers

Name Package DNSSEC Geographic
balancing
gdnsd gdnsd No Yes
Knot DNS knot Yes No
NSD nsd No No
PowerDNS powerdns Yes Yes

Draft comments

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)
I think that any open DNS server can be abused for DNS amplification attacks and I don't see how running two servers helps in that regard. --Larivact (talk) 19:04, 3 January 2019 (UTC)
There are different reasons using two may be helpful - I now write "may" just as I wrote "some" above. Feature reduction is a widely taught common IT sec design strategy. There are a few names for it, e.g. [4]. --Indigo (talk) 18:18, 9 January 2019 (UTC)
Merged, closing this. --Larivact (talk) 17:17, 9 January 2019 (UTC)
I reopen. I don't have time now to look at the merge, which is rather complex - unfortunately starting from Special:Diff/562538 instead of above draft. I hope we don't have to roll back. --Indigo (talk) 18:18, 9 January 2019 (UTC)
I just copied the draft. --Larivact (talk) 18:38, 9 January 2019 (UTC)
Ok, good to know & easier. I will close this when finished. --Indigo (talk) 19:12, 9 January 2019 (UTC)
I just filled in gaps in the "auth" server table. Can I remove the "Fill in the unknowns" note? --Pspacek (talk)
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

Could you explain what you mean by "yes", "server" and "resolver" in the DNS part of the table ? Apollo22 (talk) 21:58, 12 May 2019 (UTC)

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)
Maybe a simple server: can receive DNS packets, resolver: can send DNS packets or server: answer DNS queries, resolver: make DNS queries, either in the notes at the bottom of the table, or directly in the supported protocols cell ? -- Apollo22 (talk) 12:24, 14 May 2019 (UTC)
I'd prefer the second option (server: answer DNS queries, resolver: make DNS queries) below the table. -- nl6720 (talk) 14:44, 15 May 2019 (UTC)

Some DNS servers flush the cache when the configuration changes

unbound and 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.

Apollo22 (talk) 09:33, 8 May 2019 (UTC)

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).

Apollo22 (talk) 09:33, 8 May 2019 (UTC)

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)
I am not sure all resolvers support it (for exemple stubby). I am sure all the ones compatible with openresolv are. Apollo22 (talk) 08:03, 11 May 2019 (UTC)
I didn't say all resolvers, but all proper DNS servers. -- nl6720 (talk) 08:58, 11 May 2019 (UTC)
The notion of proper DNS servers is blurry. And in this case some unproper DNS servers support conditional forwarding (for exemple systemd-resolved). Apollo22 (talk) 07:54, 12 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)