Contemporary DNS software is very complex. Vendors and development teams lack feedback about the features that are actually in use. Our survey aimed to obtain such information from users. The results are described in this article. Users and administrators of DNS resolvers from any vendor were invited to participate in this survey. This post follows the article “Survey: How do you configure DNS resolvers?”.
The survey was conducted in mid-2020, so some users’ preferences may have changed in the meantime. A total of 337 respondents participated. Some questions were optional, so the number of respondents may vary.
Who answered
The following charts give us a better idea of the respondents, their use-cases and deployment sizes.
The following chart then shows the distribution of DNS resolver implementations used by our respondents. Only base implementations are shown, derived implementations are included.
Configuration
In this question, we asked the respondents how they modify the configuration of their resolvers. We also asked what methods they would like to use in the future.
We can see that most respondents modify the configuration files using a text editor. However, there is a significant demand to modify configuration via an unspecified form of API.
The next chart shows how often respondents modify the configuration.
Our next question focuses on the acceptable downtime to apply configuration changes. Respondents answered as follows.
Traffic filtering
In this section, we asked the respondents about DNS traffic filtering and their resolver policies.
data in the answer – e.g. blacklisted IP address
DNS “metadata” – e.g. IP address or name of authoritative DNS server
The following chart shows the most common actions when filtering rules are triggered. Some respondents also answered “drop connection” or “redirect to a different resolver”.
block answer on DNS level – e.g. answer with NXDOMAIN, REFUSED or NODATA
send back modified answer – e.g. answer with different IP address
We were also interested in the approximate number of these rules. The answers in “other” are significantly below or above the possible answers.
Future direction
It seems that clients will use a diverse set of protocols to communicate with DNS resolvers. This includes TLS, HTTPS or QUIC. The following chart shows respondents’ interest in these protocols and whether they prefer a built-in support or a proxy component.
The survey also inquired about the respondents’ opinion regarding automatic collection of metrics about configuration, so-called “call home”. This feature could make it easier for vendors to get feedback. In any case, this would not include traffic or any sensitive data.
list of options in use – e.g. local-data, forward-first, so_reuseport
list of options with frequency – e.g. 3 x local-data, 1x forward-first, 1x so_reuseport
redacted configuration – configuration file without appropriate names, IP address or comments, etc.
full configuration – actually used configuration (likely identifying particular deployment)
About half of the respondents would be willing to automatically share some data while the others are against it. Another question we asked also made it clear that this feature should be strictly opt-in (almost 90 % of respondents answered this way). Such limited means of automatic data collection most likely wouldn’t provide relevant feedback.
Conclusion
I would like to thank all the respondents for their participation and answers. I would also like to apologize for the late publication of the results. I believe that these results will help the future direction of DNS software development. For example, Knot Resolver is going to explore the possibility of configuration via an API in the upcoming versions.