Maintained by: NLnet Labs

Filtered Redirect (captive portal)

W.C.A. Wijngaards
Mon Feb 27 13:45:38 CET 2017


Hi Simon,

These names: google.co.uk.sant.ox.ac.uk     make me think that you have
written CNAMEs and you did not terminate domain names with a trailing
'.'.  Domain names have to end in a trailing dot; and if you don't, the
zone name is appended to name.  In some cases unbound allows a missing
trailing dot; because zone names are not usually available.  But for,
eg. authority servers and zone files; this is the case.

So it looks like that name is the result of a typo where the trailing
dot is missing from a domain name.

Best regards, Wouter

On 27/02/17 12:50, Simon Wedge via Unbound-users wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170227/badd6931/attachment.sig>