Talk:Domain name resolution

From ArchWiki
(Redirected from Talk:Resolv.conf)
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)