Developer DNS / Local testing

DNS Server for developers

Development teams often need predictable DNS behavior: local domains, wildcard subdomains, test mail records, service discovery, and controlled forwarding.

When this is useful

A developer DNS server is useful when an application behaves differently depending on hostnames, subdomains, mail records, service discovery, or private network names. Instead of hard-coding IP addresses or editing the hosts file repeatedly, you can create a local zone that behaves like a small controlled DNS environment.

This helps with microservices, multi-tenant subdomains, local HTTPS setups, integration tests, internal tools, and software that needs realistic DNS responses before it is deployed.

What developers can test

  • A and AAAA records for local services.
  • CNAME records for aliases and domain redirects.
  • TXT records for verification and application metadata.
  • MX records for mail-related tests.
  • SRV records for service discovery.
  • Wildcard records such as *.wild for generated subdomains.

Example local domain

project.local      A      127.0.0.10
api.project.local  A      127.0.0.11
*.dev.project.local A     127.0.0.20

This lets a project resolve names locally without modifying public DNS and without hard-coding every host in the Windows hosts file.

Project-friendly workflow

Use Portable mode when each project needs its own DNS setup. Use Service mode when the workstation or test machine should keep the same DNS behavior across restarts.

Start with Free mode for local development. Upgrade to Pro when the machine needs to run continuously without the 48-hour restart limit.