I'm using unbound to build a somewhat unusual type of captive portal.
It's a Linux box that acts as a restricted WiFi access point to a group
of clients, and which has an outbound connection to the internet and
knows DNS servers to use out there.
The portal lets users freely access one particular site on the internet;
it forces accesses to another specific site back to itself; and it makes
everything else go to a third specific site on the internet. In other
words, it behaves as follows:
1. traffic to example1.org is to be resolved normally, i.e. ultimately
by the DNS server on the internet that the captive portal machine knows
about
2. traffic to example2.org is to be resolved to 192.168.0.1 (the captive
portal machine)
3. everything else is to resolve to example3.org, a machine out on the
internet
I've added the following to my conf file. 1 & 2 work fine but 3 doesn't
work. I'd be grateful for advice about what I'm doing wrong.
local-zone: "." redirect
local-zone "example1.org." transparent
local-zone "example2.org." static
local-zone "example3.org." transparent
local-data: ". IN CNAME example3.org."
local-data: "example2.org. IN A 192.168.0.1"
BTW, I now see that the documentation specifically says the CNAME local data won't work, and advises me to use a stub zone. But when I look at the documentation for that, none of it seems to relate to what I'm trying to achieve, i.e. the * -> example3.org mapping, except for the exceptions identified above.
In other words, DNS tunnelling will work without restriction. Thanks
for keeping this classic loophole available for the few that care to
use it. Yes, I'm being sincere.
Thanks for pointing out a potential problem but obviously I wouldn't have suggested this if I was aware of an attack.
If I've understood it correctly, to be useful DNS tunnelling is carried out to a DNS server under the attacker's control. It's not clear to me how they could do that. Say the attacker controls a DNS server at example4.org. Assuming the scheme that I have defined (1-3 in my original message) works, then when the attacker tries to resolve example4.org, the request will be CNAMEd to example3.org, which I control.
So please explain what I am missing.
I'd also appreciate an answer to my original question :-). I'm sorry if I'm being dense but I'm new to all of these configuration issues.
You are right, Tim. I didn't read your config in detail. Feel free to
keep the DNS tunnel loophole available, though, in the spirit of
elevator operators' secret key press overrides, red light zebra
crossing tricks of the trade, etc
I'm trying to work around my inability to configure Unbound as per my original message (below) and have encountered another problem. According to the manual, "Answers for local zones are authoritative DNS answers" but this seems not to be the case:
local-zone: "." redirect
local-data: ". IN A 192.168.0.1"
It's better too. You don't "screw up" the one DNS/webpage the user tried to go to.
Especailly in browsers with fast-flux protection that cache the DNS answer despite
any minimum TTL from the DNS answer.
