Every time you type a URL into your browser, a complex set of protocols—some decades old, some very new—springs into action to find the right IP address. During the AIORI-2 Hackathon, our team, DDos Duo from the Heritage Institute of Technology, set out to modernize this foundational process. We built a high-performance DNS Load Balancer that bridges the gap between the original DNS standards of the 1980s and the high-speed requirements of 2026.
1. The Architectural Foundation: Core DNS & EDNS0
Our system is built on the bedrock of RFC 1034 and RFC 1035, which define how DNS queries are structured and sent. However, original DNS was limited to 512-byte packets. To support modern, feature-rich responses, we implemented EDNS0 (RFC 6891).
By implementing EDNS0, our load balancer can negotiate “Extended UDP” payloads. This allows the system to handle packets up to 4096 bytes, ensuring that large DNSSEC-signed responses or complex records aren’t truncated, which would otherwise force a slow fallback to TCP.
2. High-Performance Engineering
Performance isn’t just about speed; it’s about stability under pressure. Our load balancer was written in C++17 and optimized for the Linux kernel using SO_REUSEPORT to distribute incoming UDP traffic across multiple CPU cores.
| Metric | Achievement | Operational Context |
|---|---|---|
| Peak Throughput | 67,000 QPS | Sustained high-volume traffic handling. |
| Average Latency | 2.3 ms | Near-instantaneous redirection of queries. |
| Cache Hit Rate | ~70% | Drastic reduction in backend server load. |
| Protocol Support | EDNS0 / RRL | Compliant with modern security extensions. |
3. Resilience and Security: Response Rate Limiting (RRL)
DNS is frequently abused in “Amplification Attacks,” where small queries are used to generate massive responses directed at a victim. To mitigate this, we looked to RFC 8198 and implemented Response Rate Limiting (RRL).
Our system tracks query volume per source IP. If an IP exceeds a safety threshold, the load balancer can “dampen” the responses or drop them entirely, protecting both our infrastructure and the rest of the Internet from being used in a DDoS attack.
4. Implementation Workflow & Testing
We used the AIORI Testbed to simulate a real-world network environment with multiple authoritative backends and recursive resolver clients.
- Parsing: Extracting the DNS Question and Header fields.
- Health Check: Periodically “pinging” backends to ensure they are alive.
- Selection: Choosing a backend based on Round-Robin or IP-Hashing logic.
- Verification: Using dnsperf to stress-test the system and dig to verify packet integrity.
5. Lessons from the AIORI Testbed
Our sprints taught us that interoperability is the ultimate test. While a system might work in a lab, it must handle the quirky, non-standard behaviors of various DNS clients in the wild. Following RFC 1035 precisely ensured that our load balancer remained “invisible” to the end-user while providing a massive boost in reliability.
“Working on DNS made me realize how important RFC standards are in keeping the Internet reliable. Building this taught me how small code changes—like UDP buffer tuning—can vastly affect global performance.” — Team DDos Duo
6. Future Work: The Path to XDP
Our next goal is to move query handling into the XDP (Express Data Path) layer of the Linux kernel. By processing DNS packets directly in the network driver before they even reach the operating system, we aim to push our performance beyond 100,000 QPS.
Read the full report
