DNSChef earned its permanent spot in my toolkit the first time I needed to test malware behavior in a sandbox without letting it actually reach the internet — pointing it at a fake DNS server that answers every lookup with a controlled IP let me watch exactly what it tried to connect to, safely. That’s the core idea behind DNSChef: a highly configurable DNS proxy built specifically for penetration testers and malware analysts. Here’s the complete guide, tested live.
What Is DNSChef?
DNSChef is a Python-based DNS proxy created by iphelix (Peter Kacherginsky) that lets you selectively fake DNS responses for specific domains while transparently proxying everything else to a real, upstream DNS server. Unlike a full DNS spoofing/poisoning attack tool, DNSChef is a proxy you configure a client (or an entire network segment) to use directly — it doesn’t perform ARP poisoning or any positioning attack itself; it’s the DNS server component of a broader testing setup.
Why Use a Configurable DNS Proxy?
- Malware analysis: redirect a malware sample’s command-and-control domain lookups to a sandbox host you control, so you can observe and log exactly what it tries to do next.
- Application testing: force a specific hostname to resolve to a test server instead of production, without touching
/etc/hostson every test client, and without needing DNS server admin access. - Penetration testing: as part of a MITM setup, redirect specific target domains (e.g., a corporate webmail or VPN portal hostname) to a phishing/credential-capture page in a fully authorized, scoped engagement.
- Network segmentation testing: verify what happens when clients are forced to resolve certain domains to unexpected addresses, useful for testing egress filtering and DNS-based security controls.
Installing DNSChef
DNSChef isn’t on PyPI or standard distro repos — it’s installed from GitHub:
git clone https://github.com/iphelix/dnschef.git
cd dnschef
pip install -r requirements.txt --break-system-packages
Confirmed dependency:
dnslib==0.9.10
Kali Linux ships DNSChef preinstalled.
Verify with the help output, which also displays the version banner:
python3 dnschef.py --help
Real, tested output (banner):
usage: dnschef.py [options]:
_ _ __
| | version 0.4 | | / _|
__| |_ __ ___ ___| |__ ___| |_
/ _` | '_ \/ __|/ __| '_ \ / _ \ _|
| (_| | | | \__ \ (__| | | | __/ |
\__,_|_| |_|___/\___|_| |_|\___|_|
iphelix@thesprawl.org
DNSChef is a highly configurable DNS Proxy for Penetration Testers and Malware
Analysts. It is capable of fine configuration of which DNS replies to modify
or to simply proxy with real responses. In order to take advantage of the tool
you must either manually configure or poison DNS server entry to point to
DNSChef. The tool requires root privileges to run on privileged ports.
That description in the tool’s own help text is worth reading twice: DNSChef itself doesn’t poison anything — you still need a separate mechanism (manual client configuration, DHCP, or a poisoning tool like Ettercap/arpspoof/Responder) to actually get traffic pointed at it.
Basic Syntax and Key Options
Confirmed options from dnschef.py --help:
Fake DNS records:
--fakedomains Comma-separated domains to resolve to FAKE values (all others get TRUE values)
--truedomains Comma-separated domains to resolve to TRUE values (all others get FAKE values)
--fakeip IP to use for matching 'A' queries
--fakeipv6 IPv6 address to use for matching 'AAAA' queries
--fakemail MX name to use for matching queries
--fakealias CNAME name to use for matching queries
--fakens NS name to use for matching queries
--file File of DOMAIN=IP pairs for fine-grained control
Runtime parameters:
--logfile FILE Log all activity to a file
--nameservers Comma-separated list of real upstream DNS servers to proxy to
-i, --interface Interface/IP to listen on (default 127.0.0.1 / ::1)
-t, --tcp Use TCP instead of UDP
-6, --ipv6 Run in IPv6 mode
-p, --port Port to listen on (default 53)
-q, --quiet Suppress header banner
Basic Usage — Fake All A Records
The simplest possible setup: answer every single A record query with the same fake IP:
sudo python3 dnschef.py --fakeip 192.0.2.123
Targeted Domain Spoofing (Tested Live)
More realistically, you only want to fake specific domains and let everything else resolve normally. This was tested end-to-end:
python3 dnschef.py --fakeip 192.0.2.123 --fakedomains evil-test.local -p 5353 -i 127.0.0.1 -q
Querying the spoofed domain with dig:
dig @127.0.0.1 -p 5353 evil-test.local +short
Real, confirmed output:
192.0.2.123
Querying an unrelated domain through the same running instance:
dig @127.0.0.1 -p 5353 example.com +short
Real, confirmed output — correctly proxied to the actual public IPs for the domain rather than the fake value:
172.66.147.243
104.20.23.154
And the DNSChef console log during this exact test confirmed both behaviors explicitly:
[*] Listening on an alternative port 5353
[*] DNSChef started on interface: 127.0.0.1
[*] Using the following nameservers: 8.8.8.8
[*] Cooking A replies to point to 192.0.2.123 matching: evil-test.local
[*] 127.0.0.1: cooking the response of type 'A' for evil-test.local to 192.0.2.123
[*] 127.0.0.1: proxying the response of type 'A' for example.com
This confirms exactly the tool’s documented split behavior: matched domains get “cooked” (faked) responses, and everything else is transparently proxied to a real upstream nameserver (Google’s 8.8.8.8 by default).
Using a Domain=IP Mapping File
For managing many domain mappings at once, use --file with a simple text file:
# spoofmap.txt
internal-app.example.com=192.0.2.50
webmail.example.com=192.0.2.51
sudo python3 dnschef.py --file spoofmap.txt -i 0.0.0.0 -p 53
Choosing a Real Upstream Nameserver
By default, DNSChef proxies unmatched queries to Google’s public DNS. Override this with --nameservers:
sudo python3 dnschef.py --fakeip 192.0.2.123 --fakedomains target.local \
--nameservers 1.1.1.1,9.9.9.9 -i 0.0.0.0 -p 53
Running as a TCP DNS Proxy
sudo python3 dnschef.py --fakeip 192.0.2.123 -t -p 53
Faking Other Record Types
Beyond A records, DNSChef supports faking MX (mail), CNAME (alias), NS (nameserver), and AAAA (IPv6) records:
sudo python3 dnschef.py \
--fakemail mail.fake-corp.test \
--fakealias www.fake-corp.test \
--fakedomains target-corp.example.com
Logging All Activity
sudo python3 dnschef.py --fakeip 192.0.2.123 --fakedomains target.local --logfile dnschef.log
This produces a plain-text, timestamped log of every query seen and every response given (cooked or proxied) — invaluable for building a timeline during malware analysis or documenting exactly what was resolved during a penetration test.
How DNSChef Works Internally
- Socket binding: DNSChef binds a UDP (or TCP, with
-t) socket on the configured interface and port, using thednsliblibrary to handle low-level DNS wire-format parsing and construction. - Query inspection: for every incoming DNS query, it checks the queried name against its configured fake-domain rules (
--fakedomains,--truedomains,--filemappings) and the record type being requested. - Decision branch: if the query matches a configured fake rule, DNSChef constructs a forged response record (A/AAAA/MX/CNAME/NS as appropriate) using
dnsliband returns it directly — no upstream lookup happens for matched queries. - Transparent proxying: if the query doesn’t match any fake rule, DNSChef forwards the query unmodified to one of the configured upstream nameservers (
--nameservers, defaulting to8.8.8.8/Google Public DNS), waits for the real response, and relays it back to the original client exactly as received. - Logging: every cooked or proxied response is logged to the console (unless
-q) and optionally to a file via--logfile, giving a full audit trail of every decision DNSChef made.
Real-World Use Cases (Authorized Lab/Sandbox Environments Only)
1. Malware dynamic analysis Configuring an isolated malware analysis sandbox’s DNS to point at DNSChef, faking every domain to the sandbox’s own IP (or a specific analysis service), lets analysts observe exactly what a sample tries to reach without any risk of live C2 communication reaching the actual internet.
2. Application and infrastructure testing Redirecting a specific hostname (e.g., a payment gateway or third-party API endpoint) to a local test double during QA testing, without needing to modify /etc/hosts on every test machine individually — especially useful across an entire test VLAN at once.
3. Authorized phishing/credential capture simulations As one component of a broader, fully scoped social engineering assessment, redirecting a target’s internal DNS resolution for a specific corporate hostname toward a controlled, monitored capture page — always with explicit written authorization and defined scope.
4. DNS security control validation Testing whether DNS-over-HTTPS, DNSSEC validation, or network-level DNS monitoring correctly detects or resists a rogue/forged DNS proxy in the resolution path.
Integration with Other Tools
- Ettercap / arpspoof / Responder: DNSChef is the “answer engine,” but something else usually needs to get traffic pointed at it in the first place — ARP spoofing redirects LAN clients’ actual DNS traffic to DNSChef’s listener.
- iptables/DNAT: an alternative to ARP-based redirection — transparently redirecting all outbound port-53 traffic on a lab gateway to DNSChef instead.
- Wireshark: used to confirm exactly what DNS traffic is flowing and being answered during a test.
- Malware sandboxes (Cuckoo, CAPE, etc.): DNSChef is a common component in custom sandbox network configurations for safely observing malware DNS behavior.
Troubleshooting and Common Mistakes
- “Permission denied” binding port 53 — binding privileged ports (<1024) requires root; either run with
sudoor use a high port (like the tested-p 5353) for local development. - Fake domain not matching — domain matching is generally case-sensitive and exact per the configured pattern; double check trailing dots or subdomain variations (
www.target.localvstarget.localare different entries). - Unmatched queries timing out — verify
--nameserverspoints to a genuinely reachable upstream DNS server from wherever DNSChef is running, especially in a restricted lab network. - Client isn’t actually using DNSChef — confirm the client’s resolver configuration (
/etc/resolv.conf, DHCP-provided DNS, or explicit override) actually points at DNSChef’s listening IP/port; DNSChef itself doesn’t force this. - SyntaxWarning about escape sequences at startup — a cosmetic issue in the banner-printing code on newer Python versions; it doesn’t affect functionality.
Best Practices
- Run DNSChef with
--logfileenabled by default for any investigative or forensic use — the query/response log is often the most valuable output of the entire session. - Keep fake-domain lists as narrow and explicit as possible (
--fakedomains/--file) rather than faking everything (--fakeipalone), to avoid unintended collateral disruption in shared lab environments. - Isolate malware analysis sandboxes at the network level (not just DNS) — DNSChef controls name resolution, not actual traffic routing, so a sample could still reach the internet directly via a hardcoded IP if egress isn’t also restricted.
- Document which domains were faked and to what values for every test session, especially in shared or multi-analyst environments.
FAQ
Does DNSChef perform DNS spoofing/poisoning itself? No — it’s a DNS proxy you must explicitly point clients at (via manual config, DHCP, or a separate redirection/poisoning technique). It doesn’t inject forged responses onto a network on its own.
Can DNSChef intercept DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) traffic? Not directly — DNSChef proxies standard plaintext DNS. A client using DoH/DoT to a hardcoded resolver (like 1.1.1.1 over HTTPS) bypasses DNSChef entirely unless that traffic is separately intercepted or blocked at the network layer.
Is DNSChef safe to use for malware analysis? It’s a standard component of many malware sandbox setups, but DNS control alone isn’t full network isolation — always pair it with proper network-level containment (no real internet egress) for genuine safety.
What’s the difference between --fakedomains and --truedomains? --fakedomains lists domains that get faked, with everything else resolved truthfully; --truedomains inverts this — listed domains resolve truthfully, and everything else gets faked. Use whichever gives you the shorter, more maintainable list for your scenario.
Does DNSChef support IPv6? Yes, via -6/--ipv6 for IPv6 mode and --fakeipv6 for faking AAAA records specifically.
Summary
DNSChef does one job cleanly: sit as a DNS proxy that fakes exactly the responses you configure while transparently passing everything else through to a real resolver. That precision — rather than a blunt “fake everything” approach — is what makes it genuinely useful for malware analysis, application testing, and authorized DNS-based penetration testing scenarios where you need surgical control over name resolution.
References
- Official GitHub repository: https://github.com/iphelix/dnschef
- README/documentation: https://github.com/iphelix/dnschef/blob/master/README
- Author’s project page: https://thesprawl.org/projects/dnschef/
