Skip to content

feat: improve emergency DNS configuration logic#4962

Open
rz467fzs7d wants to merge 1 commit intovernesong:devfrom
rz467fzs7d:improve-emergency-dns
Open

feat: improve emergency DNS configuration logic#4962
rz467fzs7d wants to merge 1 commit intovernesong:devfrom
rz467fzs7d:improve-emergency-dns

Conversation

@rz467fzs7d
Copy link
Copy Markdown
Contributor

Summary

Improves the emergency DNS configuration logic to respect user's network settings and only activate when necessary.

Changes

  1. Add dnsmasq enabled check: Only perform DNS check when dnsmasq service is enabled
  2. Prioritize LAN DNS: Use network.lan.dns configuration as emergency DNS first
  3. Fallback mechanism: Only use hardcoded DNS (119.29.29.29, 8.8.8.8) when LAN DNS is not configured
  4. Multi-DNS support: Properly handle multiple DNS servers from LAN configuration

Motivation

Current implementation always writes hardcoded emergency DNS (119.29.29.29, 8.8.8.8) when DNS check fails, even when:

  • User has configured custom DNS in LAN interface
  • dnsmasq is disabled and another DNS service (e.g., AdGuardHome) is running

This causes unexpected DNS configuration and potential privacy concerns.

Test Plan

Tested on OpenWrt with:

  • dnsmasq disabled + AdGuardHome enabled
  • Custom LAN DNS configured
  • Verified emergency DNS uses LAN DNS instead of hardcoded values

Changes:
- Only check DNS when dnsmasq is enabled
- Prioritize using LAN interface DNS for emergency resolv.conf
- Fallback to hardcoded DNS (119.29.29.29, 8.8.8.8) only when LAN DNS is not configured
- Support multiple DNS servers from network.lan.dns configuration

This prevents unnecessary emergency DNS activation and respects user's network configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants