Omgaan met DNS-fouten binnen een PAC-regel

Geef een mislukte PAC-DNS-lookup zijn eigen beleidstak in plaats van hem te behandelen als een geverifieerd adres buiten het lokale netwerk.

Een mislukte lookup bewijst niet dat de bestemming buiten je privénetwerk ligt. Hij bewijst dat deze PAC-evaluatie het adres dat nodig was niet heeft gekregen.

Dat onderscheid is belangrijk wanneer dnsResolve() een isInNet()-regel voedt. De PAC-implementatie van Chromium geeft null terug wanneer de resolutie mislukt. Bouw de fouttack niet op de herinnering dat het resultaat altijd een lege tekenreeks is.

function FindProxyForURL(url, host) {
    var address = dnsResolve(host);
    if (!address) {
        return "PROXY proxy.example:8080";
    }
    if (isInNet(address, "10.40.0.0", "255.255.0.0")) {
        return "DIRECT";
    }
    return "PROXY proxy.example:8080";
}

Dit voorbeeld stuurt niet-opgeloste namen naar de proxy. Dat is een beleidskeuze, geen universeel veilige standaard. Het kan nuttig zijn wanneer de proxy een resolver of netwerkbeeld heeft dat de client niet heeft. Een netwerk dat lokale resolutie vereist, heeft een andere expliciete uitkomst nodig.

Los het één keer op en hergebruik het resultaat. Zo blijft de beslissing aan één waarde gekoppeld en worden mogelijk trage hulpaanroepen niet herhaald.

Controleer ook de daadwerkelijke PAC-consument. Oude IPv4-hulpfuncties en uitgebreide IPv6-hulpfuncties hebben verschillende contracten. Een regel die is getest met de implementatie van één browser bewijst geen ondersteuning in elke toepassing die dezelfde PAC-URL gebruikt.

Als de eis alleen is om een bekend bedrijfssuffix te routeren, kan een hostnaamregel de lookup volledig vermijden. Kies adresgebaseerde classificatie wanneer het adres informatie is die het beleid echt nodig heeft.

Gerelateerde artikelen