I can now shed some more light on the behaviour:
This is my test configuration:
access-control-view: [ip-range]/24 whitelist
...
local-zone: "." redirect
local-data: ". A [server-ip]"
...
view:
name: "whitelist"
local-zone: "google.co.uk" transparent
view-first: yes
...
Test 1:
nslookup google.co.uk [server-ip]
Result 1:
Name: google.co.uk.sant.ox.ac.uk (that doesn't look right)
Address: [server-ip]
Test 2:
nslookup www.sant.ox.ac.uk [server-ip]
Result 3:
Name: www.sant.ox.ac.uk.sant.ox.ac.uk (still not right)
Address: [server-ip]
Test 3:
nslookup google.co.uk. [server-ip]
Result 2:
Name: google.co.uk (works
as expected)
Addresses: 2a00:1450:4009:801::2003
172.217.23.3
Test 4:
nslookup www.sant.ox.ac.uk. [server-ip]
Result 4:
Name: www.sant.ox.ac.uk (works as
expected)
Address: [server-ip]
>From this I have come to the conclusion that when a global redirect is in
>place using "." it is unable to match any other "local-zone" without appending
>. onto the end of the initial DNS request.
I honestly don't know where to go from here, users won't be appending all of
their DNS requests with . on the end of each request, and I need the redirect
to work with the whitelist.
As previously mentioned not using redirect doesn't result in this behaviour, as
refuse (for example) works without having to add . onto the end of the DNS
request, is this a bug?
Simon.
From: Unbound-users [mailto:[email protected]] On Behalf Of
Simon Wedge via Unbound-users
Sent: 27 February 2017 09:06
To: [email protected]
Subject: RE: Filtered Redirect (captive portal)
Apologies for following this up but does anyone have any suggestions on what I
should need to do to get a redirect everything working with some exceptions?
It sounds like Unbound should be able to do this, but for the life of me I
can't get it to work.
Simon.
From: Unbound-users [mailto:[email protected]] On Behalf Of
Simon Wedge via Unbound-users
Sent: 21 February 2017 20:08
To: [email protected]<mailto:[email protected]>
Subject: Filtered Redirect (captive portal)
Hi All,
I am currently building a Network Access Control system, and in order to keep
it "out of band" (via a layer 3 firewall), I would ideally like to use a DNS
redirect to direct people to the NAC server from a registration VLAN.
I am having issues with doing a redirect with some exceptions (the registration
VLAN needs access to the University Shibboleth servers and the IT registration
pages which are outside the College network).
Now I realise that I am not the first person to try and do this, so I searched
the mailing list for similar discussions.
https://www.unbound.net/pipermail/unbound-users/2010-April/001134.html
https://www.unbound.net/pipermail/unbound-users/2010-May/001171.html
Based on what I found (and read in the annotated unbound.conf file) I realised
that something like this should work:
local-zone: "." redirect
local-data: ". A <NAC server ip>"
local-zone: "google.co.uk" transparent
This however doesn't seem to work as I would expect it to, as everything is
redirected by the local-data to the NAC server ip.
(note: changing this to "refuse" rather than "redirect" works as expected, can
connect to google.co.uk, get refused for everything else)
I thought this might be a version issue, as CentOS 7 is packaged with an older
version (1.4.20??) and I know that in recent versions additional options were
added for the zone types.
So I compiled 1.6.0 from source and experienced the same behaviour, even when
attempting to use always_transparent , I tried all sorts of other iterations of
options and none worked as I had hoped...
Noticing that I can find multiple references to the above example, has the
behaviour of Unbound changed?
If so how do I accomplish the above, I would expect the "always_transparent"
would have been the answer if the local-data was the cause of the behaviour:
"always_transparent Like transparent, but ignores local data and
resolves normally."
But this still doesn't work as expected when using a redirect.
Many Thanks,
Simon Wedge
St Antony's College
University of Oxford
