Bug 1173 - deny action doesn't work for access-control-tag-action
deny action doesn't work for access-control-tag-action
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
unspecified
Other All
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-12-03 02:47 CET by JINMEI Tatuya
Modified: 2016-12-06 10:48 CET (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JINMEI Tatuya 2016-12-03 02:47:16 CET
With the following configuration:

	local-zone: example.org static
	local-zone-tag: example.org "testtag"
	local-data: "a.example.org. IN A 192.0.2.66"
	access-control-tag-action: 127.0.0.1/32 "testtag" deny

If I send a query from 127.0.0.1 to a.example.org, the local-data is
returned:

% dig @127.0.0.1 a.example.org +short
192.0.2.66

even if the tag is found:

[1480729377] unbound[5913:0] debug: matched tag [0] testtag

Is this behavior intentional?  In terms of the implementation, I
suspect this is because 'deny' is action ID 0 but it's also used as
the indication there's no action in localzone.c:lz_type():

				/* does this tag have a tag action? */
				if(i*8+j < tagactionssize && tagactions
				   && tagactions[i*8+j] != 0) {

I'm not sure if it's intentional just from the code, but if it is I
thin it should be explicitly documented.  (If it's not intentional the
implementation should be corrected, of course.)

I've confirmed the behavior for svn trunk rev 3943.
Comment 1 JINMEI Tatuya 2016-12-03 16:52:49 CET
I just realized the above example wasn't a good one to explain the
issue.  What I should have used is this configuration:

	local-zone: example.org static
	local-zone-tag: example.org "testtag"
	access-control-tag: 127.0.0.1/32 "testtag"
	access-control-tag-action: 127.0.0.1/32 "testtag" deny
(no local-data)

and a query for a.example.org/A.  I would have expected it would be
denied since it matches 'testtag' and there's no local data.  But the
actual result is NXDOMAIN.

So the example wasn't appropriate, but the main point of the report
still stands.
Comment 2 Ralph Dolmans 2016-12-06 10:48:41 CET
Hi JINMEI,

Fixed this by adding an unset type to the localzone_type enum, with value 0.

Thanks again for reporting,

-- Ralph