Bugzilla – Bug 1163
inconsistent origin for RDATA between local-data and access-control-tag-data
Last modified: 2016-11-22 20:24:03 CET
Consider the following config snippet:
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
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
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.
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?
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,
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.