i3D.net logo in blue
i3D.net logo in blue

No more scenic routing: How Quad9 localized DNS traffic across eastern Canada

Localizing DNS traffic across Eastern Canada

For globally distributed services, Canada presents a unique mix of opportunity and complexity. A dense population concentrated along the eastern corridor, strong expectations around data sovereignty, and a historical tendency for traffic to south of the border all place additional demands on network design.

Quad9, an anycast DNS resolver focused on security, privacy, and performance, had long identified Canada as a priority market. In collaboration with i3D.net, Quad9 recently completed a rollout that enables Canadian users to be served almost by Canadian-based infrastructure, keeping traffic local, reducing latency, and improving routing behavior across the region.

Quad9 partnered with i3D.net to tackle a long-standing issue: much of its Canadian DNS traffic was still being resolved via the US, despite local infrastructure.
This written customer story outlines the technical details behind focusing on DNS routing behavior, and their teams increasing local coverage from ~60% to over 95%. The accompanying video features a conversation between Zachary Gilman, Quad9, and Martijn Schmidt, i3D.net, sharing insights from both sides.

“Canadian users have been very vocal since the beginning of Quad9 that routing locally, on their own soil, really matters to them. This has been a problem we wanted to solve for a long time.”

Zachary Gilman, Manager, Network and Interconnection at Quad9

The challenge: Serving Canada locally in a cross-border-by-default internet ecosystem

Despite geographic proximity, much of eastern Canada’s internet traffic has historically been routed through major US metros such as New York, Ashburn or Chicago. For DNS resolvers, that dynamic introduces several challenges:

  • Data sovereignty concerns, which are important to many Canadian users
  • Higher latency, even though the distances involved are still relatively short
  • Geolocation side effects, where downstream content is served from the wrong region due to EDNS Client Subnet (ECS) being disabled by design for privacy reasons

For Quad9, these effects were amplified by a deliberate architectural choice.

“If 25 million people are routing to New York, Ashburn or Chicago, that puts pressure on metros that are already under load,” Gilman explains. “Fewer eggs in more baskets makes the entire network more resilient.”

Privacy-first DNS in a routing environment that assumes ECS

Many DNS resolvers rely on ECS to compensate for distant resolution points by sharing semi-anonymized client IP information. While this can improve content localization, it does so by sharing partially anonymized client IP information, typically a /24 for IPv4 (representing up to 256 unique IP addresses) or a /48 for IPv6.

In IPv6, a /48 contains 65,536 distinct /64 networks, each of which in turn contains 65,536 individual /128 addresses. Therefore, partial anonymization at this level does not represent a meaningful trade‑off in terms of user privacy However, since the mid‑2000s, industry guidance—including recommendations from the IPv6 Task Force and regional internet registries such as RIPE and ARIN—have treated a /48 as the standard allocation size per end site or subscriber (for example, a household or office building).

Quad9 deliberately avoids ECS because even these “anonymized” prefixes can still map to a small neighborhood, or even an individual subscriber. Under widely adopted RIR guidance, many ISPs allocate a /48 IPv6 prefix per subscriber, meaning ECS disclosure at this level can effectively identify a single household or organization.

Instead, Quad9 prioritizes privacy‑by‑default, supported by encrypted DNS protocols such as DNS over TLS, DNS over HTTPS, DNSCrypt, and emerging standards including DNS over QUIC and HTTP/3.

Routing without ECS: why proximity matters

This design choice has important routing implications. Without ECS, effective localization depends heavily on how close Quad9’s anycast infrastructure is to end users. When Canadian traffic was resolved through U.S.-based nodes, DNS answers could inadvertently steer downstream content delivery across borders, increasing latency and forcing ISPs to carry high‑volume traffic such as CDN workloads over long‑haul transit links.

For Quad9, this meant that even when users were physically located in places such as Ontario, Québec, or elsewhere in Eastern Canada, they would often resolve their DNS queries via US-based infrastructure and therefore get US-centric content served back to them.

Solving this required not just deploying compute in Canada, but ensuring that real-world routing behavior followed intent, across incumbents, IXPs, and tier‑1 transit paths.

The partnership: Extending an existing relationship into Canada

Quad9 and i3D.net had already worked together extensively across other regions. As i3D.net expanded its Canadian footprint, the timing aligned to address Quad9’s long-standing goals in the market.

“Adding Canada was the cherry on top. It helped complete our North American footprint and made our investments elsewhere more effective.”

Zachary Gilman, Manager, Network and Interconnection at Quad9

Beyond simply adding capacity, the collaboration focused on how traffic would behave under real-world conditions. That included close coordination between engineering teams on BGP communities, MED handling, backbone isolation, and anycast traffic steering. These details are often the difference between provisioned infrastructure and infrastructure that actually gets used.

Rollout: Engineering for predictable local routing

The rollout emphasized control and observability. Rather than treating Canada as an extension of the US backbone, the Canadian deployment was deliberately segmented through BGP Action Communities to prevent unintended spillover during maintenance or failure scenarios elsewhere.

During testing, the teams identified and resolved several routing edge cases, including Multi-Exit Discriminator (MED) interactions that caused some traffic to continue preferring US nodes. i3D.net implemented targeted policy adjustments, allowing Quad9 to enforce MED behavior aligned with its global anycast design.

“This wasn’t even an emergency—we were still testing,” Gilman notes. “The turnaround time from i3D.net was days, and that made a big difference.”

The result was a controlled, incremental ramp-up that allowed traffic to shift naturally while maintaining network stability.

Results: From partial coverage to near-total localization

Once full traffic was enabled, the impact was immediate and measurable. Traffic that had historically resolved through the US began shifting to Canadian nodes across Montreal and other eastern metros.

Key outcomes included:

  • Two of the largest eastern Canadian ISPs began routing to Quad9 locally
  • Dozens of smaller ISPs, government, and education networks shifted without prior coordination
  • Local coverage for eastern Canada increased from roughly 60% to well over 95%


“When we flipped the switches, the ASN graphs just changed shape,” Gilman says. “It was exactly the kind of shift you hope to see.”

In one case, a major Québec ISP independently detected the change and added Quad9 to its DNS forwarders within days, even before Quad9 had formally announced the rollout.

Takeaways for engineering teams operating infrastructure in Canada

Beyond Quad9, the project underscores several broader considerations for organizations operating infrastructure in Canada. It shows that a local presence alone is insufficient without thoughtful routing policy, as where DNS resolution occurs directly influences downstream content delivery.

For privacy‑oriented services that do not use ECS by design, this dependency on local interconnection becomes even more pronounced. As a result, IXPs, tier‑1 blends, and strong community relationships remain critical components of effective infrastructure strategy.

As Gilman puts it, “If you’re a distributed service, customers will notice when you become local. Sometimes within days.”

Looking ahead

For Quad9, the Canadian rollout closes one of the oldest open items in the organization’s network roadmap. For i3D.net, it reinforces a broader strategy of enabling customers to control traffic locality without sacrificing global reach.

“This felt like closing an eight‑year ticket,” Gilman reflects. “And the results exceeded our expectations.”

As Canada continues to attract hyperscalers and large-scale infrastructure—particularly in Québec—the need for well-engineered, locally routed Internet services is only set to grow. The collaboration between Quad9 and i3D.net offers a practical example of what it takes to make locality real in a market where geography, policy, and legacy routing behavior don’t always align by default.

View all Customer Stories

Related Articles

Read more
Quad9 customer logo
Company Description
Quad9 is a not-for-profit, free, recursive, Anycast DNS platform that provides end users robust security protections, high performance and privacy.
Industry
Enterprise
Products
Solutions
➜ Contact us