Security/DOH-resolver-policy

Policy Requirements for Mozilla’s Trusted Recursive Resolver Program

This document describes the minimum set of policy requirements that a party must satisfy to be considered as a potential partner for Mozilla’s Trusted Recursive Resolver (TRR) program for DNS over HTTPS (DoH). It specifically 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. Parties interested in joining the TRR program should refer to the guidance given in “Applying for the TRR Program” below.

Mozilla’s current requirements – as detailed below – may be updated at its sole discretion as the community-defined best practices for DNS privacy evolve. If this happens, TRR partners will be notified 30 days in advance at minimum, longer for larger changes that require more time to implement, and will be required to begin complying with the updated requirements.

TRR partners must not charge users for use of their DoH service.

Discussion of these policies and of TRR applications occur on mozilla-trr-program-discuss@mozilla.com.

Privacy Requirements

Mozilla’s TRR is intended to provide better, minimum privacy guarantees to Firefox users than current, ad hoc provisioning of DNS services. As such, resolvers must strictly limit data collection and sharing from the resolver. More specifically:

1. The resolver may retain user data (including identifiable data, data associated with user IP addresses, and any non-aggregate anonymized data) but should do so only for the purpose of operating the service and must not retain that data for longer than 24 hours.

• Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours.
• All stored data requires access controls that limit access to operational support staff who require access to perform their duties.

2. The resolver must not retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser.

3. The resolver must not combine the data that it collects from queries with any other data in any way that can be used to identify individual end users.

4. The resolver must not sell, license, sublicense, or grant any rights to user data to any other person or entity.

5. The resolver must not propagate unnecessary information about queries to authoritative name servers. In particular, the client subnet DNS extension in RFC 7871 (or its most recent revision) must not be sent to servers unless the connection to the authoritative server is encrypted and only to authoritative name servers operated by the domain owner directly or by a DNS provider pursuant to its contract with the domain owner.

6. The resolver must support DNS Query Name Minimisation as defined in RFC 9156 (or its most recent revision).

7. The resolver must support padding policies for EDNS(0) as defined in RFC 8467 (or its most recent version).

Performance Requirements

1. The partner’s DoH resolver must be dual-stack, i.e., accessible over both IPv4 and IPv6.
2. Resolver performance should be comparable to DNS53 resolutions.
3. Under normal operation, the resolver must not close idle DoH connections any sooner than after 180 seconds. If lowering temporarily due to maintenance, the TRR partner must notify Mozilla ahead of the change. (Longer idle timeouts are encouraged, as they improve user experience.)
4. DoH resolver has deployed performance monitoring and alerting and will immediately notify Mozilla on observed performance issues and provide timelines to resolve.

Transparency Requirements

The party operating the resolver must be transparent about any data collection and sharing that does occur in accordance with the above requirements. More specifically:

1. Privacy Notice. There must be a public privacy notice specifically for the resolver service that documents the specific fields for data that will be retained for 24 hours and that documents specific fields for aggregate data that will be retained beyond 24 hours. The notice should also attest to requirements 2 - 5 above.
2. Transparency Report. There must be a transparency report published at least yearly that documents the policy for how the party operating the resolver will handle law enforcement requests for user data and that documents the types and number of requests received and answered, except to the extent such disclosure is prohibited by law.

Blocking & Modification Prohibitions

1. The party operating the resolver should not by default block or filter domains unless specifically required by law in the jurisdiction in which the resolver operates. Mozilla will generally seek to work with DNS resolvers that provide unfiltered DNS responses and, at its discretion, may remove from consideration resolvers subject to legal filtering obligations, depending on the scope and nature of those obligations.
2. For any filtering that does occur under the above requirement, unless prohibited by law, the party must maintain public documentation of all domains that are blocked and a log of when particular domains are added and removed from any blocklist. (Alternatively, a TRR partner may respond with error codes as described in draft-nottingham-public-resolver-errors when a user request is filtered in this way.)
3. When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content.

Enforcement

The decision of who to include in (or remove from) Mozilla’s Trusted Recursive Resolver (TRR) program is at Mozilla’s sole discretion, and we may evaluate additional factors such as abusive practices, relevant reputational developments, or other security concerns not specifically identified here. Any changes to a TRR partners’ published policies or operational changes that may render implemented processes not compliant to our requirements must be promptly communicated to Mozilla and may trigger a re-evaluation of the program membership. We intend to publicly document violations of this policy and take additional actions if necessary.

TRR Program Partner Types

Mozilla supports three types of TRR partners:

1. Regional default: Firefox will by default send DoH requests for all users within the designated region to this TRR partner. Note: It is rare that new TRR partners are directly added as regional default TRR partners. We strongly encourage you to apply as a regional non-default TRR partner first.

2. ISP Steering: Firefox will by default send DoH requests to ISP steering TRR partners while a user is on their network.

3. Regional (or global) non-default: Firefox will list non-default TRR partners in the browsers settings, allowing users to manually configure them as an alternate provider. (Regional default TRR partners may also apply to be shown as non-defaults outside their region.)

When a user is in default protection mode, i.e., is using the Firefox default settings, regional default partners and ISP steering partners are enabled, with ISP steering partners taking precedence for users on the ISP partner’s network. When a user has manually selected a TRR partner or configured a third-party DoH provider in the preferences, their choice always takes precedence.

Application Process

Applying to join Mozilla’s TRR program follows this process:

1. Submit a bugzilla ticket to initiate your application. Once submitted this ticket can be used to track the application process.

2. Information verification.

3. Public discussion and review (4 weeks).

4. Mozilla legal review (Mozilla/applicant internal).

5. Contracted service providers will be integrated into Firefox DoH settings and listed as a conforming resolver.

Applying for the TRR Program

Parties operating resolvers that are interested in joining the TRR program may apply. An official representative of the service provider may submit their request using Mozilla’s Bugzilla issue tracking system. Please make sure the information you provide covers all the requirements set out above. Mozilla prefers links to publicly available information whenever possible:

1. If you don’t already have a Bugzilla account, create an account for yourself.

• Note that you must supply an email address when creating an account; this address will be made public, and will be used for communications related to your request.

• Be sure to use an email address that you regularly monitor, because all communication regarding the request will be sent to this email address.

2. Create a new bug report corresponding to your request.

• https://bugzilla.mozilla.org/enter_bug.cgi

• Product: DoH TRR Program

• Component: TRR Application

• Type: task

• Severity: N/A

• Summary: TRR Application [Name of Organization]

• Do NOT select the check boxes to restrict visibility, such as making it confidential or marking it as a security bug. All information that is submitted for inclusion and update requests must be publicly available.

3. Provide all information as mentioned in the ‘Required Information’ section below.

4. Watch for email from bugzilla-daemon@mozilla.org containing additional requests for information.

• It is recommended that you add bugzilla-daemon@mozilla.org to your email contacts so that notifications of updates to your bug don’t get filtered into your SPAM folder.

IMPORTANT: Note that all information submitted to our Bugzilla system is publicly available to anyone on the Internet. Please do not include proprietary or confidential information in your request. If you wish to discuss confidential or sensitive matters, please do so via private email to mozilla-trr-program-apply@mozilla.com. Mozilla’s process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available.

Required Information

1. Name of legal entity applying for the TRR program, corporate address, public website, documentation of incorporation (including information where this can be verified, e.g. Certificate of Good Standing or URL of government-maintained lookup website).

2. Ownership structure (beneficial owners, publicly traded, for-profit, non-profit, government, etc.)

3. Link to a privacy policy, addressing the TRR program’s privacy requirements detailed above.

4. Link to a transparency policy, addressing the TRR program’s transparency requirements detailed above.

5. Link to a policy on filtering and law enforcement request handling policy, addressing the blocking & modification requirements detailed above.

6. Links to any relevant certifications or audits (e.g., SOC, ISO/IEC 27001, etc., if any)

7. References from the privacy and security community (if any).

8. Desired TRR Program Partner type (Regional Default, Regional Non-default, ISP Steering).

9. Regions/geographies the resolver proposes to serve, and current resolver capacity and scale-out contingency plans in those regions. (If the applicant intends to serve those regions from other locations, which are those? Is the service being outsourced to a third party?)

10. Information about the history of service availability. Include links to resolver operational incidents and status dashboards, if any.

11. Information about resolver performance. Include links to performance dashboards, if any. Performance should be comparable to existing TRR partners.

Approved providers must enter into a legal agreement with Mozilla governing participation in the program.

Current TRR Partners

The following providers have contractually agreed to abide by these requirements:

TRR Partner		Partner Type	Region
CIRA	Privacy policy	Regional Default	CA
Cloudflare	Privacy policy	Regional Default, Global non-default	US, RU, UA
Comcast	Privacy policy	ISP Steering	US-Comcast Network
NextDNS	Privacy policy	Global non-default	Global
Shaw	Privacy policy	ISP Steering	CA-Shaw Network