ERROR: recursive cloaking rule

[stockbsd]

upgrade from 2.1.15 to 2.1.16 on macos. previously working cloaking-rules.txt failed

mg.8803.xyz 104.18.0.153
proxy.8803.xyz mg.8803.xyz #line 21

sudo dnscrypt-proxy -config dnscrypt-proxy.toml
[2026-06-06 11:04:23] [NOTICE] dnscrypt-proxy 2.1.16
[2026-06-06 11:04:23] [NOTICE] Using default Weighted Power of Two (WP2) load balancing strategy
[2026-06-06 11:04:23] [NOTICE] Network connectivity detected
[2026-06-06 11:04:23] [NOTICE] Now listening to 127.0.0.1:53 [UDP]
[2026-06-06 11:04:23] [NOTICE] Now listening to 127.0.0.1:53 [TCP]
[2026-06-06 11:04:23] [NOTICE] Source [public-resolvers] loaded
[2026-06-06 11:04:23] [NOTICE] Source [relays] loaded
[2026-06-06 11:04:23] [NOTICE] Firefox workaround initialized
[2026-06-06 11:04:23] [NOTICE] Loading the set of cloaking rules from [cloaking-rules.txt]
[2026-06-06 11:04:23] [FATAL] recursive cloaking rule at line 21: target [mg.8803.xyz] matches cloak pattern [*.mg.8803.xyz]

[github-actions]

This issue was automatically closed because it did not follow the issue template. We use the issue tracker exclusively for bug reports and feature additions that have been previously discussed. However, this issue appears to be a support request. Please use the discussion forums for support requests.

[jedisct1]

Thanks for reporting this. I checked it against the current code, and I think this points to a real 2.1.16 regression in the new load-time recursive cloaking check, not just a support issue.

The relevant path is in dnscrypt-proxy/plugin_cloak.go. loadRules() stores IP targets as cloakedName.isIP around lines 100 to 108, stores name targets around line 109, then adds all rules to the PatternMatcher around lines 145 to 148. The new recursive check at lines 151 to 168 tests each name target with patternMatcher.Eval(cloakedName.target), but it only checks whether the target matches any cloak pattern. It does not inspect the matched CloakedName to distinguish an actual name-to-name cycle from a target that is already mapped directly to an IP.

That explains this specific failure. In the cloaking matcher, a bare rule such as mg.8803.xyz 104.18.0.153 is a suffix-style cloak pattern. The wiki documents this behavior with the example.com 192.168.2.37 example, which applies to both example.com and www.example.com, and pattern_matcher.go implements that default suffix behavior around lines 89 to 96 and 134 to 148. So when the second rule says proxy.8803.xyz mg.8803.xyz, the target mg.8803.xyz matches the first cloak rule and is rejected as recursive, even though the matched rule ends in an IP address.

The behavior change also lines up with the 2.1.16 release notes, which say “Recursive cloaking rules are now rejected at load time instead of being detected only when a matching query arrives.” That comes from commit a7f669c9774c01d7fd63aa3c0a725c93b6511c29. The intention makes sense for real cycles, such as a.example pointing to b.example and b.example pointing back to a.example, but this report looks like an over-strict false positive because the chain terminates at an IP rule.

The immediate workaround is to put the IP directly on the alias too, for example proxy.8803.xyz 104.18.0.153, or to point proxy.8803.xyz at a target name that is not also covered by cloaking. That is not ideal if the goal is to maintain one canonical mapping, so I think the code should probably be adjusted to detect actual cycles in the name-target graph instead of rejecting every target that matches any cloak rule.

I checked the existing comments on this issue, the cloaking documentation, the 2.1.16 release notes, related issues, PRs, and commits, and I did not find another open item that already tracks this exact false positive. This is an automated reply by Swival (https://swival.dev) using only open-source models, intended to help both the reporter and the maintainers.

[jedisct1]

Reopening because the repository audit above found this is likely an actionable regression in the 2.1.16 cloaking recursion check rather than a duplicate or out-of-scope support request.