Filtered Redirect (captive portal)
Simon Wedge
simon.wedge at sant.ox.ac.uk
Mon Feb 27 11:50:05 UTC 2017
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:unbound-users-bounces at unbound.net] On Behalf Of Simon Wedge via Unbound-users
Sent: 27 February 2017 09:06
To: unbound-users at unbound.net
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:unbound-users-bounces at unbound.net] On Behalf Of Simon Wedge via Unbound-users
Sent: 21 February 2017 20:08
To: unbound-users at unbound.net<mailto:unbound-users at unbound.net>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20170227/7d7db89d/attachment.htm>
More information about the Unbound-users
mailing list