When managing multiple subdomains under a parent domain (e.g., aaa.example.com, bbb.example.com), developers often face redundancy when manually adding each entry to the hosts file. While *.example.com seems like an intuitive solution, neither Windows nor Linux natively support wildcard DNS entries in hosts files.

The hosts file operates at a lower level than DNS resolvers and follows simple text-matching rules. Consider this attempted configuration:

# DOES NOT WORK (Linux/Windows)
192.168.1.100  *.example.com

The asterisk character has no special meaning in hosts file parsing - it's treated as a literal character.

Option 1: Local DNS Server Setup

For development environments, setting up a local DNS server like dnsmasq provides proper wildcard support:

# dnsmasq.conf configuration
address=/example.com/127.0.0.1

Option 2: Automated Hosts File Generation

Create a script to dynamically generate entries:

# generate_hosts.sh (Linux/macOS)
#!/bin/bash
BASE_IP="192.168.1.100"
DOMAIN="example.com"
SUBDOMAINS=("dev" "test" "api" "staging")

echo "# Auto-generated hosts entries" | sudo tee -a /etc/hosts
for sub in "${SUBDOMAINS[@]}"; do
  echo "$BASE_IP ${sub}.${DOMAIN}" | sudo tee -a /etc/hosts
done

Option 3: Browser Extension Override

For web development, extensions like "HostAdmin" (Chrome) or "Hosts Switcher" (Firefox) can manage domain redirections without system file modifications.

For larger teams:

• Configure wildcard DNS (e.g., *.dev.example.com) in your internal DNS server
• Use Kubernetes Ingress with wildcard host routing
• Implement Docker container naming conventions that resolve to subdomains

PowerShell script for automated hosts management:

# Add-WildcardHosts.ps1
$ip = "192.168.1.100"
$domain = "example.com"
$subdomains = @("api","admin","cdn")

$hostsPath = "$env:windir\System32\drivers\etc\hosts"
$entries = $subdomains | ForEach-Object { "$ip ${_}.$domain" }
Add-Content -Path $hostsPath -Value $entries -Force

When implementing wildcard solutions:

• Never expose wildcard DNS in production environments
• Use different TLDs for development (e.g., .test, .localhost)
• Regularly audit your hosts file for deprecated entries

When developing locally or testing multiple subdomains (e.g., api.project.local, admin.project.local), adding each entry to the hosts file becomes tedious:

# Traditional approach (inefficient)
127.0.0.1 aaa.xxx.zzz
127.0.0.1 bbb.xxx.zzz
127.0.0.1 ccc.xxx.zzz
# ...and so on for dozens of subdomains

The hosts file doesn't support wildcard DNS entries like *.xxx.zzz because:

• It's a simple text-based resolution system
• Follows "first match" principle without pattern matching
• Designed for explicit IP-to-hostname mapping

1. Using dnsmasq (Linux/macOS)

# Install dnsmasq
sudo apt-get install dnsmasq

# Configure /etc/dnsmasq.conf
address=/xxx.zzz/127.0.0.1

# Restart service
sudo systemctl restart dnsmasq

2. Windows Alternative: Acrylic DNS Proxy

# In AcrylicHosts.txt
127.0.0.1 *.xxx.zzz

3. Local Development with Traefik/Nginx

For web projects, configure a reverse proxy:

# Example Traefik dynamic configuration (docker-compose.yml)
labels:
  - "traefik.http.routers.app.rule=HostRegexp({subdomain:[a-z]+}.xxx.zzz)"
  - "traefik.http.services.app.loadbalancer.server.port=3000"

Create a script to generate entries:

#!/bin/bash
# generate_hosts.sh
DOMAINS=("api" "admin" "staging" "test")
for domain in "${DOMAINS[@]}"; do
  echo "127.0.0.1 ${domain}.xxx.zzz" >> /etc/hosts
done

• Always back up your hosts file before modifications
• Flush DNS cache after changes (ipconfig /flushdns on Windows)
• For production environments, use proper DNS wildcard records