Skip to content
View Ozy-666's full-sized avatar

Block or report Ozy-666

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Maximum 250 characters. Please don’t include any personal information such as legal names or email addresses. Markdown is supported. This note will only be visible to you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
Ozy-666/README.md

Ozy-666 — Systems & Network Engineer

TSI alumnus (IT, Class of '05). I build and run high-availability, high-concurrency edge infrastructure — zero-allocation Go network daemons, Linux kernel tuning (XDP, nftables), and aggressive codebase stripping to cut runtime overhead and attack surface.

My main project is DNSDOH.ART — a public encrypted-DNS resolver I build and run as a hobby. No logs, no telemetry, no company behind it. → ozy-666.github.io


🛡️ Active R&D — DDoS mitigation (L4 / L7)

The goal behind all of it: a single node that simply does not fall over.

  • L4, kernel-space (eBPF/XDP): packet-filtering engines in Go that drop volumetric garbage (SYN floods, UDP amplification) at the NIC driver level — before the kernel ever allocates an sk_buff.
  • L7, user-space (Go / nginx): zero-allocation byte parsers that rate-limit and sanitize malicious DoH / HTTP requests.
  • Dynamic nftables orchestration: a Go control plane talking to nftables over Netlink sockets, pushing real-time blocklists straight into kernel-space sets to isolate abusers with minimal CPU cost.

⚙️ The resolver behind it — DNSDOH.ART

A single, carefully-tuned server — not a global anycast network — running encrypted DNS over DoH, DoH3 (QUIC), DoQ and DoT, with ad/tracker blocking and a strict no-logs policy. The focus is reliability and zero tolerance for DDoS and abuse, not out-scaling the big providers.

🧰 The hardened Go stack

  • AdGuardHome-edge-spec — the engine: a stripped-down AdGuard Home fork (~13k LOC removed, zero-allocation hot paths, Unbound on BoringSSL).
  • dnsproxy — transport fork: pooled connections, SO_REUSEPORT listener sharding, lock-free upstream RTT map.
  • dnscrypt-proxy — encrypted-upstream fork: sync.Pool packet buffers (0 B/op on hot paths), monitoring compiled out, security-audited.
  • urlfilter — filtering engine: AST-based required-literal extraction (O(1) regex miss paths).
  • dns-ultra — upstream resolver profiler: separates warm-cache from uncached lookups so a slow authoritative walk can't misrank a good anycast resolver, and prints a ready-to-paste config.

🧱 The C edge — build tooling, not forks

The TLS and DNS daemons themselves are stock. Every customisation lives in build flags, configuration and systemd units, and both scripts fetch the official upstream release at build time — so there is no source tree to re-sync and nothing to merge on each release.

  • nginx-edge — BoringSSL-linked nginx: HTTP/3, post-quantum key exchange, Zen 2 tuning, plus annotated TLS-hardening and L7 anti-DDoS example configs. Carries one patch: server-side Encrypted Client Hello, which nginx implements only against the OpenSSL 3.x API and not BoringSSL.
  • unbound-edge — BoringSSL-linked, Zen 2-optimised Unbound. BoringSSL was chosen on measured DNSSEC throughput, not assumed parity, and the repo ships the benchmark that re-proves it after every library bump.

🤖 How I work

Profile-driven: every change is proven with pprof / benchstat on real hardware before it ships, and the dead-ends get documented alongside the wins. Static analysis, profiling and refactoring done with AI tooling (Claude Code, Gemini / AI Studio CLI) in the loop.


Career note: I left IT around 2012. I came back to it in 2022 when I started DNSDOH.ART — the first few years were self-taught by trial and error; from late 2025 I started measuring things properly instead of guessing. It's evenings-and-weekends work, not a day job — which is also why there's no company behind DNSDOH.ART and never will be.

QA & uptime inspection: Maine Coon Michelle 🐾 — sits on the keyboard during deploys. Zero incidents attributable to her so far.

Pinned Loading

  1. AdGuardHome-edge-spec AdGuardHome-edge-spec Public

    Public specification and optimization logs of the private AdGuardHome & dnsproxy fork used in dnsdoh.art

  2. nginx-edge nginx-edge Public

    BoringSSL-linked nginx build tooling with HTTP/3, Encrypted Client Hello and post-quantum key exchange, optimised for AMD Zen 2 - plus annotated TLS hardening and L7 anti-DDoS examples

    Shell 1

  3. unbound-edge unbound-edge Public

    BoringSSL-linked, Zen 2-optimised Unbound build tooling and config for the dnsdoh.art edge resolver

    Shell

  4. dnscrypt-proxy dnscrypt-proxy Public

    Forked from DNSCrypt/dnscrypt-proxy

    High-performance dnscrypt-proxy 2 edge fork (GOAMD64=v3). Upstream layer for Unbound: AGH-Edge → Unbound → dnscrypt-proxy → encrypted upstreams.

    Go

  5. dns-ultra dns-ultra Public

    Find the fastest DNS resolvers for your dnscrypt-proxy setup. Works great with Unbound and AdGuardHome stacks - tests real queries, not synthetic pings.

    Shell 1

  6. dnsproxy dnsproxy Public

    Forked from AdguardTeam/dnsproxy

    AdGuard dnsproxy fork: pooled connections, SO_REUSEPORT listener sharding, lock-free upstream RTT map. Transport layer for the dnsdoh.art edge stack.

    Go