Russian TSPU Begins Intercepting UDP DNS Queries to Cloudflare and Google Public Resolvers
Starting approximately on the evening of August 26, Russia's TSPU system began intercepting open DNS queries directed at major public resolvers operated by Cloudflare and Google (1.1.1.1 and 8.8.8.8). Previously, only encrypted DoH endpoints from these providers were blocked.
Users immediately observed that DNS resolution for blocked domains now returns an NXDOMAIN response. The following example illustrates the behavior when querying YouTube and Rutracker:
- dig youtube.com @8.8.8.8 returns NXDOMAIN
- dig rutracker.org @1.1.1.1 returns NXDOMAIN
Tcpdump captures confirm that the NXDOMAIN reply is generated almost instantly, indicating local interception rather than a response from the actual resolver. The mechanism functions only over UDP; queries sent with the +tcp flag receive genuine A records from the original servers.
Further testing revealed that the interception relies on TTL-based routing manipulation. When a DNS query is first sent with TTL 2 (stopping just after the TSPU node) and then repeated with TTL 64, the second query often bypasses the filter and receives the real IP addresses. Sending random non-DNS packets with low TTL does not trigger the same effect.
In one notable case, a DNS query with TTL 2 elicited an ICMP TTL Exceeded message whose source IP was not 8.8.8.8 but 195.208.5.1, the address of the Russian NSDI server. This confirms that the TSPU performs destination NAT specifically on packets containing DNS queries, replacing the original resolver IP with the domestic NSDI address.
When multiple identical queries are sent in rapid succession within the same flow, the system occasionally fails and returns both NXDOMAIN and legitimate answers in quick succession. Network operators downstream of the TSPU will therefore observe a measurable drop in netflow records destined for foreign public DNS servers.
Related articles
HTTPS Lock Icon Present but List of Visited Sites Remains Visible
Even when HTTPS is active and passwords stay protected, DNS queries and the SNI field in TLS handshakes expose the exact domains a user visits over public Wi-Fi. Classic unencrypted DNS over UDP sends domain names in plaintext, allowing anyone on the same network to observe them with simple packet captures. The SNI extension reveals the target hostname before encryption is negotiated, enabling domain-based filtering without decrypting traffic. DNS over HTTPS moves queries inside encrypted channels but shifts visibility to the chosen resolver instead of the local network. Encrypted Client Hello offers partial protection for SNI yet requires support from both browsers and server infrastructure. The practical takeaway is that metadata about services used, timing, and frequency leaks more readily than credentials in modern public networks.
Google Develops Public Android API for On-Device Content Safety Classification
Google is creating a new public Android API that will allow third-party applications to analyze images and other files locally on the device and assign them one of four safety statuses. The system builds on the existing SafetyCore component already used in Google Messages to blur intimate images. ContentSafetyManager will process images, raw files, and multimedia content entirely on-device without transmitting data to Google servers. Applications will then decide whether to display, blur, or hide the content based on the classification result. Experts warn that malicious apps granted broad permissions could misuse the classifier to scan large volumes of user files and build detailed profiles. SafetyCore itself previously sparked controversy after being installed automatically without explicit user consent and without a visible icon, leading some users to install blockers to prevent reinstallation via the Play Store. Google continues to emphasize minimal permission requests and local processing as safeguards for user privacy.
WhatsApp Adds Support for Multiple Passkeys on Single Account
WhatsApp has expanded its account protection features by allowing users to register more than one passkey on the same profile. The update particularly benefits users who switch between Android and iOS devices while maintaining phishing-resistant login methods. Passkeys replace traditional codes and passwords with biometric authentication, facial recognition, or device lock mechanisms. Meta reports that more than one billion people already use the feature on WhatsApp, with Android support introduced in 2023 and iOS support added in 2024. The change reduces reliance on a single device during authentication by associating multiple keys with one account. Users can manage keys through Settings > Account > Passkeys. WhatsApp has also strengthened two-factor verification by allowing replacement of the six-digit PIN with longer passwords containing letters, numbers, and special characters.
Russian ISPs Begin Disrupting Encrypted DNS Services from Google and Cloudflare
Users of several major Russian internet providers have reported widespread issues accessing encrypted DNS protocols offered by Google and Cloudflare. The affected services include DNS over HTTPS (DoH) and DNS over TLS (DoT), which are designed to prevent providers from inspecting domain queries. Measurements show that connections to Cloudflare addresses 1.1.1.1 and 1.0.0.1 on port 853 establish TCP handshakes but are then reset with ECONNRESET errors before TLS authentication completes. Google Public DNS endpoints experience different interference, with sessions stalling after the TLS ClientHello or terminating with unexpected EOF errors. The disruptions have been observed across Rostelecom, Dom.ru, Tattelecom, and SkyNet subscribers, with varying impact depending on region and operator. Tattelecom support reportedly advised one customer to disable both protocols to restore connectivity. No official confirmation of centralized blocking has been issued, yet the coordinated pattern across multiple providers suggests deliberate interference rather than random failure.