DNS-flaters yn in HTTP-proxykeatling: hokker hop lûkt de namme op?
Skied it berikken fan de lokale proxy, it oplossen fan de âlder en it oplossen fan de website by it diagnostearjen fan in keatlingfoarútproxy.
client → local forward proxy → HTTP parent → websiteBegjin mei de namme dy't mislearret, ynstee fan te sizzen dat alle DNS by “de proxy” heart:
| Nedige namme | Hop dy't it berikke moat |
|---|---|
| Einpunt fan de lokale proxy | De klant |
| Einpunt fan de HTTP-âlder | De lokale foarútproxy |
| Einpunt fan de website | De âlder as er de definitive ferbining iepenet |
Dy hops kinne ferskate oplossers brûke as de einpunten hostnammen binne. Foar HTTPS kin in foarútproxy de bestimminghost en -poarte fan CONNECT trochjaan oan de âlder, dy't de definitive ferbining makket. De oarspronklike klant hoecht de website net earst op te lossen. Gewoane HTTP-trochstjoering draacht ek bestimmingsynformaasje fierder.
Dit is gjin tasizzing dat krekt ien masine elke namme opfreget. ACL-ewaluaasje, caching, belied en ymplemintaasjedetails kinne ekstra opfragen feroarsaakje.
Kontrolearje it fallback-belied as de âlder net beskikber is. As direkte tagong tastien is, kin de lokale proxy de hop wurde dy't nei de website sjocht, mei syn eigen besluten oer oplosser en boarneadres. Allinich in âlder konfigurearje bewiist net dat elk fersyk him brûkt hat.
By in flater: identifisearje de namme en it proses dat him oplosse wol foardat jo in hosts-bestân bewurkje. In wiziging oan klantkant kin net elke folgjende beslissing reparearje. De definitive iepenbiere boarne heart by de hop dy't de website-ferbining iepenet; it waarnimmen fan dy boarne is net itselde as mjitte wêr't DNS plakfûn.