dns-switch
Production-ready DNS management with security and portability. A self-contained, portable DNS management tool with comprehensive security, health checking, and remote discovery capabilities.
Version: 9.0.1 | Size: 6.0MB | Author: Warith Al Maawali
License: Proprietary | Website: https://digi77.com
File Information
| Property | Value |
|---|---|
| Binary Name | dns-switch |
| Version | 9.0.1 |
| Build Date | 2026-03-23T08:26:07.341948128Z |
| Rust Version | |
| File Size | 6.0MB |
| JSON Data | View Raw JSON |
SHA256 Checksum
Features
| Feature | Description |
|---|---|
| Feature | Embedded DNS server lists (no external config dependencies) |
| Feature | Dynamic path detection (works in any directory) |
| Feature | Comprehensive input validation and sanitization |
| Feature | JSON output support for automation |
| Feature | Health monitoring and performance testing |
| Feature | Remote DNS server discovery and testing |
| Feature | Security-focused design with privilege checking |
| Feature | DNSCrypt proxy integration |
| Feature | Pi-hole DNS filter integration |
| Feature | Automatic backup and restore capabilities |
Security Features
| Feature | Description |
|---|---|
| Authentication | Integrated with Kodachi authentication system |
| Encryption | Supports DNSCrypt for encrypted DNS queries |
| Inputvalidation | All inputs sanitized and validated before use |
| Ratelimiting | Built-in rate limiting for remote operations |
System Requirements
| Requirement | Value |
|---|---|
| OS | Linux (Debian-based) |
| Privileges | root/sudo for system changes |
| Dependencies | systemd-resolved or resolvconf, DNSCrypt proxy (optional), Pi-hole (optional) |
Global Options
| Flag | Description |
|---|---|
-h, --help |
Print help information |
-v, --version |
Print version information |
-n, --info |
Display detailed information |
-e, --examples |
Show usage examples |
--json |
Output in JSON format |
-o, --output-format <FORMAT> |
Force output format (text |
--verbose |
Enable verbose output |
--quiet |
Suppress non-essential output |
--no-color |
Disable colored output |
--timeout <SECS> |
Set timeout (default: 30) |
--retry <COUNT> |
Retry attempts (default: 3) |
--config <FILE> |
Use custom configuration file |
--json-human |
Enhanced JSON output (best of both worlds) |
--json-pretty |
Pretty-print JSON output |
--json-human |
Enhanced JSON output with improved formatting (like jq) |
--fields <FIELDS> |
Select specific fields to include |
--limit <NUMBER> |
Limit number of results |
--offset <NUMBER> |
Skip first N results |
--work-dir <DIR> |
Specify working directory |
--no-action |
Dry run mode |
--log-level <LEVEL> |
Set logging verbosity (error |
Commands
DNS Management
switch
Switch DNS to a specific category or provider
Usage:
Options:
- --category <CATEGORY>: DNS category (reputable|normal|encrypted|fallback|all)
- --provider <NAME>: Specific DNS provider name
- --names <NAMES>: Switch DNS by server names (e.g., cloudflare, adguard)
- --servers <IPS>: Switch DNS by server IP addresses
Examples:
random
Switch to random DNS servers with advanced selection
Usage:
Options:
- --type <TYPE>: Type of DNS servers (reputable|normal|encrypted|fallback|all|remotely_fetched)
- --count <COUNT>: Number of random DNS servers to select
Examples:
fallback
Switch to fallback DNS servers
Usage:
Examples:
status
Show current DNS configuration
Usage:
Examples:
DNS Mode Management
get-mode
Show current DNS management mode (modern vs legacy)
Usage:
Examples:
set-mode
Set DNS management mode (modern=systemd-resolved, legacy=/etc/resolv.conf)
Usage:
Options:
- --mode <MODE>: DNS mode: 'modern' (systemd-resolved) or 'legacy' (/etc/resolv.conf)
Examples:
detect-mode
Auto-detect recommended DNS mode for this system
Usage:
Examples:
fix-dns
Repair broken DNS configuration (mode mismatches, broken symlinks, etc.)
Usage:
Options:
- --force: Run all repair stages even if DNS appears healthy
Examples:
Health & Discovery
health
Check health of DNS servers with detailed analysis (read-only by default)
Usage:
Options:
- --type <TYPE>: Test specific type (reputable|normal|encrypted|fallback|all)
- --full: Perform comprehensive health check
- --fresh: Force fresh health check, bypassing cache
- --save: Save health check results to database (default: read-only, no database changes)
- --force-move: BYPASS 3-strike rule: move failed servers to 'failed' category IMMEDIATELY (requires --save). Use for urgent cleanup or known-bad servers
Examples:
fetch
Fetch and test remote DNS servers with advanced options
Usage:
Options:
- --save: Save results to database
- --all: Fetch all available DNS servers (instead of default 25)
- --count <NUM>: Specify number of DNS servers to fetch
- --fresh: Force fresh data retrieval, bypassing all caches
- --history: Show fetch history
- --load <CACHE_ID>: Load cached results
Examples:
fetch-count
Fetch a specific number of DNS servers from remote sources
Usage:
Options:
- --count <NUM>: Number of DNS servers to fetch
- --fresh: Force fresh data retrieval, bypassing caches
Examples:
DNSCrypt Management
dnscrypt
Show DNSCrypt status
Usage:
Examples:
dnscrypt-set
Enable DNSCrypt with specific resolver
Usage:
Options:
- --resolver <NAME>: DNSCrypt resolver name
Examples:
dnscrypt-restart
Restart DNSCrypt proxy
Usage:
Examples:
dnscrypt-remove
Remove DNSCrypt configuration
Usage:
Examples:
Pi-hole Integration
pihole
Show Pi-hole status
Usage:
Examples:
pihole-enable
Enable Pi-hole DNS filtering
Usage:
Examples:
pihole-disable
Disable Pi-hole DNS filtering
Usage:
Examples:
pihole-password
Set Pi-hole web interface password (auto-handles file protection)
Usage:
Options:
- --password <PASSWORD>: New password for Pi-hole web interface (TOML file auto-unprotected)
Examples:
pihole-reset
Reset Pi-hole configuration
Usage:
Examples:
Information & Utilities
list
List available DNS servers
Usage:
Options:
- --category <CATEGORY>: Category to list (reputable|normal|encrypted|fallback|remotely_fetched|all)
Examples:
count
Count DNS servers by category
Usage:
Examples:
Maintenance & Recovery
clean
Clean temporary files and cache
Usage:
Examples:
clean-duplicates
Clean duplicate DNS entries from database
Usage:
Examples:
flush-cache
Flush systemd-resolved and nscd DNS caches to clear stale entries
Usage:
Examples:
backup
Create DNS configuration backup
Usage:
Examples:
restore-default
Restore default DNS configuration
Usage:
Examples:
restore-backup
Restore from backup
Usage:
Options:
- --file <FILE>: Backup file to restore
Examples:
Operational Scenarios
Scenario-oriented workflows generated from the binary's built-in -e --json examples.
Scenario 1: DNS Status & Information
Check current DNS configuration and available servers
Step 1: Display current system DNS servers with detailed information
Expected Output: Shows active DNS servers, their IPs, and configuration sourceStep 2: Get DNS status in machine-readable JSON format
Expected Output: JSON with DNS servers, timestamps, and configuration metadataNote
Useful for scripting and automation
Step 3: Count available DNS servers by category (reputable, normal, encrypted, etc.)
Expected Output: Summary showing total servers in each categoryStep 4: List all reputable DNS servers with details
Expected Output: Table of reputable DNS providers with names, IPs, and locationsScenario 2: Basic DNS Switching
Switch DNS servers using different selection methods
Step 1: Switch to first available reputable DNS servers from the database
Expected Output: System DNS changed to trusted providers like Cloudflare, Quad9, or AdGuardStep 2: Switch to specific DNS providers by name
Expected Output: DNS set to Cloudflare (1.1.1.1) and AdGuard (94.140.14.14)Step 3: Switch to specific DNS servers by IP address
Expected Output: DNS set to specified IP addresses directlyNote
Useful when you know exact server IPs
Step 4: Switch to hardcoded fallback DNS servers for emergencies
Expected Output: DNS set to fallback servers from embedded recovery pool (e.g. 9.9.9.9, 1.1.1.1, 94.140.14.14)Note
Use when database is corrupted or unavailable
Scenario 3: Random DNS Selection
Randomly select DNS servers from different categories
Step 1: Select 3 random DNS servers from reputable category (default behavior)
Expected Output: DNS set to 3 randomly selected reputable serversStep 2: Select 3 random reputable DNS servers and verify they work before applying
Expected Output: DNS changed to verified working servers onlyNote
Only applies servers that pass health check
Step 3: Select 3 random reputable DNS servers and verify each works before applying
Expected Output: DNS changed to verified working reputable serversNote
Health checks each selected server; only uses working ones
Step 4: Select 5 random servers from normal category
Expected Output: DNS set to 5 randomly selected normal serversStep 5: Select 6 random normal DNS servers and verify they work before applying
Expected Output: DNS changed to up to 6 verified working serversNote
If some servers fail health check, only working ones are used
Step 6: Select 6 servers: 3 from reputable + 3 from normal categories
Expected Output: DNS set to 6 servers evenly distributed between categoriesNote
Count is distributed evenly across specified types
Step 7: Select 7 servers distributed: 4 reputable + 3 normal
Expected Output: DNS changed to 7 random serversNote
Uneven distribution favors first type
Step 8: Select 3 servers each from reputable, normal, and remotely_fetched (9 total)
Expected Output: DNS set to 9 servers: 3 from each major categoryNote
'all' excludes encrypted and fallback categories
Step 9: Select 6 servers distributed: 3 reputable + 3 normal (alternate syntax)
Expected Output: 6 servers evenly distributed between categoriesNote
--count-random is an alias for --count
Step 10: Select 6 servers distributed: 2 from each category
Expected Output: 6 servers evenly distributed across 3 categoriesStep 11: Select 10 servers distributed: 4+3+3 from each category
Expected Output: 10 servers with weighted distributionScenario 4: DNS Health Checking
Test DNS servers for availability and performance. Health checks are read-only by default — use --save to persist results to database. IMPORTANT: Failed servers are moved to 'failed' category only after 3 CONSECUTIVE failures (3-strike rule) to prevent false positives from temporary network issues. Run health checks 3 times to trigger category changes.
Step 1: Test reputable DNS servers (default) for availability and response times (read-only)
Expected Output: Health status for reputable servers with response timesNote
Read-only: does not modify the database
Step 2: Test reputable DNS servers only (read-only)
Expected Output: Health status for reputable serversNote
Tests curated high-quality DNS providers. Read-only: does not modify database
Step 3: Test reputable servers and save results to database
Expected Output: Health status saved to dns-database.jsonNote
--save updates: status, response times, geolocation, consecutive_failures counter. Servers move to 'failed' category ONLY after 3 consecutive failures (run 3 times)
Step 4: Test normal DNS servers only (read-only)
Expected Output: Health status for normal serversNote
Tests standard reliable DNS providers. Read-only mode
Step 5: Test encrypted DNS servers (DNSCrypt, DoH, DoT) only
Expected Output: Health status for encrypted serversNote
Tests DNSCrypt and secure DNS providers. Read-only mode
Step 6: Check health of remotely fetched DNS servers (read-only)
Expected Output: Health status for remotely fetched serversNote
Tests servers previously discovered via 'fetch' command
Step 7: Test remotely fetched servers and save results to database
Expected Output: Health status for remotely fetched servers saved to databaseNote
3-STRIKE RULE: Servers move to 'failed' category only after 3 consecutive failures. Run this command 3 times to trigger category moves
Step 8: Test ALL working server categories (excludes failed servers)
Expected Output: Complete report of all working DNS servers across all categoriesNote
Tests: fallback + reputable + normal + encrypted + remotely_fetched. Excludes failed servers for efficiency. May take several minutes
Step 9: Test all working categories and save results to database
Expected Output: Complete health report saved to databaseNote
Updates: status, response times, geolocation, consecutive_failures counter. 3-STRIKE RULE: Run 3 times to move failed servers to 'failed' category (prevents false positives)
Step 10: Run health check 3 times to trigger 3-strike rule and move failed servers
dns-switch health --type all --save && dns-switch health --type all --save && dns-switch health --type all --save
Note
WORKFLOW EXAMPLE: The 3-strike rule requires 3 consecutive failures before moving servers. Run 'count' after 3rd run to see category changes
Step 11: Test ONLY failed servers and update their status if recovered
Expected Output: Failed servers health check completed - recovered servers moved IMMEDIATELY back to original categories (no 3-strike rule for recovery)Note
Recovery is instant (1 success = move back). Tests servers from dns-database-failed.json. --save required to persist recovery
Step 12: BYPASS 3-strike rule: move failed servers to 'failed' category IMMEDIATELY
Expected Output: Failed servers moved to 'failed' category on FIRST failure (no waiting for 3 strikes). Check with 'count' commandNote
⚠️ CAUTION: Bypasses protection against transient network issues. Use for urgent cleanup or when you're CERTAIN servers are permanently down. --save required
Step 13: Test remotely fetched servers and force-move failures immediately
Expected Output: Remotely fetched servers tested - failures moved to 'failed' category instantlyNote
Useful for quickly cleaning up newly discovered servers that are non-responsive. Skips 3-strike protection
Step 14: Full health check with geolocation, save results
Expected Output: Comprehensive health data saved to databaseNote
Full check includes geolocation lookup for all working servers
Step 15: Health check with JSON output (read-only)
Expected Output: JSON formatted health dataNote
Default tests reputable servers. Use --type to specify category
Step 16: Test encrypted DNS servers with JSON output for parsing
Expected Output: JSON object with detailed health metrics per serverNote
Structured JSON output for automation and integration
Step 17: Fresh health check, save results, JSON output
Expected Output: Real-time health check saved to database in JSONNote
Bypasses cache for current data, persists to database
Scenario 5: JSON Output
Automation-friendly JSON responses
Step 1: Get status in JSON format
Expected Output: JSON object with current DNS configurationStep 2: Pretty-printed DNS server counts
Expected Output: Formatted JSON with server statisticsStep 3: Human-readable JSON with enhanced formatting
Expected Output: JSON object with improved readability and structureScenario 6: DNS Switching by Names
Switch DNS servers using provider names
Step 1: Switch to Cloudflare DNS (1.1.1.1)
Expected Output: DNS changed to Cloudflare serversStep 2: Switch to Cloudflare DNS after verifying it's working
Expected Output: DNS changed to Cloudflare servers (verified working)Note
Health check performed before applying DNS change
Step 3: Switch to Cloudflare and Quad9 DNS servers (space-separated)
Expected Output: DNS changed to multiple providersNote
Multiple names separated by spaces
Step 4: Switch to multiple DNS providers (comma-separated)
Expected Output: DNS changed to Cloudflare, Quad9, and AdGuard serversNote
Alternative syntax using commas to separate names
Step 5: Switch to multiple DNS providers after verifying each works
Expected Output: DNS changed to only verified working serversNote
Only working servers will be applied to resolv.conf
Step 6: Switch to AdGuard DNS (94.140.14.14, 94.140.15.15) - Privacy-respecting
Expected Output: DNS changed to AdGuard serversNote
Blocks ads and trackers
Step 7: Switch to OpenDNS (208.67.222.222, 208.67.220.220)
Expected Output: DNS changed to OpenDNS serversStep 8: Switch to NextDNS (45.90.28.167, 45.90.30.167)
Expected Output: DNS changed to NextDNS serversStep 9: Switch to CleanBrowsing DNS (185.228.168.9, 185.228.169.9)
Expected Output: DNS changed to CleanBrowsing serversNote
Family-friendly content filtering
Scenario 7: DNS Switching by IP
Switch DNS servers using IP addresses
Step 1: Switch to specific DNS server IP
Expected Output: DNS changed to specified IPStep 2: Switch to specific DNS server IP after verifying it works
Expected Output: DNS changed to specified IP (verified working)Note
Health check ensures DNS server is responsive before applying
Step 3: Switch to multiple specific DNS server IPs
Expected Output: DNS changed to multiple IPsStep 4: Switch to multiple DNS IPs after verifying each works
Expected Output: DNS changed to only verified working IPsNote
Failed servers are excluded from final configuration
Step 5: Switch to AdGuard DNS by IP
Expected Output: DNS changed to AdGuard IPsScenario 8: Remote DNS Discovery & Fetching
Discover and fetch new DNS servers from remote sources
Step 1: Fetch 25 DNS servers from remote sources, test them, and save to database
Expected Output: Lists fetched servers with country, response time, and success/failure statusNote
Default fetches 25 servers
Step 2: Fetch exactly 50 DNS servers from remote sources
Expected Output: Shows all 50 servers with test results and performance metricsNote
Shows all results when count < 100
Step 3: Fetch exactly 100 DNS servers from remote sources
Expected Output: 100 DNS servers fetched and testedNote
May take longer to complete
Step 4: Alternative syntax to fetch 35 servers (same as fetch --count 35)
Expected Output: Lists all 35 fetched servers with detailed informationNote
fetch-count is an alias for fetch with --count
Step 5: Fetch ALL available DNS servers from remote sources
Expected Output: Fetches hundreds of servers, shows truncated list with summaryNote
Note: Use kitty terminal to see country flags. Total servers > 60,000 so this will take very long to test all servers
Step 6: Force fresh fetch bypassing ALL caches (API cache, result cache, etc.)
Expected Output: Real-time fetch with no cached data usedNote
--fresh ensures completely new data from remote sources
Step 7: Fetch 25 servers with JSON output
Expected Output: JSON response with fetched server detailsStep 8: Fresh fetch 35 servers with JSON output
Expected Output: JSON response with fresh server dataStep 9: Fetch all servers with JSON output for processing
Expected Output: Complete JSON dataset of all serversStep 10: Fetch remote DNSCrypt servers from authentication card
Expected Output: Adds DNSCrypt servers from VPS to encrypted categoryNote
Requires valid authentication with online-auth
Scenario 9: DNSCrypt & Pi-hole Integration
Encrypted DNS and ad-blocking integration
Step 1: Switch DNS to use local DNSCrypt (127.0.0.1)
Expected Output: DNS set to use DNSCrypt proxy, service started if neededNote
Automatically starts dnscrypt-proxy service if not running. Aliases: dnscrypt | dnscrypt-server | dnscryptproxy | encrypted
Step 2: Check DNSCrypt proxy service status
Expected Output: Shows if DNSCrypt is running, configured resolver, and portStep 3: Configure DNSCrypt to use Cloudflare's encrypted resolver
Expected Output: DNSCrypt configured and started with Cloudflare resolverNote
Requires dnscrypt-proxy package installed
Step 4: Restart DNSCrypt proxy service
Expected Output: DNSCrypt proxy service restarted successfullyStep 5: Stop DNSCrypt and switch to reputable DNS servers
Expected Output: DNSCrypt stopped and DNS switched to regular serversNote
Automatically switches to reputable DNS to avoid DNS being offline
Step 6: Switch to remote DNSCrypt IPv4 server from authentication card
Expected Output: DNS switched to remote DNSCrypt IPv4 server from VPSNote
Requires running 'fetch-dns-from-card' first to add remote servers
Step 7: Switch to remote DNSCrypt IPv6 server from authentication card
Expected Output: DNS switched to remote DNSCrypt IPv6 server from VPSNote
Requires running 'fetch-dns-from-card' first to add remote servers
Step 8: Switch to both remote DNSCrypt servers (comma-separated)
Expected Output: DNS switched to use both remote DNSCrypt servers for dual-stack supportNote
Comma-separated format - both IPv4 and IPv6 from your VPS
Step 9: Switch to both remote DNSCrypt servers (space-separated)
Expected Output: DNS switched to use both remote DNSCrypt servers for dual-stack supportNote
Space-separated format - alternative syntax for multiple servers
Step 10: Check Pi-hole service status with systemctl info
Expected Output: Shows if Pi-hole is running, blocking status, and systemctl_statusNote
Use 'systemctl status pihole-FTL.service' to verify service state directly
Step 11: Enable Pi-hole ad blocking DNS with automatic DNSCrypt integration
Expected Output: DNS redirected through Pi-hole for ad/tracker blocking → Pi-hole automatically uses DNSCrypt (127.0.0.1#5353) as upstream → You get encrypted DNS + ad blocking = maximum protection → Secure yet transparent - see what's blocked in Pi-hole web interfaceNote
Pi-hole must be installed. DNSCrypt integration is automatic - no manual config needed!
Step 12: Disable Pi-hole DNS filtering and stop the service
Expected Output: Pi-hole service stopped and disabled from bootNote
DNSCrypt continues independently if running. Use 'sudo dns-switch pihole-enable' to re-enable.
Step 13: Set Pi-hole web interface password (automatically unprotects TOML file)
Expected Output: Pi-hole admin password updated. Protection restored on service restart.Note
Note: To manually change password, run 'sudo chattr -i /etc/pihole/pihole.toml' first
Scenario 10: Database Maintenance
Manage DNS database, backups, and cleanup
Step 1: Remove duplicate DNS entries and clean temporary files from database
Expected Output: Reports which temporary files were cleaned and how many duplicates removedStep 2: Alternative command to remove duplicate entries
Expected Output: Same as 'clean' - removes duplicate DNS entriesStep 3: Create timestamped backup of current DNS database (not system DNS config)
Expected Output: Creates backup file of DNS database with timestampNote
Backs up dns-switch database only, not /etc/resolv.conf
Step 4: Create user backup with JSON output
Expected Output: JSON confirmation of backup operationStep 5: Reset DNS database to factory defaults and update system DNS
Expected Output: Database restored to original state and system DNS updatedNote
Removes all custom configurations and applies default DNS
Step 6: Preview restore to defaults without applying changes
Expected Output: Shows what would be restoredStep 7: Restore DNS database from most recent backup (database only)
Expected Output: Database restored from latest backup fileNote
Restores database backup, run 'switch' to apply to system
Step 8: Preview restore from backup in JSON format
Expected Output: JSON preview of restore operationScenario 11: Dry Run & JSON Output
Test commands safely and get machine-readable output
Step 1: Preview what would happen without making changes
Expected Output: Shows DNS servers that would be set without actually changing themNote
Use --no-action to test any command safely
Step 2: Preview random DNS selection without applying
Expected Output: Shows 5 servers that would be selectedStep 3: Preview fallback server switch without applying
Expected Output: Shows fallback servers that would be usedStep 4: Preview database cleanup without applying changes
Expected Output: Shows duplicates that would be removedStep 5: Check what DNSCrypt operations would be performed
Expected Output: Shows DNSCrypt configuration changesStep 6: Get current DNS status in pretty-printed JSON
Expected Output: Formatted JSON with indentation for readabilityStep 7: Get health check results in enhanced JSON format
Expected Output: JSON with human-readable formatting and metadataNote
--json-human provides best of both worlds
Step 8: Get DNS server count statistics in enhanced JSON format
Expected Output: JSON with human-readable formatting and metadataNote
--json-human provides best of both worlds
Scenario 12: DNS Mode Management (Modern vs Legacy)
Manage DNS configuration modes: modern (systemd-resolved) vs legacy (/etc/resolv.conf)
Step 1: Check current DNS management mode
Expected Output: Shows: modern (systemd-resolved) or legacy (/etc/resolv.conf)Note
Displays mode health status and any configuration issues
Step 2: Get DNS mode in JSON format
Expected Output: JSON with mode, systemd-resolved status, and health checksNote
Includes resolv.conf symlink status and detected issues
Step 3: Auto-detect recommended DNS mode for this system
Expected Output: Recommends modern if systemd-resolved active, legacy otherwiseNote
Checks systemd-resolved installation and activity status
Step 4: Get mode detection results in JSON
Expected Output: JSON with detected mode, current mode, and recommendationStep 5: Switch to modern mode (systemd-resolved)
Expected Output: Enables systemd-resolved and configures /etc/resolv.conf as symlinkNote
Backs up existing resolv.conf, starts systemd-resolved if needed
Step 6: Switch to legacy mode (/etc/resolv.conf)
Expected Output: Converts /etc/resolv.conf to regular file, preserves current DNSNote
Extracts current DNS from systemd-resolved before switching
Step 7: Auto-repair broken DNS configuration
Expected Output: Fixes mode mismatches, broken symlinks, applies fallback DNSNote
Emergency repair command for connectivity issues
Step 8: Run complete DNS repair sequence regardless of initial health
Expected Output: Executes all repair stages, then validates DNS statusNote
Use after unstable DNS incidents or repeated resolver failures
Step 9: Check current systemd-resolved configuration method
Expected Output: Shows: global, per-interface, networkmanager, or autoNote
Only applies when in modern mode (systemd-resolved)
Step 10: Get systemd-resolved method in JSON
Expected Output: JSON with method and descriptionStep 11: Set to global config method (RECOMMENDED)
Expected Output: Configures /etc/systemd/resolved.conf - covers ALL interfacesNote
Safest method - prevents DNS leaks on all network interfaces
Step 12: Set to per-interface method
Expected Output: Uses resolvectl dnsNote
May miss virtual/VPN interfaces - use global method instead
Step 13: Set to NetworkManager method
Expected Output: Uses nmcli for DNS configurationNote
Only for NetworkManager-managed systems
Step 14: Set to auto with smart fallback chain
Expected Output: Tries global → per-interface → networkmanager automaticallyNote
Automatically selects best available method
Step 15: Check for DNS leaks across all network interfaces
Expected Output: Reports any interfaces with unexpected DNS serversNote
Essential for privacy - detects DNS configuration bypasses
Step 16: Get DNS leak detection results in JSON
Expected Output: JSON with leaked interfaces list and expected DNS serversNote
Use after switching DNS to verify no leaks occurred
Scenario 13: Boot-Time DNS Check Management
Manage automatic DNS checking and fixing on system boot
Step 1: Manually check and fix DNS configuration (same as boot-time check)
Expected Output: Reports DNS status and fixes empty/invalid nameservers if neededNote
Uses configuration-based fallback servers, never hardcoded values
Step 2: Enable automatic DNS checking on system boot
Expected Output: Creates and enables systemd service for boot-time DNS validationNote
Ensures DNS is always configured correctly after system restart
Step 3: Disable automatic DNS checking on system boot
Expected Output: Removes systemd service for boot-time DNS validationNote
DNS configuration will not be automatically checked on boot
Step 4: Check status of the boot-check systemd service
Expected Output: Shows if boot-check service is enabled and its last run statusNote
Useful for verifying boot-check is working correctly
Environment Variables
| Variable | Description | Default | Values |
|---|---|---|---|
RUST_LOG |
Set logging level | info | error |
NO_COLOR |
Disable all colored output when set | unset | 1 |
DNS_SWITCH_CONFIG |
Path to configuration file | ~/.config/dns-switch/config.json | /path/to/config.json |
Exit Codes
| Code | Description |
|---|---|
| 0 | Success |
| 1 | General error |
| 2 | Invalid arguments |
| 3 | Permission denied |
| 4 | Network error |
| 5 | File not found |
| 6 | Operation timeout |
| 7 | Authentication error |