quak.

Today I learned: apart from common CamelCase and snake_case naming conventions we also have the kebab-case. Best name IMO

One more reason to perform RPKI & ASPA ROV. The attack surface is real, don't wait until you get impacted.

This summer you have a unique opportunity to find a critical RCE in curl/libcurl using your fancy multi-stage AI pipeline and sell it to threat actors for many money, so that they can do bad things to half of the internet, until the vulnerability eventually gets patched somewhen after August 3rd 😉

In the previous post I briefly mentioned the DNS protocol. If you somehow managed to find my channel, I'm sure you have at least a basic understanding of it. In short, it is (primarily) responsible for keeping the web resource addressing human-friendly by providing memorable aliases for IP addresses, commonly referred to as "domain names". At the core of this system are ~2000 root name servers distributed around the globe, which are heavily anycasted to be reachable via only 13 IPv4/6 addresses and perform load balancing. Those are hard-coded into all recursive resolvers to be used by your devices for getting information on all available TLDs (top-level domains like .com, .net, .de).

By now this protocol has grown way beyond its initial purpose, offering dozens of additional record types used by mail servers, certificate authorities and hundreds of thousands of generic applications. The TXT record alone offers an infinite amount of exotic use-cases, including (but not limited to) using it as a file storage, to play DOOM, running a TCP proxy and much more.

As with many early protocols, DNS (in its original form) suffers a lack of security. To be exact, it doesn't offer any of confidentiality (encryption), integrity (modification protection) or authenticity (of the source) of the data. This flaw is actively used by many countries to restrict access to certain domains (as seen in one of previous posts), but also by threat actors to redirect (un)encrypted traffic from legitimate resources to their own machines.

Side note: Starting from 2021, the Russian government operates "НСДИ" (NSDI, "National System for Domain Names"), which provides recursive resolvers and alternative root name servers, which are required to be used by ISPs (and, preferably, their clients too). I wasn't able to find any reports indicating a difference of the national root zone to the global one, but there are certain blocked domains when using their recursive resolver.

To migrate these issues, two protection mechanisms were introduces: DoX ("DNS-over-X", insert T for "TLS", H for "HTTPS", Q for "QUIC" instead of X) and DNSSEC. The first measure implements a secure underlay channel for the transmission, but does not guarantee the "honesty" of the used recursive resolver. DNSSEC solves this problem by providing signed responses with the possibility to verify their chain of trust up to the root name servers. An "authoritative" extension to "DoX" is currently being deployed to additionally secure the communication between your recursive resolver and its targets.

Both methods come with limitations, as "DNS-over-X" is prone to protocol- / domain-based blocking (with DoT / DoQ without enforced certificate validation being vulnerable to targeted MITM attacks), while DNSSEC is still missing for some TLDs and may cause some (un/)funny effects upon unsuccessful signing key rotation (1, 2).

#dns #quic #networking #dpi #firewall

A note on QUIC protocol

QUIC is a relatively new transport protocol standardized in RFC 9000 (2021), which aims to provide secure, reliable and fast data transfer over UDP. Combined with HTTP/3 protocol it reduces the overhead of the handshake (compared to HTTP/2 with TLS and TCP), solves the head-of-line blocking problem and makes SNI-based censorship more difficult for an on-line observer (e.g. ISP). However, it does come at a cost.

As with any attempt to improve the internet on a global scale, the adoption of the new technology takes an eternity and meets resistance from individual states if they see a risk in it; so does QUIC. Despite being implemented in the majority of browsers and server-side engines, the use of HTTP/3 is only at ~30% of the three HTTP protocols, as per Cloudflare Radar. All this despite HTTP/3 with QUIC being available (and enabled) for all plans.

Trying to blindly connect to port 443 via UDP would be a waste of time due to a large number of websites ignoring the existence of QUIC. Thus, two independent helpers may inform the client about its availability. An Alt-Svc response header may be used to specify the port QUIC is listening on, but requires an initial TCP / TLS connection to the website. A measurement documented by Geoff Hutson from APNIC (as of June 2025) shows a clear sign of the Chrome browser relying on this method, performing a QUIC connection only on the second attempt (after the header was observed). Safari, on the other hand, queries for HTTPS DNS record of the target domain to check for "h3" ALPN support. This record comes with lots of useful information (IPv4 and IPv6 hints, ECH and supported ALPNs) and improves the "time-to-QUIC", as it does not require a preceding TCP connection to the website.

As mentioned, QUIC also makes DPI-based per-domain access lists more difficult, as the protocol does not carry SNI in plaintext, contrary to TLS (without ECH extension). However, this does not stop certain country-scale firewalls from using packet decryption, as all necessary encryption parameters are present in the handshake, unfortunately. This process comes at the expense of compute resources, as such the protocol may be completely blocked in some cases.

In my opinion, the protocol has lots of potential for improving the overall user experience in the "World Wide Web". Apart from the examples with HTTP/3 it has also found its use with DNS, both as an underlay (DoQ) and overlay (spoiler alert), which additionally improve the privacy and availability of the resources.

#http #quic #networking #dpi #firewall

On the importance of MTU value for peer-to-peer tunnels

An incorrect, too large MTU (Maximum Transmission Unit) value may cause unexpected behavior of a link between two machines. It is particurlarly difficult to determine the root cause of working pings, but certain transmissions failing, especially if you've never had this problem before. I've had two cases where the connection success rate to different websites through a tunnel (GRE / WireGuard) was seemingly random, until you open Wireshark and notice a bunch of fragmented packets on your physical interface.

The maximum allowed MTU between two machines (=PMTU, "Path MTU") is determined by the lowest MTU of any intermediate node. The most straight-forward way to determine this value involves using ping with variable data size and DF ("Don't Fragment") flag set, until you get error-free bidirectional transmissions:
# 1500 MTU = 20 IPv4 header + 8 ICMP header + 1472 bytes ICMP data
# Lower this value to get error-free transmissions
ping -c 3 -M do -s 1472
However, wire-seek does essentially the same (but automated and more efficient) and has additional support for WireGuard tunnel MTU discovery.

It is important to note that due to (possible) asymmetric routing through the internet between two machines, this value may be different on either side. Additionally, weird per-packet or per-protocol processing rules on intermediate nodes may lower this value for your tunnel. A direct MTU (via the IPv4 underlay network) of 1492 to a peer does not necessarily mean an MTU of 1432 (60 bytes IPv4 WireGuard overhead) within a tunnel. The solution to my fragmentation problems was to run MTU discovery inside the tunnel and apply it to its interface:
ip link set mtu dev
Or add the following to WireGuard configuration for persistance:
[Interface]
MTU =

Got a possibility to test internet access on a Russian residential IP. Most russian websites work fine, unless you want more freedom. The screenshots above are from the dpi-detector tool towards foreign resources, and the results were somewhat expected:
1. Plain UDP DNS spoofing
2. Blacklisted domains (on this vantage point) mostly L3/IP blocked (otherwise SYN would go through)
3-4. Cloud provider connectivity restricted / blocked (16-20 KB block)
5. Telegram connectivity fails (DNS spoofing, Down/uplink/DC unavailable)

The general statistics on the last image (lines 2-3) indicate only 17% of the tested domains and 13% of cloud provider address spaces accessible. This much better compared to the current network situation in Iran, but worse than it was just three months ago (AS-based blacklists and Telegram restrictions have been added since). It doesn't seem like the restrictions will be lifted anytime soon (apart from the time before elections in autumn 2026, maybe). On the contrary:

▶️ the total throughput of DPI system is expected to double by 2030. The budget of the digital control program was raised accordingly.
▶️ large tech companies heavily cooperate with authorities and might use their client-side apps to collect information about VPN servers a device is connected to (particularly on Android). The widely used state-promoted Max messenger has already been suspected to have this behavior.
▶️ about 20 companies that own foreign telecommunications links in Russia have signed an agreement to halt their expansion to enforce VPN detection / blocking by the operators. Alternatively, this may cause all international traffic to be billed at a higher price. A similar pricing model for large amount of mobile traffic towards foreign services should be enforced by mobile operators already this year.

This topic is particularly interesting for me, both from the technical perspective and because I have grandparents in Russia. My grandfather, also an engineer, used to find lots of useful information on YouTube, which was one of the first targets to be hit.
The expansion of digital surveillance took WhatsApp as the first communication channel, and has significantly disrupted Telegram for us. The most convenient way of communication for now is the state-sponsored Max messenger, which I personally don't want to use. Of course, there are methods to bypass the "firewall", a LOT of them, but none of them can be configured by an elderly person on their own.
I am responsible for keeping YouTube alive, and want to keep Telegram video calls working for them, at least for some more time. I may periodically post updates on the digital censorship in Russia and hope to have some good news for you one day (hopefully not about another sophisticated VPN obfuscation method).

If you want an overview / in-depth review of the network protocols used by Russians to access the outer world, you may show some activity under this post :)

#russia #dpi #networking #firewall