Feature Request: Comprehensive Cross-Platform DNS Client and Management Support
Description
I would like to request expanding the application into a complete, modern, and cross-platform DNS client/manager.
The goal is to support modern DNS protocols, privacy technologies, DNS routing and filtering, resolver discovery, reliability features, diagnostics, and system-wide DNS management across supported platforms.
The implementation should use a platform-independent core with platform-specific networking and DNS configuration backends where necessary.
The features below can be implemented incrementally and do not need to be introduced all at once.
- Standard DNS
Support traditional DNS transports:
- DNS over UDP (Do53 UDP)
- DNS over TCP (Do53 TCP)
- Encrypted DNS Protocols
Support modern encrypted DNS protocols:
- DoT — DNS over TLS
- DoH — DNS over HTTPS
- DoH2 — DNS over HTTP/2
- DoH3 — DNS over HTTP/3
- DoQ — DNS over QUIC
- DoDTLS — DNS over DTLS
- DNSCrypt
- PQDNSCrypt
- Anonymized DNSCrypt
- ODoH — Oblivious DNS over HTTPS
- ODoQ — Oblivious DNS over QUIC (Experimental)
- DNS Resolver Discovery
Support DNS resolver discovery mechanisms:
- DDR — Discovery of Designated Resolvers
- DNR — Discovery of Network-designated Resolvers
Note: DDR and DNR are not DNS transport protocols. They are resolver discovery mechanisms and should be implemented separately from the DNS transport layer.
- DNS Security and Privacy
Support advanced DNS security and privacy features:
- DNSSEC
- DNSSEC Validation
- DNSSEC status/testing
- EDNS
- EDNS Client Subnet (ECS)
- DNS Cookies
- QNAME Minimization
- DNS Cache Poisoning Protection
- Anonymized DNS
- DNS Routing
Support flexible DNS routing:
- Split DNS
- Split-Horizon DNS
- Per-Domain DNS
- Per-App DNS
- Per-Interface DNS
- Rule-Based DNS Routing
- Custom DNS Rules
- Hosts-based DNS
- Fake-IP DNS
Example:
Wi-Fi → Resolver A
Ethernet → Resolver B
VPN → VPN DNS
Domain X → Resolver C
Domain Y → Resolver D
- DNS Filtering
Support configurable DNS filtering:
- Ad-Blocking DNS
- Malware-Blocking DNS
- Custom blocklists
- Custom allowlists
- Custom DNS rules
- Hosts-based filtering
- Per-domain filtering
- DNS Reliability and Failover
Support mechanisms for maintaining DNS availability:
- DNS Failover
- Multiple upstream resolvers
- DNS Load Balancing
- DNS Fallback
- Automatic resolver switching
- Configurable resolver priority
- Health-based failover
- DNS Cache
- Bootstrap DNS
The application should be able to detect when a resolver becomes unavailable and automatically switch to a configured backup resolver.
- DNS Health Check and Benchmarking
Add built-in DNS diagnostics and benchmarking.
The application should test actual DNS resolution performance rather than relying only on ICMP ping.
Possible metrics:
- DNS query latency
- Resolution success rate
- Availability
- Failure rate
- DNSSEC support
- IPv4 support
- IPv6 support
- Supported DNS protocols
Example:
Cloudflare
Latency: 18 ms
Availability: 100%
DNSSEC: Supported
IPv4: ✓
IPv6: ✓
DoH3: ✓
Status: Healthy
A benchmark mode could compare multiple DNS providers and automatically rank them based on configurable criteria.
- Automatic Best DNS Selection
Add an optional Auto / Best DNS mode.
The application could automatically test configured DNS providers and select the best resolver based on:
- Latency
- Availability
- Reliability
- DNSSEC support
- IPv4/IPv6 support
- Protocol availability
- Failure rate
Users should be able to configure the selection criteria and priorities.
- DNS Leak Protection and Kill Switch
Add DNS leak protection.
For encrypted DNS configurations, provide an option such as:
Block Plain DNS
When enabled:
- Plain DNS traffic should be blocked or prevented where technically possible.
- The application should not silently fall back to an unencrypted resolver.
- DNS queries should only use the configured secure resolver(s).
Possible modes:
- Secure DNS only
- Secure DNS with encrypted fallback
- Allow plaintext fallback
Also provide a built-in DNS Leak Test showing:
- Current DNS servers
- Resolver hostname
- Public IP
- IPv4 DNS
- IPv6 DNS
- Whether the configured resolver is actually being used
- Whether DNS traffic is leaking to another resolver
- Cross-Platform System DNS Integration
The application should provide proper system-wide DNS integration on all supported platforms.
Instead of assuming a specific DNS backend, the application should detect the operating system and use the appropriate native networking/DNS APIs or configuration mechanisms.
Linux
Support where applicable:
- NetworkManager
- systemd-resolved
- systemd-networkd
- dnsmasq
- resolvconf/openresolv
- "/etc/resolv.conf"
Windows
Support the native Windows networking/DNS configuration mechanisms, including:
- Per-adapter DNS configuration
- IPv4/IPv6 DNS configuration
- Windows network interfaces
- Windows DNS Client integration
macOS
Support native macOS networking/DNS configuration mechanisms, including:
- Network services
- Wi-Fi
- Ethernet
- VPN interfaces
- IPv4/IPv6 DNS configuration
The application should use platform-specific backends behind a common abstraction layer so that the core DNS engine remains cross-platform.
- Network Change Detection
Detect network changes such as:
- Wi-Fi network changes
- Ethernet connection/disconnection
- Network interface changes
- VPN connection/disconnection
- DHCP changes
- System resume from sleep/hibernation
After a network change, the application should verify that the selected DNS configuration is still active and re-apply it if necessary.
- Safe Configuration, Backup, and Rollback
Because the application modifies system DNS settings, it should provide safe recovery mechanisms.
Features:
- Automatic DNS configuration backup
- Manual backup
- Restore previous DNS configuration
- Reset to system default DNS
- Automatic rollback if a new DNS configuration fails
- Configuration validation after applying changes
Suggested behavior:
Apply DNS configuration
↓
Validate DNS connectivity
↓
Successful?
↙ ↘
Yes No
↓ ↓
Keep Rollback
The application should never leave the system without a working DNS configuration because of a failed update.
- DNS Profiles
Allow users to create and switch between DNS profiles.
Example:
Privacy
→ Quad9 DoT + DNSSEC
Ad Blocking
→ AdGuard DoH3
Gaming
→ Fastest available resolver
Default
→ System DNS
A profile could contain:
- DNS provider
- Protocol
- IPv4/IPv6 configuration
- Routing rules
- Filtering rules
- Failover configuration
- DNSSEC settings
- Leak protection settings
Profiles should be portable across supported platforms where possible.
- Local DNS Proxy / System-Wide Encrypted DNS
Provide an optional local DNS proxy/listener for transparent system-wide encrypted DNS.
Example architecture:
Applications
↓
Local DNS Listener
↓
DNS Client / Proxy
↓
DoH / DoH3 / DoQ / DoT / DNSCrypt / ODoH
↓
Remote DNS Resolver
This would allow applications that only support traditional DNS to use modern encrypted DNS protocols transparently.
The local listener should be configurable and should support IPv4 and IPv6 where applicable.
- IPv4 and IPv6
Full support for:
- IPv4 DNS
- IPv6 DNS
- IPv4-only mode
- IPv6-only mode
- Dual-stack DNS
- IPv4/IPv6 fallback handling
The application should also detect IPv6 DNS leaks when IPv6 is enabled.
- Captive Portal Detection
Detect captive portals on networks such as:
- Hotels
- Airports
- Cafés
- Universities
- Public Wi-Fi
The application should notify the user when captive portal authentication is required and handle the transition between captive-portal networking and the configured DNS appropriately.
- Automatic Public IP Update
Add an Auto IP Update feature for DNS providers that require the client's public IP address to be registered or updated.
When enabled and configured, the application should automatically detect changes to the device's public IP address and notify the selected DNS provider whenever the IP changes.
Suggested features:
- Automatic public IP detection
- IPv4 support
- IPv6 support where applicable
- Periodic IP change checking
- Automatic provider notification/update
- Configurable update interval
- Manual "Update Now" option
- Current public IP display
- Last successful update status
- Retry mechanism
- Error handling
- Optional background/startup operation
This is useful for DNS providers that use public IP addresses for authentication, access control, custom DNS configurations, or dynamic DNS-style management.
- Bootstrap DNS
Support configurable bootstrap resolvers for encrypted DNS protocols.
Features:
- Custom bootstrap DNS
- Multiple bootstrap resolvers
- IPv4/IPv6 bootstrap
- Bootstrap fallback
- Configurable bootstrap behavior
- DNS Tunneling — Advanced / Experimental
If technically feasible, consider supporting DNS tunneling technologies separately from normal DNS transports:
- DNSTT
- iodine
- Heyoka
- Slipstream
These should be clearly marked as advanced/experimental functionality rather than standard DNS transport protocols.
- Background Service / Startup Support
Provide an optional background service so DNS protection and configuration remain active after:
- System startup
- User login
- Network reconnection
- VPN connection changes
- Sleep/hibernation recovery
The application should allow users to enable or disable automatic startup.
- System Tray / Menu Bar Integration
Where supported by the operating system, provide a system tray/menu bar interface for quick access to:
- Current DNS profile
- Connect/Disconnect
- Enable/Disable DNS protection
- Switch DNS profile
- View current resolver
- Run DNS health check
- Open application settings
- Logging and Diagnostics
Provide an optional diagnostic/logging system.
Logs should help users troubleshoot:
- DNS connection failures
- Resolver timeouts
- Protocol errors
- Network changes
- Configuration failures
- Failover events
- DNS leaks
- Bootstrap failures
Provide configurable log levels and an option to export diagnostic information for bug reports.
Suggested Architecture
A modular cross-platform architecture could separate the application into the following layers:
Core DNS Engine
- DNS resolution
- Protocol implementations
- Resolver management
- Caching
- Failover
- Health checks
Transport Layer
- UDP
- TCP
- TLS
- HTTPS
- HTTP/2
- HTTP/3
- QUIC
- DTLS
DNS Privacy / Proxy Layer
- DNSCrypt
- PQDNSCrypt
- Anonymized DNSCrypt
- ODoH
- ODoQ
Resolver Discovery Layer
Security Layer
- DNSSEC
- EDNS
- ECS
- DNS Cookies
- QNAME Minimization
- Cache Poisoning Protection
Routing Layer
- Split DNS
- Split-Horizon DNS
- Per-Domain DNS
- Per-App DNS
- Per-Interface DNS
- Rule-Based Routing
Filtering Layer
- Ad Blocking
- Malware Blocking
- Custom Blocklists
- Allowlists
- Hosts-based Rules
- Fake-IP
Reliability Layer
- DNS Cache
- Failover
- Load Balancing
- Fallback
- Bootstrap DNS
- Health Checks
Platform Integration Layer
Platform-specific backends for:
- Linux
- Windows
- macOS
- Other supported platforms
Management Layer
- DNS Profiles
- Backup/Restore
- Automatic Rollback
- Network Change Detection
- DNS Leak Test
- DNS Benchmark
- Automatic Best DNS Selection
- Auto IP Update
- Captive Portal Detection
- Background Service
- System Tray/Menu Bar
- Logging and Diagnostics
Expected Result
The desired outcome is a complete, modular, secure, and reliable cross-platform DNS client/manager.
The application should be capable of:
- Configuring encrypted DNS system-wide.
- Supporting multiple DNS protocols and resolvers.
- Preventing DNS leaks.
- Detecting and recovering from DNS failures.
- Automatically adapting to network changes.
- Providing advanced DNS routing and filtering.
- Benchmarking and monitoring DNS performance.
- Safely modifying and restoring system DNS configuration.
- Supporting portable DNS profiles.
- Automatically updating DNS providers when the public IP changes.
- Maintaining DNS protection through network changes and system restarts.
- Providing consistent functionality across Linux, Windows, macOS, and other supported platforms.
Not every feature needs to be implemented immediately. The functionality can be introduced incrementally, with experimental technologies such as ODoQ, PQDNSCrypt, and DNS tunneling clearly marked as experimental.
A platform-independent core with dedicated native backends for each operating system would make the application easier to maintain and would allow new DNS protocols, providers, and operating systems to be added in the future without major changes to the core architecture.
Feature Request: Comprehensive Cross-Platform DNS Client and Management Support
Description
I would like to request expanding the application into a complete, modern, and cross-platform DNS client/manager.
The goal is to support modern DNS protocols, privacy technologies, DNS routing and filtering, resolver discovery, reliability features, diagnostics, and system-wide DNS management across supported platforms.
The implementation should use a platform-independent core with platform-specific networking and DNS configuration backends where necessary.
The features below can be implemented incrementally and do not need to be introduced all at once.
Support traditional DNS transports:
Support modern encrypted DNS protocols:
Support DNS resolver discovery mechanisms:
Note: DDR and DNR are not DNS transport protocols. They are resolver discovery mechanisms and should be implemented separately from the DNS transport layer.
Support advanced DNS security and privacy features:
Support flexible DNS routing:
Example:
Wi-Fi → Resolver A
Ethernet → Resolver B
VPN → VPN DNS
Domain X → Resolver C
Domain Y → Resolver D
Support configurable DNS filtering:
Support mechanisms for maintaining DNS availability:
The application should be able to detect when a resolver becomes unavailable and automatically switch to a configured backup resolver.
Add built-in DNS diagnostics and benchmarking.
The application should test actual DNS resolution performance rather than relying only on ICMP ping.
Possible metrics:
Example:
Cloudflare
Latency: 18 ms
Availability: 100%
DNSSEC: Supported
IPv4: ✓
IPv6: ✓
DoH3: ✓
Status: Healthy
A benchmark mode could compare multiple DNS providers and automatically rank them based on configurable criteria.
Add an optional Auto / Best DNS mode.
The application could automatically test configured DNS providers and select the best resolver based on:
Users should be able to configure the selection criteria and priorities.
Add DNS leak protection.
For encrypted DNS configurations, provide an option such as:
Block Plain DNS
When enabled:
Possible modes:
Also provide a built-in DNS Leak Test showing:
The application should provide proper system-wide DNS integration on all supported platforms.
Instead of assuming a specific DNS backend, the application should detect the operating system and use the appropriate native networking/DNS APIs or configuration mechanisms.
Linux
Support where applicable:
Windows
Support the native Windows networking/DNS configuration mechanisms, including:
macOS
Support native macOS networking/DNS configuration mechanisms, including:
The application should use platform-specific backends behind a common abstraction layer so that the core DNS engine remains cross-platform.
Detect network changes such as:
After a network change, the application should verify that the selected DNS configuration is still active and re-apply it if necessary.
Because the application modifies system DNS settings, it should provide safe recovery mechanisms.
Features:
Suggested behavior:
Apply DNS configuration
↓
Validate DNS connectivity
↓
Successful?
↙ ↘
Yes No
↓ ↓
Keep Rollback
The application should never leave the system without a working DNS configuration because of a failed update.
Allow users to create and switch between DNS profiles.
Example:
Privacy
→ Quad9 DoT + DNSSEC
Ad Blocking
→ AdGuard DoH3
Gaming
→ Fastest available resolver
Default
→ System DNS
A profile could contain:
Profiles should be portable across supported platforms where possible.
Provide an optional local DNS proxy/listener for transparent system-wide encrypted DNS.
Example architecture:
Applications
↓
Local DNS Listener
↓
DNS Client / Proxy
↓
DoH / DoH3 / DoQ / DoT / DNSCrypt / ODoH
↓
Remote DNS Resolver
This would allow applications that only support traditional DNS to use modern encrypted DNS protocols transparently.
The local listener should be configurable and should support IPv4 and IPv6 where applicable.
Full support for:
The application should also detect IPv6 DNS leaks when IPv6 is enabled.
Detect captive portals on networks such as:
The application should notify the user when captive portal authentication is required and handle the transition between captive-portal networking and the configured DNS appropriately.
Add an Auto IP Update feature for DNS providers that require the client's public IP address to be registered or updated.
When enabled and configured, the application should automatically detect changes to the device's public IP address and notify the selected DNS provider whenever the IP changes.
Suggested features:
This is useful for DNS providers that use public IP addresses for authentication, access control, custom DNS configurations, or dynamic DNS-style management.
Support configurable bootstrap resolvers for encrypted DNS protocols.
Features:
If technically feasible, consider supporting DNS tunneling technologies separately from normal DNS transports:
These should be clearly marked as advanced/experimental functionality rather than standard DNS transport protocols.
Provide an optional background service so DNS protection and configuration remain active after:
The application should allow users to enable or disable automatic startup.
Where supported by the operating system, provide a system tray/menu bar interface for quick access to:
Provide an optional diagnostic/logging system.
Logs should help users troubleshoot:
Provide configurable log levels and an option to export diagnostic information for bug reports.
Suggested Architecture
A modular cross-platform architecture could separate the application into the following layers:
Core DNS Engine
Transport Layer
DNS Privacy / Proxy Layer
Resolver Discovery Layer
Security Layer
Routing Layer
Filtering Layer
Reliability Layer
Platform Integration Layer
Platform-specific backends for:
Management Layer
Expected Result
The desired outcome is a complete, modular, secure, and reliable cross-platform DNS client/manager.
The application should be capable of:
Not every feature needs to be implemented immediately. The functionality can be introduced incrementally, with experimental technologies such as ODoQ, PQDNSCrypt, and DNS tunneling clearly marked as experimental.
A platform-independent core with dedicated native backends for each operating system would make the application easier to maintain and would allow new DNS protocols, providers, and operating systems to be added in the future without major changes to the core architecture.