DoS vs DDoS: the short answer
A denial-of-service (DoS) attack makes a service or resource unavailable or materially slower for legitimate users. A distributed denial-of-service (DDoS) attack is a DoS attack that coordinates traffic or requests from many systems. Distribution can make filtering and capacity planning harder, but source count alone does not identify the affected layer or the right response.
The first operational question is not simply “DoS or DDoS?” It is which resource is failing: an upstream link, packet-processing path, connection table, application worker pool, cache, database, identity service, DNS dependency, or another shared component. Find the actual bottleneck, preserve evidence, and involve the provider that can act before traffic reaches the saturated point.
What is the difference between DoS and DDoS?
| Dimension | DoS | DDoS | Why it matters |
|---|---|---|---|
| Definition | Any deliberate action that denies or degrades legitimate service | A distributed form of DoS using traffic or requests from many systems | Every DDoS attack is a DoS attack, but not every DoS attack is distributed. |
| Apparent sources | May be one source, a small set, or a non-traffic resource failure triggered by an attacker | Usually spans many hosts, networks, regions, or reflected services | One visible IP can be spoofed, translated, proxied, or reflected; many visible IPs can include legitimate users. |
| Common constraint | Can exhaust a local protocol, process, application, or dependency without filling the Internet link | Can also exhaust upstream capacity or distributed edge and application resources | Controls must operate before the first saturated resource. |
| Filtering | A narrow, verified source or request pattern may be containable near the service | Broad source blocking often removes legitimate traffic and may not reduce load | Match controls to protocol, endpoint, cost, identity, and observed failure rather than source count alone. |
| Coordination | Application, platform, or network teams may contain a local constraint | Early ISP, hosting, cloud, CDN, or managed-mitigation coordination is often required | Filtering after a link is saturated cannot restore that link. |
| Attribution | Logs may identify an apparent source, account, or request path | Botnets and reflectors separate traffic sources from the controller | Telemetry supports response; it does not by itself prove who directed the attack. |
DoS and DDoS attack patterns
| Pattern | What becomes constrained | Evidence to compare |
|---|---|---|
| Volumetric saturation | Internet link, edge throughput, packets per second, or provider capacity | Interface utilization, drops, protocol and port mix, packet size, provider telemetry, and geographic distribution |
| Reflection or amplification | Victim capacity receives replies caused by requests carrying a spoofed victim address | Unexpected response traffic, source services, protocol and ports, response ratios, and upstream observations |
| Protocol or state exhaustion | Connection tables, load balancers, firewalls, gateways, or protocol state | Connection states and age, retransmissions, queue depth, packets per second, timeouts, and device resource use |
| Application request flood | Expensive routes, workers, CPU, cache, database, identity, search, or third-party dependencies | Request path and cost, cache misses, session or account signals, latency, errors, traces, and dependency health |
| Slow or low-rate exhaustion | Scarce connections, threads, workers, streams, or transaction slots remain occupied | Concurrency, connection age, incomplete requests, worker use, queue depth, and per-request duration |
A traffic spike is not automatically an attack. A release, crawler, retry storm, routing fault, dependency outage, or configuration error can produce similar symptoms. Incident handling should preserve both security and reliability hypotheses until the evidence separates them.
What evidence should you collect?
| Evidence | Questions it should answer | Handling note |
|---|---|---|
| Time and service scope | When did degradation start, which regions and endpoints failed, and what remained healthy? | Use synchronized timestamps and record timezone, observation point, and change history. |
| Network and edge telemetry | Which links, protocols, ports, packet rates, connection states, and edge controls changed? | Retain bounded samples and provider graphs; avoid collecting more payload data than the response requires. |
| Application telemetry | Which routes, operations, identities, caches, workers, queues, and dependencies consumed resources? | Protect credentials and personal data when sharing traces, logs, or examples. |
| Control changes | Who changed a rule, threshold, route, origin, DNS record, capacity setting, or degraded mode? | Record exact scope, approval, time, observed effect, and rollback condition. |
| External observations | What did the ISP, host, cloud, CDN, monitoring vantage point, or mitigation provider observe? | Preserve ticket IDs, contacts, activation times, traffic-diversion state, and provider limitations. |
Keep evidence proportional and privacy-aware. A useful incident record connects each observation to a time, service, collection point, and response decision; a large unlabelled log export is harder to validate and share safely.
How to respond to a DoS or DDoS attack
- Declare and scope the incident. Name an incident lead, record the present time, identify affected services and business impact, freeze unrelated changes, and keep a decision log.
- Confirm the first constrained resource. Compare provider, edge, host, and application telemetry. Do not assume the largest graph is the cause of the outage.
- Contact the upstream path early. Use the pre-arranged ISP, hosting, cloud, CDN, or managed-mitigation contact. Share the exact destination, time window, protocol or endpoint pattern, observed bottleneck, and safe evidence.
- Protect management and recovery access. Preserve an out-of-band path where possible, restrict administrative interfaces, verify routing and DNS authority, and watch for concurrent account or configuration compromise.
- Apply the narrowest validated controls. Use controls appropriate to the affected layer, monitor collateral impact, keep a rollback condition, and avoid broad geographic or network blocks without evidence.
- Operate a safe degraded mode. Prioritize critical endpoints, reduce expensive optional work, protect dependencies, and communicate service status from a channel that remains available.
- Verify recovery. Confirm user journeys from independent networks, error and latency recovery, queue drainage, dependency health, route and DNS state, and removal or review of temporary controls.
- Review and improve. Reconcile the timeline, provider response, alert gaps, capacity assumptions, control effects, communications, retained evidence, and runbook changes.
What can a source IP address prove?
A source IP address is an observation about one packet, request, or connection at one collection point and time. It may help identify a network, route, or contact path, but it does not by itself identify a person, device owner, controller, or attacker. Read the IP spoofing guide and CGNAT guide before treating an address as attribution.
- Spoofing: connectionless traffic can carry a forged source address when networks do not enforce source validation.
- Reflection: visible source addresses can belong to third-party services replying to spoofed requests.
- NAT, CGNAT, proxies, and shared systems: many users or devices can appear behind one public address.
- Botnets: the participating device and its subscriber may be victims; their addresses do not identify the controller.
Correlate network observations with server logs, account and session evidence, provider records, routing state, reliable timestamps, and lawful process. Use evidence-based abuse reports to reach the operator able to investigate.
Build and test a denial-of-service runbook
| Area | Decision to record | Proof of readiness |
|---|---|---|
| Service map | Critical endpoints, DNS, edge, origin, identity, data stores, queues, third parties, and degraded modes | Current diagram, owners, dependency health checks, capacity limits, and recovery objectives |
| Provider escalation | 24/7 contacts, account IDs, activation authority, traffic-diversion or scrubbing options, thresholds, and limitations | Tested contact path, ticket template, recent exercise, and documented fallback |
| Controls | Network, transport, edge, identity, application, cache, queue, and dependency protections | Change procedure, scoped test, observability, collateral-impact check, and rollback |
| Evidence | Required clocks, logs, flow or packet samples, traces, provider views, retention, access, and sharing rules | Time synchronization, known collection points, protected storage, and privacy review |
| Communication | Incident command, technical updates, customer status, legal or regulatory review, and closure criteria | Named roles, resilient channels, approved templates, and exercise receipts |
Test the runbook with synthetic load and provider exercises only within an authorized scope. Do not direct stress traffic at production or third-party systems. Capacity, patching, redundancy, rate controls, caching, source validation, and upstream mitigation can each reduce specific risks; none is a universal prevention guarantee.
DoS vs DDoS FAQ
What is the main difference between DoS and DDoS?
DoS is the broader category: an action that denies or degrades legitimate service. DDoS is a distributed form of DoS in which traffic or requests come from many systems. The operational response still depends on the affected layer and bottleneck.
Is DDoS a type of DoS attack?
Yes. DDoS is a DoS technique distinguished by distributed participation. Distribution may increase scale and complicate filtering, but it does not by itself identify the traffic type, controller, or correct mitigation.
Is DDoS always worse than DoS?
No. A distributed event can be absorbed by prepared infrastructure, while one request pattern can exhaust a fragile application or dependency. Compare business impact, failure point, duration, and recovery requirements rather than judging severity from source count.
How can I tell whether an outage is DoS or DDoS?
Correlate time-synchronized network, edge, host, application, and provider telemetry. Look for the constrained resource, source distribution, protocol or endpoint pattern, connection state, request cost, errors, and recent changes. Also test non-malicious causes such as a release, retry storm, dependency failure, or routing fault.
Can a firewall stop a DDoS attack?
A firewall can enforce useful controls for traffic that reaches it, but it cannot restore an already saturated upstream link and can itself run out of state or processing capacity. Large events often require action by the network or service provider before the bottleneck.
Does a source IP address identify the DDoS attacker?
No. The address may be spoofed, reflected, shared, proxied, or assigned to a compromised device. Treat it as time-bound network evidence and correlate it with other records; do not treat it as proof of a person or controller.
What should I do first during a suspected DDoS attack?
Declare the incident, identify the affected service and first constrained resource, preserve timestamps and telemetry, and contact the pre-arranged upstream or mitigation provider early. Apply only validated controls with monitoring and rollback.
How can an organization prepare for DoS and DDoS attacks?
Map service dependencies and capacity, establish baselines and alerts, pre-arrange provider escalation, protect management access, define degraded operation, retain useful evidence, assign communication roles, and exercise the runbook within an authorized scope.
Primary sources
- CISA, FBI, and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- RFC 4732: Internet Denial-of-Service Considerations
- BCP 38 / RFC 2827: Network Ingress Filtering
- BCP 140 / RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks
Where i.lease fits
i.lease can support address-space records, routing coordination, reputation work, and abuse operations within an agreed scope. It is not an emergency DDoS mitigation or incident-response service; active attacks require the network, hosting, cloud, CDN, or managed mitigation provider carrying the traffic.
For continuing address-space operations, use the IPv4 operating knowledge base, review how botnets affect network evidence, and keep an evidence-based network abuse workflow.
