SYN Cookies
SYN cookies are a server-side defense against SYN flooding, described in RFC 4987, letting a server answer a SYN without allocating per-connection state by encoding what it needs into the SYN-ACK's sequence number, creating real state only once a valid final ACK arrives. AdminKit's protective DNS product applies the same instinct: absorb abuse before it costs server resources.
By AdminKit team, Netbase JSC · Updated
SYN cookies are a server-side defense against SYN flooding, a denial-of-service technique described in RFC 4987 in which an attacker sends many SYN packets without ever completing the handshake, exhausting the finite backlog queue a server uses to track half-open connections and denying service to legitimate clients on that well-known port. Rather than allocating state for every SYN it receives, a server using SYN cookies encodes the information it needs to validate the connection directly into the initial sequence number of its own SYN-ACK reply — a value derived so the server can recompute and check it later — and only creates real connection state once a client’s final ACK comes back echoing a sequence number consistent with that encoding. Because no state is kept for a half-open connection, there’s no backlog queue for a flood of spoofed SYNs to exhaust in the first place. RFC 4987 presents SYN cookies alongside other complementary mitigations, such as increasing the backlog queue size and SYN caching, rather than as a single complete fix. Since many SYN flood attacks rely on spoofed source addresses to avoid easy rate-limiting or traceback, RFC 2827 (BCP 38) ingress filtering — having networks block outbound traffic whose source address falls outside their own assigned range — addresses a related but distinct piece of the same problem. A honeypot takes a different approach again: instead of preventing a flood of connections, it deliberately exposes a monitored service to observe attack traffic rather than to survive it.
SYN cookies are part of AdminKit’s IP & network cluster; the full AdminKit glossary lists other related terms.
Frequently asked questions
What specific resource does a SYN flood attack try to exhaust?
The server's backlog of half-open connections -- the finite queue that tracks connections which have received a SYN but not yet completed the handshake with a final ACK.
How do SYN cookies let a server avoid keeping state for incomplete connections?
Instead of storing each half-open connection, the server encodes the information it needs into the initial sequence number of its own SYN-ACK and only creates real connection state once a client's final ACK echoes back a value proving it legitimately received that SYN-ACK.
Why does ingress filtering under BCP 38 matter for SYN flood defense specifically?
Many SYN flood attacks spoof the source address of SYN packets; RFC 2827 (BCP 38) has networks filter outbound traffic so a host can't send packets with a source address outside its own assigned range, making an untraceable spoofed-source flood harder to launch in the first place.
Does RFC 4987 recommend SYN cookies as the only defense against SYN flooding?
No -- it describes SYN cookies alongside several other mitigations, such as increasing the backlog queue size and SYN caching, and treats them as complementary techniques rather than a single complete fix.