DNS-fouten in een HTTP-proxyketen: welke hop lost de naam op?
Onderscheid het bereiken van de lokale proxy, het oplossen van de parent en het oplossen van de website bij het diagnosticeren van een geketende forward-proxy.
client → local forward proxy → HTTP parent → websiteBegin bij de naam die faalt in plaats van te zeggen dat alle DNS bij “de proxy” hoort:
| Benodigde naam | Hop die hem moet bereiken |
|---|---|
| Eindpunt van de lokale proxy | De client |
| Eindpunt van de HTTP-parent | De lokale forward-proxy |
| Eindpunt van de website | De parent wanneer die de uiteindelijke verbinding opent |
Die hops kunnen verschillende resolvers gebruiken wanneer de eindpunten hostnamen zijn. Bij HTTPS kan een forward-proxy de bestemmingshost en -poort van CONNECT doorgeven aan de parent, die de uiteindelijke verbinding maakt. De oorspronkelijke client hoeft de website niet eerst op te lossen. Gewone HTTP-doorsturing draagt ook bestemmingsinformatie verder.
Dit is geen belofte dat precies één machine elke naam opvraagt. ACL-evaluatie, caching, beleid en implementatiedetails kunnen extra opzoekingen veroorzaken.
Controleer het fallbackbeleid wanneer de parent niet beschikbaar is. Als directe toegang is toegestaan, kan de lokale proxy de hop worden die naar de website kijkt, met eigen beslissingen over resolver en bronadres. Alleen een parent configureren bewijst niet dat elk verzoek hem heeft gebruikt.
Bij een storing: bepaal de naam en het proces dat hem probeert op te lossen voordat je een hosts-bestand aanpast. Een aanpassing aan clientzijde kan niet elke latere beslissing repareren. De uiteindelijke openbare bron hoort bij de hop die de websiteverbinding opent; die bron observeren is niet hetzelfde als meten waar DNS plaatsvond.