GodNS: A DNS Proxy That Lies for a Living

Hook

Every security tool does one thing well, but GodNS does something most developers never think about: it makes the internet's phonebook lie convincingly enough to fool both humans and malware.

Context

DNS manipulation has been a staple of offensive security testing for decades, but traditional approaches have always involved trade-offs. You could modify /etc/hosts files for simple redirections, but that requires host access and doesn't scale. You could deploy a full DNS server like BIND or PowerDNS, but configuring them for selective spoofing is like using a bulldozer to plant flowers. Python-based tools like DNSChef emerged to fill this gap, offering lightweight DNS manipulation for penetration testers, but they brought their own baggage: runtime dependencies, slower performance, and deployment friction.

GodNS entered this landscape as a spiritual successor to DNSChef, reimagined in Go. The value proposition is elegantly simple: a single statically-compiled binary that sits between clients and legitimate DNS servers, selectively lying about DNS records based on rules you define. Whether you're redirecting malware command-and-control traffic in a sandbox, testing phishing resilience, or analyzing how applications handle DNS poisoning, GodNS gives you surgical control over DNS responses without the overhead of a full DNS infrastructure. It's explicitly designed for offensive security workflows—pentesting, malware analysis, and reverse engineering—where you need to manipulate network reality on demand.

Technical Insight

At its core, GodNS is a DNS proxy with a pattern-matching brain. When a DNS query arrives, it flows through a rule engine that decides whether to forward it transparently or inject a spoofed response. The architecture is refreshingly straightforward: listen on UDP/TCP port 53, match incoming queries against configured patterns, and either return forged records or proxy to an upstream DNS server.

The pattern matching system offers two modes: glob patterns for simplicity and regex for surgical precision. A glob pattern like *.evil.com catches all subdomains, while a regex pattern like ^api[0-9]+\.target\.com$ lets you target specific naming schemes. Here's how you'd use the CLI for quick A record spoofing:

# Redirect all Google DNS queries to your phishing server
./godns -A "*.google.com=192.168.1.100" -upstream 8.8.8.8:53

# Spoof multiple domains with different IPs
./godns -A "*.bank.com=10.0.0.50" -A "*.evil.com=10.0.0.51" \
  -upstream 1.1.1.1:53

For complex scenarios, GodNS supports JSON and YAML configuration files that unlock its full record-type coverage. The configuration schema separates rules by record type, allowing you to forge A, AAAA, CNAME, PTR, MX, NS, SRV, SOA, and TXT records simultaneously. This is where GodNS shines for sophisticated attacks:

upstream: "8.8.8.8:53"
listenAddr: ":53"
rules:
  A:
    - pattern: "*.target.com"
      type: "glob"
      answer: "192.168.1.50"
    - pattern: "^api[0-9]+\.example\.com$"
      type: "regex"
      answer: "10.0.0.100"
  CNAME:
    - pattern: "www.legitimate.com"
      type: "glob"
      answer: "phishing.attacker.com"
  MX:
    - pattern: "*.corporate.com"
      type: "glob"
      answer: "mail.interceptor.com"
      priority: 10
  TXT:
    - pattern: "_spf.target.com"
      type: "glob"
      answer: "v=spf1 include:attacker.com ~all"

This configuration demonstrates a multi-vector attack: redirecting web traffic via A records, hijacking CNAMEs for subdomain takeover simulation, intercepting email via MX record spoofing, and even manipulating SPF records to test email security posture. The rule precedence is deterministic—first match wins—which gives you fine-grained control over overlapping patterns.

The implementation leverages Go's miekg/dns library for RFC-compliant DNS handling, which means GodNS speaks proper DNS protocol and can handle edge cases that naive implementations miss. The static compilation model produces a single binary with zero runtime dependencies, making deployment trivial. You can cross-compile for 20+ platform combinations, including ARM devices for embedded scenarios (think Raspberry Pi in a physical pentest) or exotic platforms like Plan 9 for research environments.

One architectural detail worth noting: GodNS doesn't cache responses. Every query either matches a rule and gets spoofed immediately, or gets proxied upstream. This design choice prioritizes real-time accuracy over performance—critical when you're analyzing malware that might change behavior based on DNS response timing or TTL values. The lack of caching also means you see every DNS query in real-time, which is valuable for understanding application behavior during security testing.

The blocking capability deserves special attention for malware analysis workflows. By specifying rules without answers, you can selectively black-hole domains:

# Block all command-and-control domains for malware analysis
./godns -A "*.malicious-c2.com=" -upstream 8.8.8.8:53

This returns NXDOMAIN responses, letting you observe how malware handles failed DNS resolution without actually connecting to attacker infrastructure. Combined with network isolation, it creates a safe sandbox for analyzing suspicious binaries.

Gotcha

The elephant in the room is encrypted DNS. GodNS operates exclusively on traditional UDP/TCP DNS traffic, which means it's blind to DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), or DNS-over-QUIC. As browsers and operating systems increasingly default to encrypted DNS, the attack surface for tools like GodNS shrinks. You'll need to either disable encrypted DNS on target systems or use network-level blocking to force fallback to traditional DNS—both of which reduce the realism of your testing scenarios.

Network positioning is the second major hurdle. GodNS must be in the path between clients and legitimate DNS servers, which requires either ARP spoofing, routing manipulation, being the DHCP-advertised DNS server, or having clients explicitly configured to use your GodNS instance. This isn't a limitation of the tool itself, but it adds operational complexity. In controlled lab environments, this is trivial. In red team engagements or production network testing, it requires careful planning and additional tooling. The documentation doesn't provide much guidance on deployment strategies, so you're expected to understand offensive network positioning already—this isn't a beginner-friendly tool despite the simple CLI interface.

Verdict

Use GodNS if you're conducting penetration tests where DNS manipulation is part of your attack chain, analyzing malware in sandboxed environments where you need to control C2 resolution, or testing application resilience against DNS poisoning attacks. It's particularly valuable when you need quick, surgical DNS spoofing without deploying full DNS infrastructure, or when cross-platform portability matters (testing on ARM devices, unusual architectures, or creating portable toolkits). The single-binary deployment and clean CLI make it perfect for automation in CI/CD security pipelines. Skip if you need to intercept encrypted DNS traffic (DoH/DoT), require a production DNS server with caching and high availability, want a defensive DNS filtering solution like Pi-hole, or lack the network positioning to intercept DNS traffic. Also skip if you're uncomfortable with offensive security tools—this is explicitly designed for authorized security testing and malware analysis, not general-purpose DNS serving.