What Are DoS and DDoS Attacks?
A denial-of-service (DoS) attack is any deliberate action that prevents or materially degrades legitimate access to a service or resource. The constrained resource may be network capacity, protocol or connection state, compute, storage, a dependency, or an application endpoint. One source is common in simple cases, but source count is not the definition.
A distributed denial-of-service (DDoS) attack is a DoS technique that coordinates traffic or requests from numerous systems. Distribution can make filtering, attribution, and capacity planning harder, but the affected layer, traffic validity, upstream capacity, and mitigation design determine the response.
DoS vs DDoS: the operational differences
DoS Attack
- Source pattern: A DoS event may come from one source or a small set, but one apparent IP can be spoofed, translated, proxied, or part of a reflection path.
- Evidence: Identify the constrained resource and layer—link capacity, connection or protocol state, compute, database, cache, dependency, or application endpoint.
- Response: A narrow source may be blockable, but durable mitigation still requires validation, rate and state controls, capacity planning, and an upstream escalation path.
DDoS Attack
- Source pattern: Traffic or requests arrive from numerous systems, networks, regions, or reflected services; not every participating host is knowingly malicious.
- Evidence: Compare edge, network, and application telemetry to identify protocols, ports, request paths, response ratios, source distribution, and the actual bottleneck.
- Response: Coordinate early with the ISP, hosting or cloud provider, CDN, or managed mitigation provider; filtering at an already saturated link is too late.
DoS and DDoS attack patterns
Volumetric or resource saturation: Traffic consumes available bandwidth, packet-processing capacity, connection slots, compute, memory, storage, or a downstream dependency. Measure the bottleneck instead of assuming every spike is a bandwidth flood.
Reflection and amplification: Requests with a spoofed victim address cause third-party services to send larger responses toward the victim. Capture protocols, ports, request-to-response ratios, and upstream observations before changing filters.
Distributed bot traffic: Compromised devices can coordinate traffic across many networks. Source diversity alone does not identify the controller, and blocking whole countries or networks can remove legitimate users without relieving the bottleneck.
Slow or low-rate resource exhaustion: A relatively small number of connections or requests can hold scarce application or protocol state. Track connection age, concurrency, queue depth, timeouts, worker use, and dependency health.
Application-layer request floods: Requests may look syntactically valid while concentrating on expensive paths such as search, login, APIs, or cache misses. Use endpoint cost, cache behavior, identity, session, and application telemetry—not source IP alone.
How to prepare for and respond to DoS or DDoS
1. Map the service and failure points: List critical endpoints, DNS, edge and origin paths, upstream links, authentication, databases, queues, third-party dependencies, capacity limits, and the business impact of degraded operation.
2. Establish baselines and alerts: Retain time-synchronized edge, network, and application telemetry. Alert on saturation, errors, latency, queue depth, connection state, request cost, cache misses, and dependency failures—not traffic volume alone.
3. Pre-arrange upstream help: Record 24/7 contacts, account identifiers, activation steps, traffic-diversion or scrubbing options, thresholds, change authority, and fallback routes for the ISP, hosting or cloud provider, CDN, and any managed mitigation service.
4. Match controls to the layer: Network and transport controls address spoofed, reflected, protocol, or connection-state traffic; application controls address costly routes, sessions, identities, and abusive behavior. Scaling and patching help specific constraints but are not complete DDoS plans.
5. Write and test the runbook: Assign incident command, provider escalation, evidence capture, customer communication, degraded modes, failover, rollback, and recovery validation. Exercise the plan without directing test traffic at production or exceeding an authorized scope.
6. During an incident: Confirm safety and authority, contact the upstream or mitigation provider early, preserve telemetry and timestamps, protect management access, apply the narrowest validated controls, monitor other security alerts, and verify recovery before standing down.
Build a tested denial-of-service response plan
No control eliminates denial-of-service risk. A workable plan identifies the service and bottleneck, separates network from application evidence, pre-arranges upstream coordination, defines degraded operation and recovery, and is tested before an incident. Use current guidance from your national cyber authority and service providers, then keep contacts, thresholds, diagrams, and runbooks under change control.
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.
Review IPv4 operating guidance
