Defecțiuni DNS într-un lanț de proxy HTTP: care salt rezolvă numele?
Separați atingerea proxy-ului local, rezolvarea părintelui și rezolvarea site-ului când diagnosticați un proxy de redirecționare în lanț.
client → local forward proxy → HTTP parent → websiteÎncepeți cu numele care eșuează în loc să spuneți că tot DNS-ul aparține „proxy-ului”:
| Nume necesar | Saltul care trebuie să ajungă la el |
|---|---|
| Punctul final al proxy-ului local | Clientul |
| Punctul final al părintelui HTTP | Proxy-ul de redirecționare local |
| Punctul final al site-ului | Părintele când deschide conexiunea finală |
Aceste salturi pot folosi rezolvitoare diferite când punctele finale sunt nume de gazdă. Pentru HTTPS, un proxy de redirecționare poate transmite părintelui gazda și portul destinației din CONNECT, care stabilește conexiunea finală. Clientul original nu trebuie să rezolve mai întâi site-ul. Redirecționarea HTTP simplă transportă și ea informațiile despre destinație mai departe.
Aceasta nu este o promisiune că exact o singură mașină interoghează fiecare nume. Evaluarea ACL, cache-ul, politica și detaliile de implementare pot provoca căutări suplimentare.
Verificați politica de rezervă când părintele nu este disponibil. Dacă accesul direct este permis, proxy-ul local poate deveni saltul orientat spre site, cu propriile decizii privind rezolvitorul și adresa sursă. Doar configurarea unui părinte nu demonstrează că fiecare cerere l-a folosit.
La o defecțiune, identificați numele și procesul care încearcă să îl rezolve înainte de a edita un fișier hosts. O modificare pe partea clientului nu poate repara fiecare decizie ulterioară. Sursa publică finală aparține saltului care deschide conexiunea cu site-ul; observarea acelei surse nu este același lucru cu măsurarea locului unde a avut loc DNS.