Intermittent Connectivity Issues: Is It DNS?

Step 1: Quick DNS Test (60 Seconds)

Before doing anything else, run this quick test to determine if DNS filtering is involved. Open a terminal or command prompt and run:

# Windows Command Prompt
nslookup the-failing-site.com 185.228.168.168
nslookup the-failing-site.com 8.8.8.8

# PowerShell
Resolve-DnsName -Name the-failing-site.com -Server 185.228.168.168
Resolve-DnsName -Name the-failing-site.com -Server 8.8.8.8

# macOS / Linux
dig +short @185.228.168.168 the-failing-site.com
dig +short @8.8.8.8 the-failing-site.com

Replace the-failing-site.com with the domain that is not working.

Compare the results:

Step 2: Confirm Which DNS Resolver You Are Using

Before troubleshooting further, verify that your device is actually using CleanBrowsing. A common cause of confusion is that the device is not using the DNS server you think it is.

# Windows — show configured DNS servers
ipconfig /all | findstr "DNS Servers"

# PowerShell — more detail
Get-DnsClientServerAddress -AddressFamily IPv4

# macOS
scutil --dns | grep "nameserver"

# Linux (systemd)
resolvectl status | grep "DNS Servers"

# Linux (older)
cat /etc/resolv.conf

You should see CleanBrowsing IPs (185.228.168.168 or 185.228.169.168 for Family Filter). If you see different IPs, your device is not using CleanBrowsing — the issue is not related to our filtering.

Verify with the Debug Record

CleanBrowsing provides a TXT record you can query to confirm your traffic is reaching our servers:

# Windows
nslookup -type=TXT debug.test.cleanbrowsing.org

# PowerShell
Resolve-DnsName -Name debug.test.cleanbrowsing.org -Type TXT

# macOS / Linux
dig TXT debug.test.cleanbrowsing.org

If this returns CleanBrowsing account information, your DNS queries are reaching us. If it returns nothing or a different provider's response, something between your device and CleanBrowsing is intercepting DNS (your ISP, router, or a local service).

Step 3: Compare Resolver Behavior

Test the failing domain against multiple DNS resolvers to isolate the problem. This script tests a domain against CleanBrowsing, Google, Cloudflare, and Quad9 simultaneously:

# PowerShell — multi-resolver comparison
$domain = "the-failing-site.com"
$resolvers = @(
    @{Name="CleanBrowsing"; IP="185.228.168.168"},
    @{Name="Google DNS"; IP="8.8.8.8"},
    @{Name="Cloudflare"; IP="1.1.1.1"},
    @{Name="Quad9"; IP="9.9.9.9"}
)

foreach ($r in $resolvers) {
    $start = Get-Date
    $result = Resolve-DnsName -Name $domain -Server $r.IP -ErrorAction SilentlyContinue
    $elapsed = ((Get-Date) - $start).TotalMilliseconds
    if ($result.IPAddress) {
        Write-Host ("[OK]    {0,-15} {1,-20} {2:N0}ms" -f $r.Name, ($result.IPAddress[0]), $elapsed) -ForegroundColor Green
    } else {
        Write-Host ("[FAIL]  {0,-15} {1,-20} {2:N0}ms" -f $r.Name, "No response", $elapsed) -ForegroundColor Red
    }
}

# macOS / Linux
domain="the-failing-site.com"
for resolver in "185.228.168.168 CleanBrowsing" "8.8.8.8 Google" "1.1.1.1 Cloudflare" "9.9.9.9 Quad9"; do
    set -- $resolver
    ip=$1; name=$2
    result=$(dig +short +time=3 @$ip $domain 2>/dev/null)
    if [ -n "$result" ]; then
        echo "[OK]    $name ($ip): $result"
    else
        echo "[FAIL]  $name ($ip): No response"
    fi
done

Interpreting the results:

• Only CleanBrowsing fails: The domain is likely being filtered. Check your dashboard for the block reason.
• CleanBrowsing and Quad9 fail, others succeed: The domain may be flagged as malicious by security-focused resolvers. This is a legitimate security block.
• All resolvers fail: The domain itself is down, or your network has a broader connectivity issue.
• All resolvers succeed but the site still doesn't load: DNS is working — the issue is at the network, firewall, or application layer, not DNS.

Step 4: Check for Blocked Domains in the Dashboard

If Step 1-3 confirm that CleanBrowsing is blocking one or more domains, log into the dashboard to understand why.

1. Go to your CleanBrowsing dashboard.
2. Navigate to Activity > Blocked Requests.
3. Filter by the time range when issues occurred.
4. Look for the domain(s) that your CLI tests identified as blocked.
5. Note the category that triggered the block — this tells you which filter rule is responsible.

Common Reasons Legitimate Domains Get Blocked

• New/uncategorized domain: A domain that was recently added to a service's infrastructure may not yet be categorized. Depending on your filter settings, uncategorized domains may be blocked by default.
• CDN/shared hosting miscategorization: CDN domains serve content for many websites. If any content on the CDN is flagged, the domain may be categorized incorrectly.
• VPN/Proxy category overlap: Some enterprise services use infrastructure that overlaps with VPN or proxy networks. If you have the VPN/Proxy filter enabled, this can catch legitimate services.
• Mixed content domains: Domains that serve both clean and adult content may be categorized as mixed content.

Once you identify the blocked domain, add it to your allowlist. If the categorization is incorrect, report it to support@cleanbrowsing.org so we can update it for everyone.

Step 5: Rule Out Non-DNS Causes

Not all connectivity problems are DNS-related. If DNS resolution looks correct (the domain resolves to a valid IP through CleanBrowsing), the issue may be elsewhere. Here is how to check:

Test Network Connectivity (Beyond DNS)

# Windows — ping the resolved IP directly
ping outlook.office365.com

# PowerShell — test TCP connectivity to the service
Test-NetConnection -ComputerName outlook.office365.com -Port 443 -InformationLevel Detailed

# macOS / Linux
ping -c 4 outlook.office365.com
curl -o /dev/null -s -w "HTTP Status: %{http_code}\nTime: %{time_total}s\n" https://outlook.office365.com

Check for ISP or Routing Issues

# Windows
tracert 185.228.168.168
tracert outlook.office365.com

# macOS / Linux
traceroute 185.228.168.168
traceroute outlook.office365.com

# Look for:
# - Hops with * * * (timeouts) — indicates a network node dropping packets
# - Sudden high latency jumps — indicates congestion
# - The trace stopping before reaching the destination — indicates a routing block

Check for Local DNS Cache Issues

Stale DNS cache entries are a common cause of intermittent issues. A cached response from before a domain was allowlisted (or before a DNS change propagated) will persist until the cache expires.

# Windows — view current DNS cache
ipconfig /displaydns | findstr "Record Name"

# PowerShell — view and search cache
Get-DnsClientCache | Where-Object { $_.Entry -like "*microsoft*" }

# Flush the cache
ipconfig /flushdns          # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
sudo systemd-resolve --flush-caches   # Linux (systemd)

Check for Conflicting Services

Some software overrides DNS settings or intercepts DNS queries. Common culprits include:

• Antivirus/security software (Avast, Norton, McAfee) — may redirect DNS through their own servers
• Browser DNS-over-HTTPS — Chrome, Firefox, and Edge can bypass your system DNS entirely
• VPN clients — even when not connected, some VPN apps modify DNS settings
• ISP equipment — some ISP-provided routers intercept and redirect DNS queries

See our full guide on services that conflict with DNS filtering for identification and resolution steps.

Step 6: Measure DNS Latency

If DNS is resolving correctly but feels slow, measure the actual response time. Normal DNS resolution should complete in under 50ms. Anything over 200ms will cause noticeable delays.

# PowerShell — measure DNS response time
$domain = "outlook.office365.com"
$iterations = 10

Write-Host "Testing DNS latency for $domain ($iterations queries)..."
$times = @()
for ($i = 1; $i -le $iterations; $i++) {
    Clear-DnsClientCache
    $start = Get-Date
    Resolve-DnsName -Name $domain -Server 185.228.168.168 -ErrorAction SilentlyContinue | Out-Null
    $elapsed = ((Get-Date) - $start).TotalMilliseconds
    $times += $elapsed
    Write-Host "  Query $i : $([math]::Round($elapsed))ms"
}

Write-Host "`nAverage: $([math]::Round(($times | Measure-Object -Average).Average))ms"
Write-Host "Min:     $([math]::Round(($times | Measure-Object -Minimum).Minimum))ms"
Write-Host "Max:     $([math]::Round(($times | Measure-Object -Maximum).Maximum))ms"

# macOS / Linux — measure with dig
domain="outlook.office365.com"
echo "Testing DNS latency for $domain..."
for i in $(seq 1 10); do
    time=$(dig @185.228.168.168 $domain +stats 2>/dev/null | grep "Query time" | awk '{print $4}')
    echo "  Query $i: ${time}ms"
done

Interpreting latency results:

• Under 30ms: Excellent. DNS is not the bottleneck.
• 30-100ms: Normal. Typical for DNS resolvers depending on your geographic location relative to the nearest CleanBrowsing server.
• 100-300ms: Elevated. May be noticeable. Could indicate routing issues or distance from the nearest CleanBrowsing node.
• Over 300ms or highly variable: Something is wrong. Check for network congestion, ISP throttling of DNS traffic, or misconfigured firewall rules that add processing overhead.

Step 7: What to Include When Contacting Support

If you have worked through the steps above and cannot resolve the issue, contact us at support@cleanbrowsing.org. To help us diagnose quickly, please include:

Information Checklist

1. DNS Leak Test results — run our DNS Leak Test and share the results link (captures your public IP, resolver info, and device type in one step)
2. The affected domain(s) — specific domains, not just "Microsoft Teams isn't working"
3. Time range — when the issue started and whether it is ongoing or intermittent
4. DNS resolution output — output of nslookup or dig for the affected domain through CleanBrowsing (185.228.168.168)
5. Comparison output — same query through Google DNS (8.8.8.8) for comparison
6. CleanBrowsing debug record — output of nslookup -type=TXT debug.test.cleanbrowsing.org 185.228.168.168

One-Command Diagnostic Report

Run this to generate a diagnostic report you can paste into your support email:

# PowerShell — generate full diagnostic report
$domain = "the-failing-site.com"  # Change this

Write-Host "=== CleanBrowsing Diagnostic Report ==="
Write-Host "Date: $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
Write-Host "Domain: $domain"
Write-Host ""

Write-Host "--- Public IP ---"
(Invoke-WebRequest -Uri "https://ifconfig.me" -UseBasicParsing).Content
Write-Host ""

Write-Host "--- DNS Servers Configured ---"
Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize
Write-Host ""

Write-Host "--- Resolution via CleanBrowsing ---"
Resolve-DnsName -Name $domain -Server 185.228.168.168 -ErrorAction SilentlyContinue | Format-Table
Write-Host ""

Write-Host "--- Resolution via Google DNS ---"
Resolve-DnsName -Name $domain -Server 8.8.8.8 -ErrorAction SilentlyContinue | Format-Table
Write-Host ""

Write-Host "--- CleanBrowsing Debug ---"
Resolve-DnsName -Name debug.test.cleanbrowsing.org -Type TXT -Server 185.228.168.168 | Format-Table
Write-Host ""

Write-Host "--- Connectivity Test ---"
Test-NetConnection -ComputerName $domain -Port 443 -WarningAction SilentlyContinue | Format-List

# macOS / Linux — generate diagnostic report
domain="the-failing-site.com"  # Change this

echo "=== CleanBrowsing Diagnostic Report ==="
echo "Date: $(date)"
echo "Domain: $domain"
echo ""
echo "--- Public IP ---"
curl -s ifconfig.me
echo ""
echo ""
echo "--- DNS Servers Configured ---"
cat /etc/resolv.conf 2>/dev/null || scutil --dns | grep nameserver
echo ""
echo "--- Resolution via CleanBrowsing ---"
dig @185.228.168.168 $domain
echo ""
echo "--- Resolution via Google DNS ---"
dig @8.8.8.8 $domain
echo ""
echo "--- CleanBrowsing Debug ---"
dig TXT debug.test.cleanbrowsing.org @185.228.168.168
echo ""
echo "--- Traceroute ---"
traceroute -m 15 185.228.168.168

Copy the output and paste it into your email to support@cleanbrowsing.org. This gives us everything we need to diagnose the issue quickly.