When a Family-Filtered DNS Service Over-Blocks

Today’s launch of 1.1.1.1 for Families — a filtered DNS service built on top of our existing resolver — included a mistake that briefly caused a number of LGBTQIA+ websites to be blocked. This is what happened, why it happened, and what we changed to prevent a repeat.

The new service acts as an optional layer on top of the standard, unfiltered 1.1.1.1 public DNS resolver. Many users wanted a way to restrict content on home networks. To meet that demand, we shipped two default filtering tiers at launch:

  • 1.1.1.2 and 1.0.0.2 — blocking malware.
  • 1.1.1.3 and 1.0.0.3 — blocking malware and adult content.

The goal for the Adult Content category was to mirror the definition used by Google SafeSearch, which focuses on sexual content in line with the US Children’s Internet Protection Act (CIPA). The intent was a narrow category, not a broad sweep of related content.

An Incorrect Category Feed in the Build

To build the classification lists, we licensed data from third-party providers that specialize in categorizing websites. For the Adult Content category, we spent months vetting providers, aiming for the one whose categorization best matched SafeSearch/CIPA criteria.

The mistake came from a mismatch in provider taxonomies. One vendor offered multiple "Adult Content" categories: one that closely followed SafeSearch/CIPA, and another that was broader and included LGBTQIA+ sites. During the months of review, we deliberately selected the narrow category. However, in the production build released this morning, the wrong category from that provider was included. As a result, 1.1.1.3 was initially filtering a much wider set of sites than we intended — including LGBTQIA+ content.

Identification and Initial Mitigation

Generation of the distributed blocklist uses a compact data structure designed for fast and efficient replication across our worldwide network. The tradeoff is that producing a fresh version of that structure takes several hours.

As soon as we realized the error, we removed the incorrect data provider and started regenerating the list. In the interim, we built an allowlist of individual domains that we continuously updated from user reports and other LGBTQIA+ resource lists. Those allowlist entries propagated immediately while the corrected data structure was being rebuilt.

By 16:51 UTC — roughly two hours after the first blocking report — the regenerated data structure containing the intended Adult Content definition was pushed live. Notably, users of 1.1.1.1 and 1.1.1.2 were not affected by the over-blocking. Only those who had already switched their resolvers to 1.1.1.3 were impacted during the window.

The default filtering on 1.1.1.3 is now what we intended: content that would generally be filtered by Google SafeSearch, with LGBTQIA+ sites no longer blocked. Anyone encountering a site that seems incorrectly blocked can report it at:

https://report.teams.cloudflare.com/

Preventing Future Mistakes

To reduce the chance of this recurring, we have added checks for known sites that should be outside the intended categories — including many that were mistakenly blocked earlier today. Before any future default configuration updates, our build system will verify that none of these domains appear in the list.

We understand the impact such an error had on the LGBTQIA+ community and other users. It was not an intended part of the service, and we are taking steps to ensure the classification pipeline is as rigorous as our original provider vetting.