Talk:Domain name resolution

Contents

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

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.

Only forwards using DNS over HTTPS when Rescached itself is queried using DNS over HTTPS.[1]

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]

From Wikipedia: dnsmasq has limited authoritative support, intended for internal network use rather than public Internet use.

Authoritative-only servers

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)

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)