When working in an enterprise environment with OpenWrt, you might encounter situations where internal domains need resolution through corporate DNS servers. The typical scenario involves:

Office Network → Enterprise Router (DHCP+DNS) → Internal domains
               ↘ OpenWrt Router → Client devices

Here's how to properly set up DNS forwarding in OpenWrt:

1. Access your OpenWrt router's LuCI interface
2. Navigate to Network → DHCP and DNS
3. Under the "Resolve and Hosts" tab, configure:

config dnsmasq
    option domainneeded '1'
    option boguspriv '1'
    option filterwin2k '0'
    option localise_queries '1'
    option rebind_protection '1'
    option rebind_localhost '1'
    option local '/lan/'
    option domain 'yourdomain.corp'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.auto'
    option noresolv '0'
    list server '192.168.1.1'  # Enterprise DNS server 1
    list server '192.168.1.2'  # Enterprise DNS server 2

If you need to force all DNS traffic through enterprise servers:

# Edit /etc/config/dhcp
config dnsmasq
    option noresolv '1'  # Disable ISP DNS
    option localservice '0'  # Allow non-local queries
    list server '/yourdomain.corp/192.168.1.1'
    list server '//192.168.1.1'

Verify your configuration with these commands:

# Check active DNS servers
cat /tmp/resolv.conf.auto

# Test DNS resolution
nslookup internal-host.yourdomain.corp 127.0.0.1

# Check dnsmasq queries
logread | grep dnsmasq

Ensure your firewall allows DNS traffic to enterprise servers:

# /etc/config/firewall
config rule
    option name 'Allow-DNS-Forwarding'
    option src 'lan'
    option dest 'wan'
    option proto 'tcpudp'
    option dest_port '53'
    option target 'ACCEPT'
    option dest_ip '192.168.1.1,192.168.1.2'

• Clear DNS cache: /etc/init.d/dnsmasq restart
• Verify enterprise DNS accessibility from OpenWrt: nslookup google.com 192.168.1.1
• Check for conflicting DHCP options

When using OpenWrt in an office environment, you might encounter DNS resolution issues for internal domains. The typical scenario:

• Your OpenWrt router connects to the corporate network
• Devices behind OpenWrt can get IP addresses via DHCP
• Internal domain names fail to resolve while IP access works
• Simply adding DNS forwarders in LuCI doesn't solve the problem

OpenWrt uses dnsmasq as its default DNS forwarder. By default, it:

1. Acts as DNS cache
2. Handles DHCP leases
3. Only forwards to upstream servers when it can't resolve locally

To force all DNS queries to your enterprise servers:

# Edit the network configuration
uci set network.wan.peerdns='0'
uci set network.wan.dns='192.168.1.1 192.168.1.2'  # Replace with your enterprise DNS servers
uci commit network

# Configure dnsmasq
uci set dhcp.@dnsmasq[0].noresolv='1'
uci set dhcp.@dnsmasq[0].server='192.168.1.1'      # Primary DNS
uci set dhcp.@dnsmasq[0].server='192.168.1.2'      # Secondary DNS
uci commit dhcp

# Restart services
/etc/init.d/network restart
/etc/init.d/dnsmasq restart

For more complex scenarios, you might need to use a different DNS forwarder:

# Install pdnsd for advanced forwarding
opkg update
opkg install pdnsd

# Configure pdnsd
cat > /etc/pdnsd.conf << EOF
global {
    perm_cache=1024;
    cache_dir="/var/pdnsd";
    run_as="nobody";
    server_ip = 0.0.0.0;
    status_ctl = on;
}

server {
    label = "enterprise-dns";
    ip = 192.168.1.1, 192.168.1.2;
    timeout = 5;
    uptest = none;
    purge_cache = off;
}

source {
    owner=localhost;
    file="/etc/hosts";
}

rr {
    name=localhost;
    reverse=on;
    a=127.0.0.1;
    owner=localhost;
    soa=localhost,root.localhost,42,86400,900,86400,86400;
}
EOF

# Start pdnsd
/etc/init.d/pdnsd enable
/etc/init.d/pdnsd start

After configuration, test with:

nslookup internal.corp.domain 192.168.1.1
dig @192.168.1.1 internal.corp.domain

• Check firewall rules aren't blocking DNS traffic (port 53)
• Verify enterprise DNS servers are reachable from OpenWrt
• Monitor DNS queries with log-queries in dnsmasq
• Consider adding strict-order if having multiple upstream servers