Napake DNS v verigi proxy HTTP: kateri skok razreši ime?
Pri diagnosticiranju verižnega posredovalnega proxyja ločite doseganje lokalnega proxyja, razrešitev nadrejenega in razrešitev spletnega mesta.
client → local forward proxy → HTTP parent → websiteZačnite z imenom, ki ne uspe, namesto z trditvijo, da ves DNS pripada „proxyju“:
| Potrebno ime | Skok, ki ga mora doseči |
|---|---|
| Končna točka lokalnega proxyja | Odjemalec |
| Končna točka nadrejenega HTTP | Lokalni posredovalni proxy |
| Končna točka spletnega mesta | Nadrejeni, ko odpre končno povezavo |
Ti skoki lahko uporabljajo različne razreševalnike, kadar so končne točke imena gostiteljev. Pri HTTPS lahko posredovalni proxy nadrejenemu posreduje gostitelja in vrata cilja iz CONNECT, ki vzpostavi končno povezavo. Izvirni odjemalec mu ni treba najprej razrešiti spletnega mesta. Tudi navadno posredovanje HTTP prenaša podatke o cilju naprej.
To ni obljuba, da vsako ime poizveduje natanko en stroj. Ocena ACL, predpomnjenje, politika in podrobnosti izvedbe lahko povzročijo dodatna iskanja.
Preverite rezervno politiko, ko nadrejeni ni na voljo. Če je dovoljen neposreden dostop, lahko lokalni proxy postane skok, obrnjen k spletnemu mestu, z lastnimi odločitvami o razreševalniku in izvornem naslovu. Sama nastavitev nadrejenega ne dokazuje, da ga je uporabila vsaka zahteva.
Ob napaki pred urejanjem datoteke hosts določite ime in proces, ki ga poskuša razrešiti. Urejanje na odjemalski strani ne more popraviti vsake nadaljnje odločitve. Končni javni vir pripada skoku, ki odpre povezavo s spletnim mestom; opazovanje tega vira ni isto kot merjenje, kje je prišlo do DNS.