Current dnsDomainIs() implementation

[robvanoostenrijk]

Currently dnsDomainIs() dumbproxy implementation prefixes the domain parameter with a leading .

While this is a sensible thing to do, i.e. "google.com" will now not match "agoogle.com", it does not follow the established semi-standard set by Microsoft, Google Chrome and others:

https://issues.chromium.org/issues/41059350

Ideally administrators should match against ".google.com" to prevent matching direct domain suffixes.

I ran across this when trying to match (on purpose) a domain tail-end myself and finding the behaviour to be different from other implementations.

Any thoughts about this?

[Snawoot]

Established standard comes from Netscape: https://web.archive.org/web/20060718121747/http://wp.netscape.com./eng/mozilla/2.0/relnotes/demo/proxy-live.html#dnsDomainIs

Which defines this function as (spelling preserved)

Returns true iff the domain of hostname matches.

"google.com" and "agoogle.com" are two different domains, so my implementation follows what was defined by Netscape, even if their own implementation possibly didn't. In such ambiguous situation what to match right approach would be to match conservatively, leaving out grey zone of simple suffix match. Users, however, still can redefine this function:

function dnsDomainIs(host, domain) {
    return (host.length >= domain.length &&
            host.substring(host.length - domain.length) == domain);
}

print(dnsDomainIs("agoogle.com", "google.com"));
print(globalThis.dnsDomainIs("agoogle.com", "google.com"));

produces

JSROUTER: 2026/06/27 10:21:51 printer.go:17: INFO     true
JSROUTER: 2026/06/27 10:21:51 printer.go:17: INFO     true

or even preserve both:

const dnsDomainIs = function (host, domain) {
    return (host.length >= domain.length &&
            host.substring(host.length - domain.length) == domain);
}

print(dnsDomainIs("agoogle.com", "google.com"));
print(globalThis.dnsDomainIs("agoogle.com", "google.com"));

produces

JSROUTER: 2026/06/27 10:19:40 printer.go:17: INFO     true
JSROUTER: 2026/06/27 10:19:40 printer.go:17: INFO     false

These functions were made mostly to support run of PAC files as is. Modern JS language has far more advanced and better defined tools to match strings such as RegExp, which are backed by native Go regular expressions.

[robvanoostenrijk]

Possibly even simpler. Looks like the dumbproxy JavaScript engine supports .endsWith().

Ended up using that, as you mentioned its likely more performant as well because its in the current used JS engine specification.

The difference in behaviour is just something I noticed when porting over some script. I saw the same rabbit hole you mentioned, no clear definition on which of the behavioral variants it should actually be (due to lack of documented standard likely).