Ett namn misslyckas medan tunneln är uppe, och webbläsaren kallar det ett nätverksfel, trots att den verkliga orsaken är det DNS-svar som resolvern returnerade. En filtrerande resolver kan hålla kvar, neka eller skriva om ett enda namn och låta alla andra uppslag fungera. Tunneln bär frågan; resolvern avgör svaret. Granska det svaret innan du rör krypteringsinställningarna.

Tunneln är uppe, så krypteringen är inte den misstänkta

Anslutningsstatusen säger om paket rör sig, inte om ett namn löses upp. Uppslagning är en fråga till den server klienten är konfigurerad med, och en policy där kan svara en domän annorlunda än alla andra. Från webbläsarens sida smälter alla dessa svar samman till ett allmänt fel, därför bevisar statuslampan så lite.

Skriv först ned tre saker: resolvern klienten använde, svarskoden för namnet som misslyckas och samma fråga för ett namn som borde fungera. Fråga resolvern direkt med dig example.com @10.20.0.1 och läs statusraden, inte webbläsarmeddelandet. Om kontrollnamnet löses upp och det som misslyckas returnerar ett policysvar är beviset komplett. Om båda misslyckas är filtret ännu inte inblandat.

Fyra svar, fyra olika ägare

En filtrerande resolver har inte bara ett sätt att säga nej, och formen på avvisningen pekar på ett annat nästa steg. Skriv ned svarskoden, eftersom webbläsaren skriver om alla fyra till något som låter som en bruten anslutning.

AnswerWhat it points at
NXDOMAINThe name is withheld: a policy entry or a zone decision removed it
RefusedThe resolver declines to answer; usually an access or policy rule
Replacement addressA redirect to a block page or sinkhole you can query and inspect
No answer at allWeakest evidence: reachability, load or routing, not necessarily policy

Jämför svaret med tabellen innan du tillskriver tunneln något. En avvisning och ett kvarhållet namn betyder båda att resolvern fattade ett beslut, medan tystnad betyder att frågan aldrig fick något svar. Den skillnaden avgör om du jagar en policyägare eller en nätverksväg.

Två webbläsare kan följa två policyer

En webbläsare som levererar sin egen krypterade resolver behöver inte använda den server operativsystemet delar ut, så den kan ignorera policyn som tunneln byggdes för att tillämpa. Då är två webbläsare på samma maskin oense om samma värdnamn, och ingen av dem är trasig. Kontrollera vilken resolver varje program är bunden till innan du kallar filtret inkonsekvent.

När båda programmen använder tunnelresolvern och bara ett misslyckas ligger skillnaden i programmet, inte i DNS. Skriv ned resolveradressen per program, eftersom den detaljen försvinner när fönstret stängs.

Ändra det du äger, eskalera det du inte äger

Ditt nästa steg beror på vem som äger resolvern du pekar på. En du kör själv är en funktion du kan läsa och konfigurera: kontrollera det dokumenterade filtreringsalternativet och dess undantag och tillåt sedan det enda namnet. En din arbetsgivare eller leverantör kör är ett ärende med domänen, det exakta svaret och tiden.

Byt aldrig in en offentlig resolver för att tvinga webbplatsen öppen, eftersom privata namn slutar lösas upp och en medveten policy slutar gälla. Den snäva ändringen håller också beviset intakt, så att ägaren kan jämföra din rapport med sina egna poster. Efter ändringen upprepar du det ursprungliga programtestet i stället för en uppslagning från ett skal.

En blockeringssida är inte ett betrott certifikat

En ersättningssida som presenterar sitt eget certifikat utlöser en HTTPS-identitetsvarning, och omdirigeringen gör inte certifikatet giltigt. Klicka inte igenom den bara för att tunneln är uppe; varningen är ett separat förtroendebeslut som fortfarande måste vara korrekt.

Diagnosen stängs när namnet som misslyckas returnerar ett policysvar och ett kontrollnamn returnerar ett normalt genom samma resolver. Då är reparationen en policyändring, inte en tunneländring, och RFC 1035 svarskoderna är det du citerar i rapporten. Håll båda namnen och svaren tillsammans; det är hela ärendet.

Relaterade artiklar