DNS-foute in 'n HTTP-proksi-ketting: watter skakel los die naam op?
Skei die bereik van die plaaslike proksi, die oplos van die ouer en die oplos van die webwerf wanneer 'n gekettingde vorentoe-proksi gediagnoseer word.
client → local forward proxy → HTTP parent → websiteBegin met die naam wat misluk eerder as om te sê dat alle DNS aan “die proksi” behoort:
| Naam benodig | Skakel wat dit moet bereik |
|---|---|
| Plaaslike proksi-eindpunt | Die kliënt |
| HTTP-ouer-eindpunt | Die plaaslike vorentoe-proksi |
| Webwerf-eindpunt | Die ouer wanneer dit die finale verbinding open |
Daardie skakels kan verskillende oplossers gebruik wanneer die eindpunte gasheername is. Vir HTTPS kan 'n vorentoe-proksi CONNECT se bestemmingsgasheer en -poort aan die ouer deurgee, wat die finale verbinding maak. Die oorspronklike kliënt hoef nie eers die webwerf op te los nie. Gewone HTTP-deurgee dra ook bestemmingsinligting verder.
Dit is nie 'n belofte dat presies een masjien elke naam navraag nie. ACL-evaluering, kasberging, beleid en implementeringsbesonderhede kan bykomende opsoeke veroorsaak.
Kontroleer die terugvalbeleid wanneer die ouer onbeskikbaar is. As direkte toegang toegelaat word, kan die plaaslike proksi die webwerf-waartse skakel word, met sy eie oplosser en bronadres-besluite. Om bloot 'n ouer te konfigureer bewys nie dat elke versoek dit gebruik het nie.
Vir 'n fout, identifiseer die naam en die proses wat dit probeer oplos voordat 'n hosts-lêer geredigeer word. 'n Kliëntkant-wysiging kan nie elke stroomaf-besluit herstel nie. Die finale openbare bron behoort aan die skakel wat die webwerfverbinding open; om daardie bron waar te neem is nie dieselfde as om te meet waar DNS plaasgevind het nie.