Réduire la latence sur les réseaux WiFi haute densité

PODCAST SCRIPT — "Reducing Latency on High-Density WiFi Networks" Running time: approximately 10 minutes Voice: UK English, male, senior consultant tone — confident, conversational, authoritative. --- [INTRO — approximately 1 minute] Welcome back. I'm going to cut straight to it today, because this is one of those topics where the gap between what most teams are doing and what they should be doing is genuinely costing them. We're talking about latency on high-density WiFi networks — and specifically, why DNS is the hidden culprit that almost nobody is looking at. If you're running WiFi across a hotel, a stadium, a conference centre, or a large retail estate, you've almost certainly had the conversation: "The network is slow." And the instinct is always to look at access point density, channel utilisation, or backhaul capacity. Those matter. But there's a layer underneath all of that — the DNS layer — where you can be haemorrhaging latency on every single device, for every single page load, before a single byte of actual content has moved. That's what we're going to unpack today. I'll walk you through the technical mechanics, give you two concrete implementation scenarios, and leave you with a clear set of actions you can take back to your team this week. --- [TECHNICAL DEEP-DIVE — approximately 5 minutes] Let's start with the fundamentals. When a device connects to your WiFi and a user opens a browser or an app, what actually happens first? Before any content is fetched, the device needs to resolve domain names to IP addresses. That's DNS. And on a modern smartphone, a single page load — say, a news article or a hotel booking page — can trigger anywhere between 20 and 70 DNS queries. Not because the page itself has 70 domains, but because the page is loaded with third-party tracking pixels, advertising scripts, analytics beacons, and social media widgets. Each of those fires a DNS lookup. Now, in a normal home or office environment with a handful of devices, this is largely invisible. The DNS resolver handles it, the TTL cache does its job, and the overhead is negligible. But put 500 devices on the same access point cluster at a conference, or 3,000 guests in a hotel at peak check-in time, and you have a DNS query storm. Your local resolver — if you even have one — is fielding tens of thousands of queries per minute, a significant proportion of which are going out to the public internet to resolve domains for ad networks and tracking services that will never actually load content the user cares about. Here's the critical insight: every one of those unnecessary DNS lookups adds latency to the user's perceived experience. We're not talking about the content load time — we're talking about the pre-load resolution time. On a congested network, a single DNS query to an external resolver can take 80 to 150 milliseconds. If a page fires 15 tracking domain lookups before it starts loading the actual content, you've just added over a second of invisible delay before the user sees anything. That's not a backhaul problem. That's a DNS problem. The solution has two components. First, deploy a local DNS resolver — ideally on-premises or at the edge of your network — with aggressive caching. Unbound, Pi-hole in enterprise mode, or commercial equivalents from vendors like Cisco Umbrella or Infoblox all work well here. The goal is to resolve the majority of queries from cache, sub-5 milliseconds, without hitting the public internet at all. For a high-density venue, you should be targeting a cache hit rate above 70 percent for steady-state operation. Second, and this is where the real gains come from: implement DNS filtering to drop queries for known tracking, advertising, and telemetry domains at the resolver level. When a query arrives for a known ad-network domain, the resolver returns NXDOMAIN — domain not found — instantly, in under a millisecond. The device gets its answer, stops waiting, and moves on to the next lookup. You've eliminated the round-trip to the public internet entirely. Multiply that by 15 tracking domains per page load, across 500 concurrent devices, and the aggregate reduction in DNS query volume — and therefore latency — is substantial. There's an important nuance here around DNS over HTTPS, or DoH. Modern browsers and operating systems are increasingly bypassing your local resolver entirely by sending DNS queries directly to DoH providers like Cloudflare or Google over encrypted HTTPS. This is excellent for privacy in consumer contexts, but it completely undermines your local caching and filtering strategy in a managed venue environment. You need to intercept or redirect DoH traffic at the firewall level, or deploy your own DoH resolver that devices can be directed to via DHCP option 6 and network policy. This is a growing area of complexity — if you want a deeper dive on the DoH implications specifically, Purple has a dedicated guide on DNS over HTTPS for public WiFi filtering that's worth reading. Now, let's layer in the RF side, because DNS optimisation doesn't exist in a vacuum. In a high-density deployment, you're typically running 802.11ax — WiFi 6 or WiFi 6E — with OFDMA and BSS Colouring to manage co-channel interference. The reason DNS matters even more in these environments is that OFDMA's efficiency gains are predicated on the assumption that the radio medium is being used for actual data transfer, not for the overhead of resolving hundreds of unnecessary domain names. Every DNS query that goes out to the internet is a small packet that occupies a transmission opportunity. At scale, that overhead is measurable in throughput terms. The combination of local DNS caching, tracking domain filtering, and a well-tuned 802.11ax radio environment is where you start seeing the step-change improvements. We're talking about reducing perceived page load latency by 60 to 87 percent in real-world deployments, not in lab conditions. --- [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes] Right, let's get practical. If you're scoping this for a deployment, here's how I'd approach it. Start with a DNS audit. Before you touch anything, instrument your existing resolver — or deploy a passive DNS tap — and capture query logs for 24 to 48 hours. You'll almost certainly find that 30 to 50 percent of your query volume is going to a relatively small set of tracking and advertising domains. That's your low-hanging fruit. Next, deploy a local resolver with a curated blocklist. I'd recommend starting with a conservative list — something like the Steven Black consolidated hosts list or a commercial equivalent — rather than an aggressive one. You want to avoid blocking domains that legitimate applications depend on. Test in a staging VLAN before rolling out to production. For the DoH interception, you'll need to work at the firewall level. Block outbound TCP and UDP port 443 to known DoH provider IP ranges — Cloudflare's 1.1.1.1, Google's 8.8.8.8 — and redirect those queries to your local DoH resolver. This requires coordination with your security team, particularly if you're in a PCI DSS or GDPR-sensitive environment, because you're effectively performing a form of DNS inspection. Document it, get sign-off, and make sure your captive portal terms of service reflect the filtering policy. The biggest pitfall I see is teams deploying filtering too aggressively and then getting support calls because a specific application has stopped working. Build in a rapid-response process for domain whitelist requests, and monitor your NXDOMAIN response rates. If they spike suddenly, something has changed in a legitimate application's DNS dependencies. The second pitfall is treating this as a one-time configuration rather than an ongoing operational task. Tracking domains change. New ad networks emerge. Your blocklist needs to be updated regularly — at minimum monthly, ideally weekly via an automated feed. --- [RAPID-FIRE Q&A — approximately 1 minute] A few questions I get asked regularly on this topic. "Does DNS filtering affect GDPR compliance?" — It can actually help. By preventing tracking domain resolution, you're reducing the data that third-party ad networks can collect about your guests. That said, document your filtering policy and include it in your privacy notice. "What about split DNS for internal resources?" — Absolutely necessary. Your local resolver should have authoritative zones for any internal hostnames, and those should never be forwarded externally. Standard practice, but worth stating. "Can I do this on a cloud-managed WiFi platform?" — Yes, most enterprise platforms — Cisco Meraki, Juniper Mist, Aruba Central — support custom DNS server assignment via DHCP. You point devices at your local resolver, and the filtering happens there regardless of which cloud platform manages your APs. "What's the ROI case for this?" — Guest satisfaction scores, reduced support ticket volume for slow WiFi complaints, and measurable improvements in captive portal load times. For a hotel, that translates directly to review scores. For a conference venue, it's the difference between a rebooking and a lost client. --- [SUMMARY AND NEXT STEPS — approximately 1 minute] To wrap up: the single highest-impact, lowest-cost intervention you can make to reduce WiFi latency in a high-density venue is to deploy a local DNS resolver with tracking domain filtering. It addresses the root cause of a significant proportion of perceived latency — not the RF environment, not the backhaul, but the DNS query storm generated by every device on your network resolving domains for content that will never load. Your action list: run a DNS audit this week, scope a local resolver deployment, and get a blocklist strategy agreed with your security team. If you're dealing with DoH bypass, that's the next layer to tackle. Purple's [Guest WiFi] platform and [WiFi Analytics] tooling are built with exactly this kind of network intelligence in mind — if you want to see how DNS optimisation fits into a broader venue WiFi strategy, the team at Purple is worth a conversation. Thanks for listening. See you next time. --- END OF SCRIPT