Query Log "Allow" button acts on the queried domain, not the CNAME target that caused the block

[akostibas]

Versions

• Core: v6.4.2
• Web: v6.5
• FTL: v6.6.2

Expected behavior

When a query is blocked because of deep CNAME inspection (the log row shows blocked <target>), the "Allow" button should let me unblock it — i.e. act on the CNAME target that actually triggered the block, or at least make clear that's what needs allow-listing.

Actual behavior

The "Allow" button POSTs the queried domain to /api/domains/allow/exact, not the CNAME target shown as the block reason. Because a blocked CNAME target is (correctly, by design) not overridden by an allow entry on the head domain, clicking "Allow" can never unblock the query — it just adds an inert allow entry for a domain that was never the problem. On a second click it also errors with UNIQUE constraint failed: domainlist.domain, domainlist.type, since the inert entry already exists.

The UI already knows the responsible domain — it renders it in the row (blocked thirdparty.bnc.lt) — so the button has the information it needs but acts on the wrong domain.

Steps to reproduce

1. Query a domain that CNAMEs to a gravity-blocklisted domain. Example: dl.mail.express-scripts.com → CNAME → thirdparty.bnc.lt (on StevenBlack/hosts).
2. In the Query Log the row shows blocked thirdparty.bnc.lt.
3. Click Allow. It adds/attempts to add dl.mail.express-scripts.com — the query stays blocked, because thirdparty.bnc.lt is still on a blocklist.

Suggested fix

For CNAME-cloaked rows, either (a) offer to allow the CNAME target, ideally with a note that it may be shared tracking infrastructure, or (b) disable the per-row "Allow" and explain that the block originates from the CNAME target. The current button presents a one-click action that is structurally incapable of doing what it implies.

(Note: the confusing raw UNIQUE constraint message is separately being addressed in FTL#2878; this report is specifically about the button acting on the wrong domain.)

[rdwebdesign]

Thanks for reporting the issue.

A fix is already in development.
The new code will allow the actual CNAME when the button is clicked, fixing the issue.
Read below about the changes.

[DL6ER]

Thanks for the report. The Allow button is actually working as intended: allowing the queried domain unblocks the query even though the block came from a domain in the CNAME chain. FTL whitelists the entire chain as soon as any domain in it (including the one you queried) is on the allowlist, so the blocklisted CNAME target does not need to be touched.

If it looked ineffective, the most likely cause is your client or OS resolver still serving the cached blocked answer - a fresh lookup after allowing should resolve. Allowing the CNAME target instead would be the wrong fix, as it would unblock every domain that happens to CNAME through that target.

The real problem is the second half of your report: clicking Allow again on an already-allowed domain shows a confusing error. We are fixing the query log to show a clear "The item is already present" message instead, in #3824.