The "uBlock₀ filters – Badware risks" list (uAssets badware.txt, sourced into AdGuard DNS via HostlistsRegistry filter #50) contains this rule, targeting phishing lookalikes of roblox.com such as roblox.com.gr:
The trailing dot with no ^ terminator is intentional, valid uBO/Adblock syntax: it requires something to follow roblox.com., which real Roblox subdomains never have (they precede roblox.com, not follow it) but arbitrary lookalike TLDs do (roblox.com.gr, roblox.com.br, etc.). This lets one rule catch the whole class of roblox.com.* typosquats without matching the real domain or its real subdomains — using ^ instead would only match roblox.com exactly, which is the opposite of what's needed here.
HostlistCompiler correctly strips the unsupported $all modifier for DNS use, producing:
but this compiled rule ends up blocking clientsettingscdn.roblox.com (legitimate Roblox domain) on AdGuard DNS (confirmed via the "Check the domain" tool) while leaving roblox.com and other subdomains unaffected — behavior the source uBO syntax was never meant to produce.
Root cause
In src/transformations/validate.js, validAdblockRule has this check:
// Check if the pattern does not start with the domain prefix and does not contain a domain separator
if (!_.startsWith(props.pattern, DOMAIN_PREFIX) || sepIdx === -1) {
return true;
}where DOMAIN_PREFIX = '||' and DOMAIN_SEPARATOR = '^'. Since ||roblox.com. starts with || but contains no ^ anywhere, sepIdx === -1, and the function returns true (valid) immediately — bypassing every hostname-level check that follows.
More importantly, this is a case where the validator's own model doesn't match the DNS matching engine's behavior. The compiler's EXACT_DOMAIN_PATTERN regex and its comments show awareness of trailing-dot FQDN notation, but only for ^-terminated rules (e.g. ||example.org.^), where extractDomainPattern explicitly normalizes the trailing dot away, treating it as equivalent to no dot at all (line 228-229: "Allow trailing dot as absolute FQDN marker by normalizing it away for validation"). But per my testing of both urlfilter and dnsfilter, a trailing dot without ^ is not equivalent to no dot — it changes the rule's matching scope entirely (requiring something to follow, rather than matching the bare domain). A rule in this form isn't a broken domain rule that happens to skip validation; it's a different, valid rule type — a suffix/TLD-variant matcher — that the validator has no model for at all, so it can't verify whether the DNS-compiled output does what the original rule intended.
Suggested fix
Rules starting with DOMAIN_PREFIX but lacking DOMAIN_SEPARATOR shouldn't get an automatic pass. At minimum, apply the same checkChars/hostname sanity checks used for anchored rules; ideally, recognize trailing-dot-no-caret patterns as their own category and verify their DNS-compiled behavior actually matches the semantics they have in uBO (only matching hostnames with a suffix beyond the given domain), rather than silently passing them through as if they were ordinary domain-anchored rules.
If this is a known/expected side effect of how non-DNS-oriented filter rules get converted for DNS matching, consider adding a warning in the AdGuard DNS UI when a list contains rules that upstream maintainers have explicitly stated aren't meant for DNS use — uAssets maintainers told me directly in uBlockOrigin/uAssets#33636: "Filters in uAssets are not meant to be used in DNS. Remove that list in your DNS settings." Without a warning, users keep filing reports against uAssets for behavior that's actually specific to the DNS conversion, creating avoidable maintenance burden for filter list maintainers who have no way to fix it on their end without weakening what the rule is designed to catch.
The "uBlock₀ filters – Badware risks" list (uAssets
badware.txt, sourced into AdGuard DNS viaHostlistsRegistryfilter #50) contains this rule, targeting phishing lookalikes ofroblox.comsuch asroblox.com.gr:The trailing dot with no
^terminator is intentional, valid uBO/Adblock syntax: it requires something to followroblox.com., which real Roblox subdomains never have (they precederoblox.com, not follow it) but arbitrary lookalike TLDs do (roblox.com.gr,roblox.com.br, etc.). This lets one rule catch the whole class ofroblox.com.*typosquats without matching the real domain or its real subdomains — using^instead would only matchroblox.comexactly, which is the opposite of what's needed here.HostlistCompilercorrectly strips the unsupported$allmodifier for DNS use, producing:but this compiled rule ends up blocking
clientsettingscdn.roblox.com(legitimate Roblox domain) on AdGuard DNS (confirmed via the "Check the domain" tool) while leavingroblox.comand other subdomains unaffected — behavior the source uBO syntax was never meant to produce.Root cause
In
src/transformations/validate.js,validAdblockRulehas this check:where
DOMAIN_PREFIX = '||'andDOMAIN_SEPARATOR = '^'. Since||roblox.com.starts with||but contains no^anywhere,sepIdx === -1, and the function returnstrue(valid) immediately — bypassing every hostname-level check that follows.More importantly, this is a case where the validator's own model doesn't match the DNS matching engine's behavior. The compiler's
EXACT_DOMAIN_PATTERNregex and its comments show awareness of trailing-dot FQDN notation, but only for^-terminated rules (e.g.||example.org.^), whereextractDomainPatternexplicitly normalizes the trailing dot away, treating it as equivalent to no dot at all (line 228-229: "Allow trailing dot as absolute FQDN marker by normalizing it away for validation"). But per my testing of bothurlfilteranddnsfilter, a trailing dot without^is not equivalent to no dot — it changes the rule's matching scope entirely (requiring something to follow, rather than matching the bare domain). A rule in this form isn't a broken domain rule that happens to skip validation; it's a different, valid rule type — a suffix/TLD-variant matcher — that the validator has no model for at all, so it can't verify whether the DNS-compiled output does what the original rule intended.Suggested fix
Rules starting with
DOMAIN_PREFIXbut lackingDOMAIN_SEPARATORshouldn't get an automatic pass. At minimum, apply the samecheckChars/hostname sanity checks used for anchored rules; ideally, recognize trailing-dot-no-caret patterns as their own category and verify their DNS-compiled behavior actually matches the semantics they have in uBO (only matching hostnames with a suffix beyond the given domain), rather than silently passing them through as if they were ordinary domain-anchored rules.If this is a known/expected side effect of how non-DNS-oriented filter rules get converted for DNS matching, consider adding a warning in the AdGuard DNS UI when a list contains rules that upstream maintainers have explicitly stated aren't meant for DNS use — uAssets maintainers told me directly in uBlockOrigin/uAssets#33636: "Filters in uAssets are not meant to be used in DNS. Remove that list in your DNS settings." Without a warning, users keep filing reports against uAssets for behavior that's actually specific to the DNS conversion, creating avoidable maintenance burden for filter list maintainers who have no way to fix it on their end without weakening what the rule is designed to catch.