Introduction

DNS is the invisible bottleneck of most VPS workloads. Many teams treat DNS as “point /etc/resolv.conf at an upstream and be done with it”:

• One-size-fits-all TTL: Every domain gets the same cache lifetime — high-frequency API domains and once-a-year lookups are treated identically, dragging the hit-rate down;
• Wasted egress resolution: Every app on the VPS recurses on its own, re-querying the same upstreams over and over, amplifying both egress traffic and latency;
• Missing negative cache: Failed lookups (NXDOMAIN / timeouts) aren’t recorded, so the same bad domain keeps triggering upstream recursion;
• Guesswork profiling: Which domains are hot, which can use a long TTL, which should be answered locally — all from intuition, no data.

AI DNS optimization takes a different approach: run a lightweight DNS proxy (Unbound) inside the VPS, capture each domain’s resolution profile (QPS, cache hit/miss, TTL distribution, failure rate, response latency), feed it to a local LLM (Ollama + Qwen2.5) that judges each domain’s “value” with business semantics, and auto-emit dynamic TTL, negative-cache, and egress-convergence policies — hot domains long-cached, cold domains short TTL, failed domains into negative cache, duplicate recursion merged — zero data exfiltration, all local inference.

Architecture

┌─────────────────────────────────────────────────────────────┐
│                In-VPS DNS resolution path                  │
│  apps (resolv.conf) → 127.0.0.1:53 → Unbound local proxy   │
└──────────────────────────────────────────────────────────────┘
               │ collect (query log: QPS/hit/TTL/failure/latency)
               ▼
┌─────────────────────────────────────────────────────────────┐
│          Resolution Profiler (Python)                        │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ QPS dist  │  │ hit-rate │  │ TTL dist  │  │ fail rate │   │
│  │(queries/s)│  │(cache)   │  │(upstream) │  │(NXDOMAIN) │   │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘   │
└───────┼──────────────┼─────────────┼──────────────┼────────┘
        ▼              ▼             ▼              ▼
┌─────────────────────────────────────────────────────────────┐
│      Ollama + Qwen2.5 (local inference, localhost:11434)    │
│  input: domain resolution profile + business tags           │
│  output: JSON policy (dynamic_ttl / negative_cache / egress)│
└────────────────────────────┬────────────────────────────────┘
                             ▼
┌─────────────────────────────────────────────────────────────┐
│          Policy Generator (Python)                           │
│  → Unbound local-zone TTL override (long-cache hot domains) │
│  → negative-cache-ttl tightening (failed domains)           │
│  → egress convergence (merge duplicates + Anycast upstream) │
└────────────────────────────┬────────────────────────────────┘
                             ▼
┌─────────────────────────────────────────────────────────────┐
│          Alert channel (Telegram Bot)                       │
│  TTL change notice / weekly hit-rate / egress-savings report │
└─────────────────────────────────────────────────────────────┘

Implementation

1. Collect the resolution profile: Unbound log + aggregation

Point all apps at a local Unbound and enable resolution profiling:

# /etc/unbound/unbound.conf key sections
server:
    verbosity: 2
    log-queries: no
    # Pull stats from the statistics interface instead of per-line logs — cheaper
    statistics-interval: 60
    statistics-cumulative: yes

Use Python to poll the stats and aggregate per-domain profiles over the last 7 days:

# collect_dns_profile.py
import requests, json
from collections import defaultdict

STATS = 'http://localhost:8953/stats'  # exported by unbound-control

def get_counters():
    return requests.get(STATS, timeout=5).json()

# Simplified: keep a domain -> metrics table (populated from unbound logs or a custom counter)
# Here we illustrate parsing /var/log/dns_query.log
profiles = defaultdict(lambda: {'qps': 0.0, 'hits': 0, 'misses': 0,
                                 'ttl_p50': 0, 'ttl_p95': 0,
                                 'nx': 0, 'avg_ms': 0.0, 'hits_total': 0})

# each line: ts|domain|code|ttl|ms|hit(0/1)
with open('/var/log/dns_query.log') as f:
    lines = [l for l in f.readlines()][-50000:]
for line in lines:
    ts, dom, code, ttl, ms, hit = line.strip().split('|')
    p = profiles[dom]
    p['hits_total'] += 1
    p['qps'] = p['hits_total'] / (7 * 86400)      # 7-day average
    p['ttl_p50'] = max(p['ttl_p50'], int(ttl))
    p['avg_ms'] = (p['avg_ms'] + int(ms)) / p['hits_total']
    if code == '3':                                  # NXDOMAIN
        p['nx'] += 1
    if hit == '1':
        p['hits'] += 1
    else:
        p['misses'] += 1
    p['hit_rate'] = p['hits'] / p['hits_total'] if p['hits_total'] else 0

out = {d: {k: round(v, 3) for k, v in m.items()} for d, m in profiles.items()}
with open('data/dns_profiles.json', 'w') as f:
    json.dump(out, f, indent=2, ensure_ascii=False)
print(f"Profiled {len(out)} domains, top3 hit-rate: "
      + ', '.join(sorted(out, key=lambda d: out[d]['hit_rate'], reverse=True)[:3]))

Key fields:

• qps / hit_rate: is this a hot domain or a cold one;
• ttl_p50 / ttl_p95: the upstream-supplied TTL, deciding how long local caching is safe;
• nx: high-failure domains need negative caching to avoid repeated recursion;
• avg_ms: resolution latency — abnormally high ones should converge to a nearer upstream.

2. LLM semantic judgment: hot domains vs business-critical domains

Feed the profiles into the local LLM; with business tags attached, it judges each domain’s “value” and emits dynamic TTL + policy recommendations:

# llm_dns_policy.py
import json, requests

SYSTEM = """You are a DNS resolution performance expert. For each domain, given its resolution profile and business tags, output:
1. dynamic_ttl: recommended local cache TTL (seconds). Hot/upstream-short-TTL → grow moderately (e.g. 300-3600);
   cold → keep upstream TTL; failing (nx>0) → into negative_cache.
2. negative_cache: 0/1. 1 means this domain fails often; enable a short negative cache (e.g. 30-60s).
3. egress: "local" | "upstream" | "anycast". Answerable locally → local;
   high-frequency duplicates → anycast convergence; otherwise upstream.
4. reason: one sentence (<=30 words).
Output strict JSON, no markdown."""

with open('data/dns_profiles.json') as f:
    profiles = json.load(f)

# Attach business tags (example): mark which domains are business-critical (API gateway, object store, internal svc)
tagged = {
    d: {**p, 'business': tag}
    for d, p, tag in [
        ('api.internal.example.com', profiles.get('api.internal.example.com', {}), 'internal API gateway'),
        ('s3.example.com',           profiles.get('s3.example.com', {}), 'object store'),
        ('pypi.org',                 profiles.get('pypi.org', {}), 'package index'),
        ('example-cdn.edge.com',     profiles.get('example-cdn.edge.com', {}), 'CDN'),
    ]
}

r = requests.post('http://localhost:11434/api/generate', json={
    'model': 'qwen2.5:7b',
    'prompt': f"{SYSTEM}\n\nData:\n{json.dumps(tagged, ensure_ascii=False)}\n\nOutput:"
}, timeout=120)
resp = r.json()['response'].strip()
policy = json.loads(resp[resp.index('{'):])
with open('data/dns_policy.json', 'w') as f:
    json.dump(policy, f, indent=2, ensure_ascii=False)
print(json.dumps(policy, ensure_ascii=False, indent=2))

The LLM outputs something like:

{
  "api.internal.example.com": {"dynamic_ttl": 3600, "negative_cache": 0,
                               "egress": "local",   "reason": "internal API, fixed A record, long cache"},
  "s3.example.com":           {"dynamic_ttl": 300,  "negative_cache": 0,
                               "egress": "anycast", "reason": "high-frequency dupes, converge to anycast"},
  "pypi.org":                 {"dynamic_ttl": 60,   "negative_cache": 1,
                               "egress": "upstream", "reason": "index updates fast, short TTL + negative cache"}
}

Note: attaching business tags in the prompt (mark api.internal as “internal API gateway”) lets the LLM judge by semantics rather than raw numbers — an internal API’s A record barely changes and can safely grow to 1 hour; a package index like pypi.org updates often and must stay on short TTL + negative cache. That semantic distinction is the core advantage over a pure rules engine.

3. Generate Unbound policy: dynamic TTL + negative caching

Turn the LLM policy into Unbound local-zone / config overrides:

# apply_unbound_policy.py
import json

with open('data/dns_policy.json') as f:
    policy = json.load(f)

lines = []
for dom, p in policy.items():
    zone = dom.rstrip('.')
    # hot domain + fixed internal record → override TTL with local-zone (local can self-answer, no egress)
    if p['egress'] == 'local':
        lines.append(f'local-zone: "{zone}" static')   # paired with local-data providing the fixed record
    # tighten negative cache: failing domains get a short negative cache to avoid repeated recursion
    if p['negative_cache']:
        lines.append(f"# negative cache for {zone}")
        lines.append(f'local-zone: "{zone}" nodefault')
    if p['egress'] == 'anycast':
        lines.append(f"# {zone} → egress converge to anycast upstream")

with open('/etc/unbound/dynamic_local_zones.conf', 'w') as f:
    f.write("\n".join(lines) + "\n")
print(f"Wrote {len(lines)} directive lines to dynamic_local_zones.conf")

Also enable and tune negative caching and egress convergence globally in unbound.conf:

# /etc/unbound/unbound.conf additions
server:
    cache-max-size: 64            # MB, scale up as needed
    negative-cache-ttl: 30        # global default short negative cache
    edns-ttl-enable: yes
    # egress convergence: merge duplicate recursion, prefer the lowest-latency upstream
    prefer-system-time: yes
remote-control:
    control-enable: yes

Policy logic:

• Hot domains (egress=local): use local-zone static + local-data to answer locally — egress recursion drops to zero;
• High-frequency duplicates (egress=anycast): point at the lowest-latency Anycast upstream, merging duplicate queries;
• Failing domains (negative_cache=1): tighten negative-cache TTL so bad domains get cached and stop hammering upstreams;
• Cold domains: keep the upstream’s native TTL, no amplification.

4. Egress convergence and latency monitoring

Duplicate recursion is the main source of amplified egress. After converging, expose Unbound stats to Prometheus and monitor hit-rate and latency:

# dns_metrics.py (scraped by Prometheus)
import requests

def snap():
    s = requests.get('http://localhost:8953/stats', timeout=5).json()
    return {
        'unbound_cache_hits': s.get('cache_hits', 0),
        'unbound_cache_misses': s.get('cache_misses', 0),
        'unbound_total_queries': s.get('total_queries', 0),
        'unbound_recursive_qps': s.get('num_recursive_described', 0),
    }

Hit-rate = cache_hits / (cache_hits + cache_misses). Before convergence it’s often 55%-65%; after, 90%+, meaning a large chunk of duplicate recursion is absorbed locally.

5. Cost/latency estimate + Telegram report

On every policy change, auto-compute the hit-rate and egress-traffic delta and push it to Telegram:

# dns_report.py
def estimate(before, after):
    bh = before['cache_hits'] / max(before['cache_hits'] + before['cache_misses'], 1)
    ah = after['cache_hits'] / max(after['cache_hits'] + after['cache_misses'], 1)
    egress_drop = (1 - after['recursive_qps'] / max(before['recursive_qps'], 1)) * 100
    return bh, ah, egress_drop

Telegram message template:

🌐 DNS Optimization Report 2026-10-18
────────────────────
Cache hit-rate: 61% → 93%
Recursive QPS:  2.4 → 0.6 (↓75%)
Egress resolution: down ~70%
  - api.internal → local self-answer (egress zeroed)
  - s3.example   → anycast convergence
  - pypi.org     → short TTL + negative cache
────────────────────
Zero data exfiltration ✓ Local Ollama inference ✓

Security Boundaries

The whole chain leaks no sensitive data: resolution profiles are aggregated on the host, LLM inference runs on local Ollama, and the only thing that leaves is the necessary upstream DNS query itself (that’s the job of resolution) — and convergence actually reduces that egress.

Measured Results

On a 4GB/200GB VPS running 6 services, over 7 days:

Summary

The essence of DNS optimization is letting each domain live locally with the cache policy that fits it, and converging duplicate recursion to the minimum. The LLM’s value isn’t speed — hit/miss thresholds could split hot from cold — it’s the business-semantic judgment: two cold domains behave differently; api.internal’s A record barely changes and can grow to 1-hour local self-answer, while pypi.org’s index updates often and must stay on short TTL. An LLM distinguishes that; a pure rules engine can’t.

Deployment tips:

1. Run 7 days of profile collection first so each domain’s QPS/hit/TTL/failure sample is sufficient;
2. dry-run the LLM policy output, verify manually, then unbound-control reload;
3. Use local self-answer only for fixed internal records — never static-override external domains (you’d read stale IPs);
4. Tighten negative-cache TTL to 30-60s — stops repeated recursion without masking upstream outages;
5. Watch hit-rate and recursive QPS via Prometheus, auto-run policy + report weekly, push to Telegram.