Mga pagkabigo ng DNS sa isang kadena ng proxy na HTTP: aling hop ang nagreresolba ng pangalan?
Ihiwalay ang pag-abot sa lokal na proxy, pagresolba sa magulang at pagresolba sa website kapag nag-diagnose ng naka-kadenang forward proxy.
client → local forward proxy → HTTP parent → websiteMagsimula sa pangalang nabigo sa halip na sabihing lahat ng DNS ay pag-aari ng “proxy”:
| Kailangang pangalan | Hop na kailangang makarating dito |
|---|---|
| Endpoint ng lokal na proxy | Ang kliyente |
| Endpoint ng magulang na HTTP | Ang lokal na forward proxy |
| Endpoint ng website | Ang magulang kapag binubuksan ang huling koneksyon |
Maaaring gumamit ang mga hop na iyon ng iba't ibang resolver kapag ang mga endpoint ay mga hostname. Para sa HTTPS, maaaring ipasa ng forward proxy sa magulang ang host at port ng destinasyon ng CONNECT, na siyang gumagawa ng huling koneksyon. Hindi kailangang resolbahin muna ng orihinal na kliyente ang website. Ang simpleng pagpapasa ng HTTP ay nagdadala rin ng impormasyon ng destinasyon pasulong.
Hindi ito pangako na eksaktong isang makina ang nagtatanong sa bawat pangalan. Ang pagsusuri ng ACL, caching, patakaran at mga detalye ng implementasyon ay maaaring magdulot ng karagdagang paghahanap.
Suriin ang patakaran sa fallback kapag hindi available ang magulang. Kung pinapayagan ang direktang pag-access, maaaring maging hop na nakaharap sa website ang lokal na proxy, taglay ang sarili nitong mga desisyon sa resolver at source address. Ang pag-configure lamang ng magulang ay hindi nagpapatunay na ginamit ito ng bawat kahilingan.
Kapag may pagkabigo, tukuyin ang pangalan at ang prosesong sumusubok na resolbahin ito bago i-edit ang isang file na hosts. Ang pag-edit sa panig ng kliyente ay hindi kayang ayusin ang bawat kasunod na desisyon. Ang huling pampublikong pinagmulan ay pag-aari ng hop na nagbubukas ng koneksyon sa website; pagmamasid sa pinagmulang iyon ay hindi katulad ng pagsukat kung saan nangyari ang DNS.