Bug 1163 - inconsistent origin for RDATA between local-data and access-control-tag-data
inconsistent origin for RDATA between local-data and access-control-tag-data
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
unspecified
Other All
: P5 minor
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-15 23:17 CET by JINMEI Tatuya
Modified: 2016-11-22 20:24 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-11-15 23:17:58 CET
Consider the following config snippet:

server:
	local-zone: example.com redirect
	local-data: 'example.com IN CNAME foo'
...
	local-zone: example.org static
	local-zone-tag: example.org "mytag"
	access-control-tag: 192.0.2.1/32 "mytag"
	access-control-tag-action: 192.0.2.1/32 "mytag" redirect
	access-control-tag-data: 192.0.2.1/32 "mytag" "CNAME foo"

Then, if the local-data is used, the CNAME target is assumed to be absolute:

% dig @192.0.2.1 www.example.com cname +short
foo.

But if the tag-data is used, it's assumed to be non-absolute, and the
matching local-zone's apex name is used as its origin:

% dig @192.0.2.1 www.example.org cname +short
foo.example.org.

In terms of implementation, the difference comes from how
sldns_str2wire_rr_buf() is called.  In the case of local-data, the
'origin' parameter is set to NULL, meaning "root":

	int e = sldns_str2wire_rr_buf(str, rr, &len, &dname_len, 3600,
		NULL, 0, NULL, 0);

But in the case of tag-data, it's set to the "zone name" (that can be
different for different queries):

		res = sldns_str2wire_rr_buf(buf, rr, &len, NULL, 3600,
			zname, zlen, NULL, 0);

Is this "inconsistency" intentional?  If not, I think it's at least
better to be consistent since it would confuse administrators.  Also,
if we chose to make them consistent I'd suggest always assuming root
name as the origin (or in other words assuming the name is absolute).
In fact, that's most likely to be the intent of the admin, and
especially so in the case of tag-data, since it could be used for
multiple different local-zone names.
Comment 1 Ralph Dolmans 2016-11-18 13:08:36 CET
Hi JINMEI,

I agree that this inconsistency might lead to confusion. I'm not sure how to fix.

The non-absolute behaviour in access-control-tag-data seems right to me because this tag can be applied to different local-zone domain names. If you want the CNAME target to be absolute, you can configure it as FQDN with trailing dot. If we by default would assume it to be absolute, there is no way to configure it to be non-absolute.

This flexibility is not needed on the local-data elements, because the owner is always the same. And, more important, changing the behaviour in local-data might break deployed configurations.

Maybe clearly documenting this inconsistency is enough?

Thanks,
-- Ralph
Comment 2 Ralph Dolmans 2016-11-22 15:00:48 CET
Hi JINMEI,

I briefly discussed this with Wouter. We cannot think of a valid use-case for the flexibility offered by the relative CNAME targets. I therefore changed the access-control-tag-data origin to root, making it consistent with local-data.

Thanks for reporting,
-- Ralph
Comment 3 JINMEI Tatuya 2016-11-22 20:24:03 CET
Sounds good.

You might also consider now maintaining access-control-tag-data in the form of binary rrset structures instead of text, as (unless I overlook something) there shouldn't be anything to be determined dynamically for each query anymore.  It will be obviously much faster in terms of query handling time.