An Analysis of Responses to Mozilla’s Trusted Recursive Resolver Public Consultation

In 2019, the Mozilla Corporation introduced its Trusted Recursive Resolver (TRR) programme to complement the addition of support for DNS-over-HTTPS (DoH) by its Firefox browser. The TRR policy that underpins the programme “describes data collection and retention, transparency, and blocking policies and is in addition to any contractual, technical or operational requirements necessary to operate the resolver service”.

Currently, the TRR programme only covers North America, having recently been extended to Canada, but there have been suggestions that Mozilla is keen to expand its scope to other markets.

Public Consultation

Possibly as part of a plan to extend the scope of the programme, Mozilla undertook a public consultation into the TRR policy, which closed in January of this year. The consultation posed a number of questions and sought input from the community, with a total of 57 responses received and subsequently published by Mozilla on its Open Policy and Advocacy blog, including a response by this author.

At the time of writing, we are still waiting to see what conclusions Mozilla has reached since undertaking the consultation. It has, however, made an interim announcement relating to its requirement that participants in the TRR programme publish the full list of any domains that they block due to legal requirements:

“Therefore, while we reflect on the input regarding our TRR policies and solutions for blocking transparency, we will relax this blocklist publication requirement. As such, current or prospective TRR partners will not be required to mandatorily publish DNS blocklists from here on out.”

This is an important and positive change to the TRR policy, addressing an issue that has been raised repeatedly with Mozilla, both through the consultation and directly. It has been a barrier to the expansion of the TRR programme as, for example, it is illegal in some countries to publish details of sites containing child sex abuse material.

It is also undesirable to publish such information as it could inadvertently be used as a directory by some to facilitate access to the content in question. In addition, publishing details of malicious domains would indicate to authors of malware and similar content which of their domains are being blocked, enabling them to adapt their tactics accordingly.

What Alternatives to the TRR Policy Are There?

When the TRR programme was launched, concerns were raised about the way that DoH was enabled by default, bypassing any parental controls and other content filtering that may be in operation. In addition, the limited number of participating resolver operators engendered concerns about both lack of user choice and centralisation (at the launch of the programme, the only option was Cloudflare). Another issue that was aired at the time was the absence of any reference of adherence to legislative requirements.

As a result of discussions within the industry about issues with the TRR policy, we decided to develop and launch an alternative in the form of the European Resolver Policy. This addresses issues raised about the Mozilla TRR policy as well as including an explicit requirement to comply with GDPR and to incorporate operational practices that protect the privacy and security of users’ data, summarised previously here.

What Are the Main Themes of the Responses?

Whilst it is expected that Mozilla will publish a full response to the consultation in due course, this has been some time in coming. The following is the result of an analysis of the responses submitted, identifying key themes and concerns with the TRR policy and Mozilla’s approach as it currently stands.

Whilst the responses incorporated a wide range of views, the suggested changes to the TRR policy and Mozilla’s approach that came up most frequently are as follows:

• Respect user and/or system-wide settings and preferences, including those relating to DNS resolution.
• Respect local legislation relating to matters including privacy, content blocking and information retention.
• Allow (opt-in) content filtering within the TRR programme to address concerns about exposure to malicious content and to support parental controls, both of which are not possible with the current policy.
• Work with ISPs so that DoH is implemented more widely, ensuring more resolver choice and removing the need for users to share personal data with additional entities.
• Provide better support for the needs of enterprises including, for example, split-horizon DNS, a common requirement amongst enterprise users.
• Bring the TRR policy in line with GDPR, allowing users to avoid the need to share personal data with US-headquartered entities.

In addition, some responses highlighted the need to address issues relating to centralisation. This could be helped by increasing the number of resolver options, especially if more ISPs joined the programme so that users were not forced to rely on cloud-based DNS resolvers.

Beyond the points above, which were raised in multiple responses, the following points raised in individual responses stood out as items needing attention by Mozilla:

• Replace the current user dialogue that appears the first time Firefox installs with DoH, providing proper user information and avoiding the use of so-called dark patterns (defined as “a user interface that has been carefully crafted to trick users into doing things”).
• Where access to a domain is blocked by resolver filtering policies, improve the user experience by providing an explanatory notice rather than simply presenting an error message as currently required.
• Consider an industry-wide accreditation body to ensure uniformity of “auditing” and to reduce costs, noting that this may otherwise present a barrier to entry for smaller resolver operators.
• Expand the policy to include more detailed technical requirements, for example by giving information on maximum session lengths etc. Compliance with RFC 8932 which contains operational, policy, and security considerations for resolver operators, was also mentioned (The European Resolver Policy specifies compliance with section 5 of this document).
• Enhance the current DoH options supported by Firefox through the use of “same-provider auto-upgrade”, an option already adopted by, amongst others, Google in its Chrome browser.

Finally, some responses encouraged Mozilla to support standards-based resolver discovery methods when these are agreed upon within the Internet Engineering Task Force’s ADD working group. This would also help to boost the number of resolvers accessible within Firefox without requiring users to resort to significant manual configuration, something that ordinary users won’t do.

Conclusions

The content of the responses varies widely; it is clear however that more work is needed before Mozilla expands its TRR programme. In particular, Firefox must respect user and system settings, adapt its implementation to reflect the legislative requirements in different countries and allow content filtering to be implemented. If Firefox is to expand its footprint within enterprises, more work will also be required to address the specific needs of this use case.

More generally, some of the points raised relating to GDPR compliance will need careful consideration as it is clear from the comments in the responses that there are issues in the current TRR policy that are inconsistent with the requirements of the GDPR. Any expansion of the TRR programme to Europe will certainly need to address these.

Mozilla will publish its own findings relating to the TRR public consultation in due course. I look forward with interest to reading these to see whether we have drawn similar conclusions. It is clear to me however that, given the breadth of issues identified in the consultation responses, there are significant concerns that still need to be addressed before the TRR policy can be considered a useful tool that reassures users that their personal data is secure.