Rate Limiting and API Abuse Prevention: Patterns That Scale

By /

Excerpt: A practical, sanitized walkthrough for detecting DNS record drift, validating dual-stack exposure, and feeding high-signal findings into a SIEM using only fictional infrastructure and example data.

DNS is one of the easiest control planes to overlook because it often changes outside normal deployment pipelines. A team updates an A record to move traffic, an engineer adds a temporary AAAA record during testing, or a CDN cutover leaves stale entries behind. In mature environments, those changes are not just operational concerns. They directly affect attack surface, certificate scope, access controls, monitoring coverage, and incident response assumptions.

This article walks through a sanitized workflow for detecting DNS drift in a dual-stack environment. The examples are fictional, but the process is realistic: establish a baseline, collect live DNS answers, compare intended and observed state, validate reachable services, and generate SIEM-ready telemetry. The goal is not to build a giant asset platform. It is to create a repeatable, low-noise detection loop that helps security teams spot meaningful changes before they become blind spots.

Why DNS drift matters to defenders

DNS drift happens when observed records no longer match the state your team expects. Sometimes the cause is harmless, like a migration that finished early. Sometimes it signals process failure, shadow infrastructure, or an untracked external dependency. In dual-stack environments, AAAA records add another dimension: a service may be protected on IPv4 while quietly exposed over IPv6 with a different path, policy set, or logging profile.

A few concrete risks come up repeatedly:

  • New records expose services outside approved ingress paths.
  • Old records keep pointing to systems that should have been retired.
  • AAAA records bypass controls tested only on IPv4.
  • Security scanners and SIEM parsers miss name-to-address changes because they only track hosts, not DNS intent.
  • TLS, reverse proxy, and WAF assumptions break when backends move.

A good drift workflow does not try to answer every infrastructure question. It focuses on three outcomes:

  1. Detect unexpected DNS changes quickly.
  2. Validate whether the change affects reachable exposure.
  3. Emit evidence in a format operations and detection teams can act on.

Reference architecture

For this walkthrough, assume a fictional environment with these systems:

  • `bastion01` at `10.0.1.10`
  • `siem01` at `10.0.1.20`
  • `web01` at `10.0.1.30`
  • `proxy01` at `10.0.1.40`
  • `db01` at `10.0.1.50`

The public zone is `example-corp.com`. We will monitor records such as:

  • `portal.example-corp.com`
  • `api.example-corp.com`
  • `auth.example-corp.com`

The baseline lives in version control as a simple YAML file reviewed through change control.

zone: example-corp.com
records:
  - name: portal.example-corp.com
    type: A
    values: ["192.168.1.30"]
    owner: web-platform
    criticality: high
  - name: api.example-corp.com
    type: A
    values: ["192.168.1.40"]
    owner: edge-platform
    criticality: high
  - name: auth.example-corp.com
    type: A
    values: ["192.168.1.40"]
    owner: identity
    criticality: critical
  - name: auth.example-corp.com
    type: AAAA
    values: []
    owner: identity
    criticality: critical

The key point is that “no AAAA record” is also a declared state. If an AAAA record later appears, the workflow should flag it explicitly instead of ignoring it as a harmless addition.

Step 1: Collect live DNS answers from trusted resolvers

Start with deterministic collection. Query both A and AAAA records and store exactly what resolvers return. If possible, query more than one resolver to separate local cache oddities from real changes.

A simple shell collector looks like this:

#!/usr/bin/env bash
set -euo pipefail

records=(
  portal.example-corp.com
  api.example-corp.com
  auth.example-corp.com
)

for name in "${records[@]}"; do
  for type in A AAAA; do
    dig +short "$name" "$type" | sort -u | awk -v n="$name" -v t="$type" 'NF {print n "," t "," $0}'
  done
done

Sample output might be:

portal.example-corp.com,A,192.168.1.30
api.example-corp.com,A,192.168.1.40
auth.example-corp.com,A,192.168.1.40
auth.example-corp.com,AAAA,2001:db8::40

In a real article you might show live public addresses. Do not do that in an operational content pipeline. Keep the publication sanitized. If your internal collector sees a real IPv6 result, normalize it in private processing and only publish fictional examples.

Step 2: Compare observed state to the approved baseline

Once you have live data, compare it to the intended state. A short Python script is usually easier to maintain than increasingly complex shell pipelines.

#!/usr/bin/env python3
import csv
import yaml
from collections import defaultdict

with open("baseline.yml") as f:
    baseline = yaml.safe_load(f)

expected = defaultdict(set)
for record in baseline["records"]:
    expected[(record["name"], record["type"])].update(record["values"])

observed = defaultdict(set)
with open("observed.csv") as f:
    for row in csv.reader(f):
        name, rtype, value = row
        observed[(name, rtype)].add(value)

for key in sorted(set(expected) | set(observed)):
    missing = sorted(expected[key] - observed[key])
    unexpected = sorted(observed[key] - expected[key])
    if missing or unexpected:
        print({
            "name": key[0],
            "type": key[1],
            "missing": missing,
            "unexpected": unexpected,
        })

For the sample above, the workflow would report an unexpected AAAA value for `auth.example-corp.com`. That is useful, but not enough. Security teams need to know whether the drift changes exposure or simply reflects a planned pre-stage.

Step 3: Validate reachability, not just resolution

A record appearing in DNS does not automatically mean the service is reachable. Validate what an external client would experience. For web services, test TCP reachability, TLS, and the HTTP response path. For non-web services, adapt the probe to the protocol.

Here is a minimal validation loop for HTTPS endpoints:

while IFS=, read -r name type value; do
  [ "$type" = "AAAA" ] || continue
  curl --silent --show-error --max-time 5 \
    --resolve "$name:443:$value" \
    "https://$name/healthz" \
    -o /dev/null \
    -w '{"name":"%{url_effective}","code":%{http_code},"ip":"%{remote_ip}","tls":"%{ssl_verify_result}"}\n'
done < observed.csv

In production, you would run this from a controlled probe point, ideally one that mirrors external access. Feed the result into your triage logic:

  • DNS drift + not reachable = investigate, but lower urgency.
  • DNS drift + reachable + expected certificate = likely change-management gap.
  • DNS drift + reachable + unexpected certificate or content = high-priority review.

That last case often catches real problems: stale origins, bypass paths around the proxy layer, or forgotten preview stacks.

Step 4: Add context before generating alerts

The biggest reason drift detectors get ignored is poor context. Avoid sending “record changed” events without enrichment. Join the DNS finding with asset metadata so analysts immediately know ownership, criticality, and expected network path.

A compact enrichment record might look like this:

{
  "event_type": "dns_drift",
  "record_name": "auth.example-corp.com",
  "record_type": "AAAA",
  "unexpected_values": ["2001:db8::40"],
  "owner": "identity",
  "criticality": "critical",
  "expected_proxy": "proxy01",
  "validation": {
    "tcp_443": true,
    "http_code": 200,
    "content_match": false
  }
}

Notice the fields are decision-oriented. Ownership tells you who to page. Criticality tells you urgency. Expected proxy lets you catch routing anomalies. Content matching helps distinguish a normal service from an exposed backend with the wrong application responding.

Step 5: Forward the event into the SIEM

Send a structured event to `siem01` rather than scraping human-readable logs later. A simple JSON-over-syslog or HTTP collector is enough.

Example rsyslog template on `bastion01`:

template(name="dnsdrift_json" type="string"
  string="%msg%\n")

action(
  type="omfwd"
  target="10.0.1.20"
  port="514"
  protocol="tcp"
  template="dnsdrift_json"
)

And a detection idea inside the SIEM:

title: Unexpected AAAA Record With Reachable HTTPS Service
logsource:
  category: dns_drift
  product: custom
condition:
  selection:
    record_type: AAAA
    validation.tcp_443: true
  unexpected_values|exists: true
level: high
fields:
  - record_name
  - unexpected_values
  - owner
  - criticality

This keeps the high-signal path narrow. You are not alerting on every DNS fluctuation. You are alerting on exposure-relevant drift with supporting evidence.

Step 6: Build guardrails around false positives

Defenders lose faith in control-plane monitoring when every planned change pages the wrong person. Add guardrails early.

Useful patterns include:

  • **Maintenance windows:** suppress alerts for approved record sets during a narrow change window.
  • **Resolver quorum:** require two resolvers to agree before opening a finding.
  • **Persistence thresholds:** treat single-sample anomalies as informational until they persist for multiple polls.
  • **Content fingerprinting:** compare headers or response hashes to expected applications.
  • **Ownership exceptions:** allow teams to register temporary deviations with automatic expiry.

Do not let exceptions become permanent amnesty. Every suppression should have an expiration time and an owner.

Step 7: Treat IPv6 as a first-class exposure path

Many organizations say they “do not really use IPv6” while publishing AAAA records through providers, proxies, or default platform behavior. That mindset creates blind spots. Even if your internal estate remains mostly IPv4, your public exposure can still become dual-stack through edge services or misconfiguration.

A lightweight control is to score records differently when AAAA appears where none was expected. Another is to maintain protocol-specific validation logic. If your security stack only confirms the IPv4 route to `proxy01`, you have not validated the service end-to-end.

For teams early in IPv6 monitoring, start with these three checks:

  1. Detect new AAAA records for critical names.
  2. Validate TLS and content over the IPv6 path.
  3. Confirm logs from the IPv6-served connection reach `siem01`.

That last check matters more than people think. A reachable service that bypasses logging is often worse than an unreachable stale record.

Step 8: Operationalize the workflow

Once the detection logic works, package it into a scheduled job. Run collection from `bastion01`, push normalized events to `siem01`, and store daily snapshots so responders can compare today’s state to yesterday’s. Keep the baseline in version control and require changes to pass review like application code.

A practical cadence is:

  • Poll high-value names every 15 minutes.
  • Re-validate exposure when drift appears.
  • Send enriched events immediately.
  • Generate a daily rollup for changes that resolved without escalation.

That combination gives analysts fast signals without flooding the queue.

Operational considerations and next steps

Start small. Pick five high-value records in `example-corp.com`, declare both A and AAAA expectations explicitly, and build a collector that stores clean evidence. Then add reachability tests, enrichment, and SIEM forwarding. Measure false positives before scaling to every zone.

From there, the next useful improvements are straightforward: tie baseline changes to ticket IDs, verify that IPv6-served traffic is logged, and add content fingerprints so your workflow can distinguish an approved proxy from an exposed backend on `web01`. The point is not perfect inventory. It is reducing the time between “DNS changed” and “we know whether this matters.” For defenders, that is a very practical win.

Scroll to Top