Bugzilla – Bug 828
missing type in access-control-tag-action redirect results in NXDOMAIN
Last modified: 2016-09-08 23:07:41 CEST
With the following configuration:
local-zone: example.com redirect
local-data: 'example.com IN A 192.0.2.1'
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" redirect
access-control-tag-data: 127.0.0.1/32 "testtag" "A 192.0.2.1"
1. Query for example.com/A is responded with 192.0.2.1.
2. Query for example.com/AAAA is responded with noerror/nodata.
3. Query for example.org/A is responded with 192.0.2.1.
4. Query for example.org/AAAA is responded with NXDOMAIN.
Is case 4 intentional? I suspect it's not, according to the following
comment in lz_zone_answer():
/* for static, reply nodata or nxdomain
* for redirect, reply nodata */
And, NXDOMAIN in this case could actually be harmful if the querier
caches the result (it could return NXDOMAIN to a subsequent type-A
query, for example).
Yes this is intentional. You configured NXDOMAIN for example.org in the local-zone statement. It then applied because of the tag (and no overrides for AAAA present). If you wanted a different action; i.e. noerror/nodata, that is possible by setting a soa record for the local-zone itself, and giving another data type at the node (i.e. not the one queried for). Then Unbound responds with a noerror/nodata with the SOA record for TTL.
Another way to look at this is that with a tag-action of redirect, A and AAAA should both be there, otherwise it'll fall through to the general case (unless you have A or AAAA there).
The comment in the code is then simply wrong. We should fix it. (What did you think it should say?)
But you are right. For redirect with plain local-zone it becomes a nodata answer. But if there is no data there it becomes nxdomain.
It is hard to copy that behaviour for the override.
I have adjusted it to return NODATA for redirect local-zone type instead of nxdomain. (it redirects some other type, so there is some other type, supposedly).
This should solve your bug in and make case 4 return a nodata answer.
Thanks, I've not closely looked into the code change, but I confirmed it now returns NOERROR/NODATA in case 4.