DNS Spoofing: How to Intercept an RTMP Stream

⏱️ Reading time: 14 min

A game console can stream live to a server that never belonged to Twitch or YouTube, without the console noticing the change: the technique that makes this possible is called DNS spoofing, and it takes advantage of the fact that RTMP, the streaming protocol, blindly trusts whatever the DNS responds with.

📑 En este artículo

1. TL;DR
2. What Is DNS Spoofing?
3. Why It Matters
4. How the RTMP Protocol Works
   1. RTMP: Handshake, Chunks, and Messages
   2. The Weak Link: How the Device Finds Its Server
   3. Where Spoofing Fails: TLS and Certificates
5. Practical Examples and How to Get Started
   1. Your Own Lab: Reproducing the Mechanism Without Touching Third-Party Services
6. Real Use Cases
7. Common Mistakes and Best Practices
8. Comparison with Alternatives
9. Going Deeper
10. Frequently Asked Questions
    1. How is DNS poisoning different from an ARP spoofing attack?
    2. Why can’t RTMPS be intercepted with the same DNS resolution spoofing?
    3. Is DNS spoofing legal on my own network?
    4. What is DNS over HTTPS and how does it affect DNS poisoning?
    5. Can DNS redirection be used to access paid streaming without authorization?
11. References

That blind spot is the basis of a network technique a researcher used to redirect a PlayStation 5’s native streaming to his own home server, without touching the console or breaking any of Sony’s protections. This article explains how RTMP works, why DNS is its weak point, and how to reproduce the mechanism in your own lab.

TL;DR

• RTMP sends audio and video in real time over TCP, and many devices resolve their server by domain name before streaming.
• DNS redirection changes that resolution so the device streams to your own server instead of the official one.
• RTMPS with TLS blocks interception through certificate validation; plain RTMP over port 1935 does not.
• dnsmasq rewrites the response and nginx-rtmp receives the stream as if it were the original server.
• A real attack against a PS5 served as a lab for understanding where streaming security fails and where it doesn’t.

What Is DNS Spoofing?

DNS spoofing is a network manipulation technique in which an attacker or administrator falsifies the domain name system’s response so that a device resolves a legitimate domain to a different IP address than the real one, redirecting any subsequent connection without the application noticing.

The technique doesn’t attack the streaming protocol itself, but the layer before it: name resolution. Any device that discovers a server by domain name instead of a fixed IP is vulnerable to this kind of redirection if the DNS resolver it uses isn’t protected. It’s also known as DNS poisoning, and it’s one of the oldest traffic manipulation vectors on the internet.

Why It Matters

This technique matters because much of today’s hardware (consoles, smart TVs, IP cameras, voice assistants) discovers its cloud servers by domain name, not a fixed address. That simplifies maintenance on the provider’s side: it can move, scale, or decommission a server without touching the firmware on millions of devices.

The cost of that convenience is that the device never verifies who it’s actually talking to beyond resolving a name. If someone controls that resolution (a compromised router, a fake Wi-Fi access point, or simply the administrator of your own network) they can decide where the traffic goes without the user noticing anything odd on screen.

Understanding name resolution manipulation serves two opposite purposes: a red team auditing how well an IoT device validates its connections, and anyone who wants to understand why modern defenses like DNSSEC or encrypted DNS exist.

How the RTMP Protocol Works

RTMP (Real-Time Messaging Protocol) is the protocol Macromedia designed in the early 2000s for live Flash streaming, which Adobe inherited after acquiring Macromedia in 2005. It’s still the de facto standard for streaming to Twitch and YouTube from consoles, cameras, and software like OBS.

RTMP: Handshake, Chunks, and Messages

An RTMP session starts with a three-step handshake (C0/C1/C2 on the client side, S0/S1/S2 on the server side) that synchronizes clock and protocol version before a single byte of video is sent. Once that handshake is done, video and audio travel split into chunks, small fragments that are interleaved so audio doesn’t have to wait for a heavy video frame.

Each chunk belongs to an RTMP message of a specific type: video, audio, metadata, or session control. It’s a binary protocol, with no text fields, designed for low latency over TCP on port 1935.

flowchart TD
    A["Handshake (C0/C1/C2, S0/S1/S2)"] --> B["Split into chunks"]
    B --> C["RTMP messages: audio, video, control"]
    C --> D[("Ingest server")]

That’s how any RTMP transmission is structured before reaching a real or fake server: the protocol doesn’t change depending on who’s on the other end.

The Weak Link: How the Device Finds Its Server

Before streaming, many RTMP clients don’t use a fixed IP: they first ask a discovery endpoint which regional server is closest. In Twitch’s case, the client resolves an ingest domain like ingest.global-contribute.live-video.net, and that domain, through DNS, points to a specific regional server based on location.

That intermediate step is exactly what can be hijacked. If the DNS resolver the device uses responds with an IP different from the real one, the client never knows: as far as it’s concerned, it’s still talking to the same domain name as always.

sequenceDiagram
    participant D as Device
    participant R as DNS Resolver
    participant I as Real ingest server
    D->>R: queries the ingest domain
    R-->>D: responds with the official IP
    D->>I: connects and streams via RTMP
    I-->>D: confirms the stream was received

Where Spoofing Fails: TLS and Certificates

The redirection works perfectly against plain RTMP, but not against its encrypted variant. RTMPS wraps the same conversation in TLS, usually over port 443, and the client validates the server’s certificate against a list of trusted certificate authorities. A server of your own with a self-signed certificate doesn’t pass that validation, and on a closed device like a console there’s no way to install a custom CA.

That’s why the technique documented against the PS5 targeted an ingest endpoint that uses plain RTMP on port 1935 instead of the HTTPS discovery endpoint. Even so, there was an additional obstacle: some providers verify on their API side that the stream actually arrived, and if it never does, they cut the transmission after a short while, even if the device keeps sending data.

sequenceDiagram
    participant D as Device
    participant R as Local DNS resolver
    participant A as Own server
    D->>R: queries the same ingest domain
    R-->>D: responds with the IP of the own server
    D->>A: connects thinking it's the provider
    A-->>D: accepts the RTMP connection
    Note over D,A: the device never detects the change

The result is that DNS resolution spoofing moves the stream’s destination, but doesn’t change a single line of firmware or break any encryption. The device believes it’s still talking to the original provider.

Practical Examples and How to Get Started

The rest of this section builds a lab with two open source services: dnsmasq for the fake resolution and the nginx-rtmp module to receive the stream. To avoid targeting any provider’s real infrastructure, the example uses your own test domain instead of a Twitch or YouTube domain: the mechanism is identical, only the name changes.

Your Own Lab: Reproducing the Mechanism Without Touching Third-Party Services

You’ll need a Linux machine (a Raspberry Pi, a VM, or your own laptop will work) with administrator permissions. Install dnsmasq as the resolver, nginx with the RTMP module as the receiver, and ffmpeg to generate a test stream without depending on any external file.

sudo apt update
sudo apt install -y dnsmasq nginx libnginx-mod-rtmp ffmpeg

On macOS you can install the same components with Homebrew (brew install dnsmasq nginx-full ffmpeg); on Windows, dnsmasq doesn’t have a direct equivalent, so the simplest alternative is to run this same lab inside a Linux VM or WSL2.

Configure dnsmasq to resolve a test domain to your own machine. The line server=1.1.1.1 forwards everything else to Cloudflare, so the rest of your network keeps browsing normally:

# /etc/dnsmasq.d/lab-rtmp.conf
server=1.1.1.1
address=/ingest.stream.lab/127.0.0.1
log-queries
log-facility=/var/log/dnsmasq-lab.log

Restart the service and add the rtmp block to the nginx configuration. That block goes at the same level as http, not inside it:

sudo systemctl restart dnsmasq

# /etc/nginx/nginx.conf (add at the end of the file)
rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        application live {
            live on;
            record off;
        }
    }
}

Restart nginx and confirm the fake resolution is active before streaming anything:

sudo systemctl restart nginx

$ dig ingest.stream.lab @127.0.0.1 +short
127.0.0.1

With the response pointing to your own machine, generate a synthetic stream with ffmpeg. No real video is needed, lavfi generates one:

ffmpeg -re -f lavfi -i testsrc=size=640x480:rate=25 -f lavfi -i sine=frequency=1000 -c:v libx264 -c:a aac -f flv rtmp://ingest.stream.lab/live/test

To verify that nginx-rtmp is receiving the stream, enable the module’s stats panel by adding this location inside nginx’s http / server block:

location /stat {
    rtmp_stat all;
}

Reload nginx and, while ffmpeg keeps running, check the status:

sudo systemctl reload nginx

$ curl -s http://127.0.0.1/stat | grep -o '<nclients>[0-9]*'
<nclients>1</nclients></nclients>

That 1 confirms the server received an active connection in the live application. Kill ffmpeg with Ctrl+C and the number goes back to zero: that’s all the verification you need to know the redirection mechanism works end to end.

Real Use Cases

The documented case that popularized this technique in 2026 involved a developer who wanted to share his PlayStation 5’s screen on Discord without buying a capture card. As he described on his blog, he first tried spoofing ingest.twitch.tv directly, but that domain is just an HTTPS discovery endpoint: the console queries it to ask which regional server to use, and the response arrives protected by TLS.

Checking the dnsmasq logs while streaming, he found the console ended up resolving ingest.global-contribute.live-video.net, which in turn pointed to a specific server like aps30.contribute.live-video.net. Spoofing the parent domain contribute.live-video.net covers all those regional subdomains at once, and that server does accept plain RTMP on port 1935.

The final step was to direct only the console’s traffic, not the entire home network’s: using a router running OpenWRT, he configured DHCP option 6 (the DNS server) to apply only to the lease for the PS5’s MAC address, via a tag defined in the DHCP configuration.

The same primitive is used, in reverse, to filter traffic instead of stealing it: tools like Pi-hole apply this same DNS redirection, but as a deliberate block, so advertising domains resolve to a null address. In authorized security audits, it’s also one of the first tests run against a new IoT device: if the manufacturer doesn’t validate certificates, the redirection reveals that flaw within minutes.

Common Mistakes and Best Practices

• Confusing the discovery endpoint with the real server: targeting an HTTPS discovery domain directly, like ingest.twitch.tv, doesn’t work, because certificate validation there cuts the connection before a single byte of video travels.
• Redirecting the entire network instead of a single device: if the fake dnsmasq serves the whole LAN, every other device loses access to the rest of the internet. Limit the scope by MAC address or DHCP lease.
• Forgetting the upstream server: without a server= line pointing to a real resolver, the test dnsmasq leaves everything except the fake domain unresolved.
• Ignoring the provider’s live stream check: some platforms confirm against their own API that the stream arrived, and if it never does, they cut the transmission within seconds even if the device keeps sending data.
• Testing against someone else’s infrastructure without authorization: what’s a technical test in your own lab becomes unauthorized access against someone else’s network or a third party’s service.

⚠️ Heads up: applying this technique against a network, device, or service that isn’t yours, or without explicit written authorization, is illegal in most jurisdictions even if the intent is harmless.

Comparison with Alternatives

Going Deeper

The trick of spoofing contribute.live-video.net instead of a specific subdomain works because dnsmasq resolves by suffix: the address=/domain/ip directive automatically covers any subdomain hanging off that name. It’s the same logic CDNs use for geo-routing: the root domain doesn’t change, but the response varies depending on which edge server best fits the location.

The real technical defense against name resolution manipulation has two layers. DNSSEC cryptographically signs each DNS response so a resolver can verify it wasn’t altered in transit, but it requires both the domain and the client to validate it, and much of consumer hardware simply doesn’t. The second layer, DNS over HTTPS or over TLS, encrypts the entire query to a specific resolver, for example 1.1.1.1 or 8.8.8.8 via HTTPS: if the device uses DoH toward a fixed server on the internet, a local dnsmasq on the same network can no longer intercept or modify that query.

💡 Tip: forcing DNS over HTTPS toward an external resolver on any device under your control completely cancels out this kind of local redirection, because the query no longer passes through the network’s DNS.

In practice, almost no consumer streaming device implements DoH natively yet, which explains why the technique documented against the PS5 kept working in 2026 without any additional adjustment. Even so, the pattern repeats across the rest of the streaming ecosystem: any client that resolves its server by domain name, without pinning the IP and without validating a certificate, is a candidate for this same class of redirection.

Your next step: set up this guide’s lab with your own test domain and run tcpdump -i any port 1935 while the example ffmpeg streams, to watch RTMP chunks arrive live at your fake server.

Frequently Asked Questions

How is DNS poisoning different from an ARP spoofing attack?

DNS poisoning tricks the device at the domain name level, without needing to be on the same local network. ARP spoofing, on the other hand, falsifies physical addresses within a LAN and requires the attacker to share the same network segment as the victim.

Why can’t RTMPS be intercepted with the same DNS resolution spoofing?

RTMPS encrypts the connection with TLS and validates the server’s certificate against a list of trusted authorities. A server of your own with a self-signed certificate doesn’t pass that validation, so DNS resolution spoofing only changes the destination, but the device cuts the connection when it detects the certificate isn’t trusted.

Is DNS spoofing legal on my own network?

It depends on the scope. Applying DNS spoofing against your own devices, on your own network, and for testing purposes doesn’t break any law in most countries. Doing it against someone else’s network, device, or service without authorization is unauthorized access, a crime in practically every jurisdiction.

What is DNS over HTTPS and how does it affect DNS poisoning?

DNS over HTTPS encrypts the name resolution query inside an HTTPS connection to a specific resolver, instead of sending it in plain text to the local network’s DNS server. That means traditional DNS poisoning, the kind that depends on intercepting a query on the LAN, stops working against that device.

Can DNS redirection be used to access paid streaming without authorization?

It’s technically possible to try using DNS redirection to bypass access control, but it’s unauthorized use that violates any platform’s terms of service and can constitute a crime, on top of which services encrypted with RTMPS block interception through certificate validation.

References

• Hijacking the PS5’s RTMP Stream: the original article documenting the PlayStation 5 case used as a practical example.
• nginx-rtmp-module on GitHub: documentation and source code for the module used to set up the lab’s RTMP server.
• Official dnsmasq documentation: complete reference for configuration directives, including address= and server=.
• Real-Time Messaging Protocol on Wikipedia: history and general specification of the RTMP protocol.
• DNS spoofing on Wikipedia: general explanation of the DNS manipulation technique and its variants.

📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Jonathan en Unsplash