ISP DNS vs Unbound - Akamai/CDN/DNS Leaks

mscaff · Apr 16, 2017, 1:55 PM

Hi guys,

I'm curious what the experts think on here - for CDN/Akamai, is ISP DNS the way to go? Would unbound do just as well to select proper server locations and akamai/CDN?

My ISP servers do not support DNSSEC afaik - they wont resolve when Unbound has DNSSEC enabled, however - I also have devices with alternate DNS servers set to mitigate DNS leaks, however I cannot utilise DNSSEC due to it being globally disabled to be able to resolve through ISP DNS.

–---------------------------------------

So to summarise - questions are:

1. Is Unbound just as good as ISP DNS in terms of Akamai/CDN?

2. Is there a better way to mitigate DNS leaks other than access lists in Unbound (rejecting the leaking client) and specifying alternative servers via static DHCP?

3. Is there a way to specify the ISP servers be accessed plainly, whilst still having DNSSEC globally enabled for the DNS leaking client (to anonymize requests etc)

4. Is there a way to pull VPN DNS instead and respond to queries through the VPN? (policy routed setup, no-pull, gateway OVPN interface, NAT'd source, tagged traffic dropped on WAN outbound.)

5. When the client (with its gateway specified as the OVPN interface) queries the specified DNS server (supplied via DHCP), would requests take place through the VPN or through WAN?

6. The proper definition for DNS leak - in this circumstance, would be leaking queries to ISP DNS, or querying ISP DNS through VPN? if anyone can clarify :/

Thanks lads - would appreciate any help :)

Cheers.

johnpoz · Apr 16, 2017, 3:24 PM

If you are using unbound out of the box.. It would be doing dnssec and resolving not forwarding. So when would a device that asks pfsense for dns ask your isp dns? If you don't want clients to ask other devices other than pfsense which would be resolving. Then block on the interface from using any outside dns and only allow queries to pfsense and then the resolver will go look up what the client is asking for from the authoritative servers - yes using dnssec.

At a loss to what that has to do with a CDN?

So you want or don't want clients to use the dns provided by your vpn? So your connecting through pfsense from a client to some vpn server/service?? Why not just connect to this vpn/vpn service with pfsense as your client and then policy route the clients you want to send the traffic you want through the vpn.. You could then have pfsense resolve through the vpn or not, etc.

Seems users hear the buzz word dns leak, and their tin foil hats tighten up and squeeze all the blood from their heads…

What are you concerns exactly, and we can discuss how to mitigate those or discuss if they are even actual concerns you should be having.

TS_b · Apr 17, 2017, 4:31 AM

What Mr Poz said.

If you want to prevent leaking DNS queries to your ISP and you are already using a VPN, just use Unbound exactly as it came out of the box with one change. Select your VPN as the only outbound interface for Unbound.

This cuts your ISP DNS server completely out of the equation. Your DNS queries will go direct to the root servers through your VPN tunnel, your ISP will just see encrypted traffic.

YOUR COMPUTER > PFSENSE BOX > VPN SERVER(encrypted) > ROOT DNS SERVERS

mscaff · Apr 17, 2017, 6:15 AM

Thanks for the replies guys - I believe I was unclear about a few things, my apologies.

In reply to johnpoz:

I'm fully aware of the fact Unbound will resolve and not forward on requests - my concern is that, if using the Resolver primary, without forwarding - would I not benefit from proper geocaching/akamai that one would generally benefit from with the use of ISP DNS?

I've just made a discovery - I'd like a confirmation here, as I believe my understanding was astray - this is my current setup:


- Point to point VPN configured between PF and a remote location, no-pull, few custom options for performance.

- OpenVPN interface (OVPN_INTERFACE) bound to the point to point VPN service (for lack of a better explanation)

- Firewall rule (policy route) on LAN outbound specifies any traffic originating from 10.1.1.2, use the default gateway (OVPN_INTERFACE), as well as being tagged NO_WAN_EGRESS

- Outbound NAT rule on OVPN_INTERFACE, any traffic matching 10.1.1.0/24 will be translated by NAT.

- Floating point rule on Outbound WAN, any traffic matching tag NO_WAN_EGRESS is dropped.

My concerns/questions:

Will traffic leaving 10.1.1.2, including DNS requests - if not specified to point towards Unbound (within the same LAN), leave through the VPN, and anything else be dropped?
If I'm getting DNS responses (nslookups) from 8.8.8.8 for example, while the VPN is up, and nothing when the VPN is down, this would imply the NO_WAN_EGRESS rule is doing its job?
I'm assuming requests via Unbound through the use of DNSSEC, remains plain text?
As mentioned above, will ISP DNS or Unbound be more useful in better akamai/CDN performance? geocaching etc.

–------------------

My desire is that any traffic originating from 10.1.1.2 remain completely anonymous, including DNS requests.
I'd like to have the rest of my LAN, be free from any sort of akamai selection/geocaching issues pertaining to buffering etc (on a 100mb line)

Thanks guys

TS_b · Apr 17, 2017, 6:57 AM

Will traffic leaving 10.1.1.2, including DNS requests - if not specified to point towards Unbound (within the same LAN), leave through the VPN, and anything else be dropped?

If you are policy routing that IP to your VPN Gateway, then everything it does goes through that gateway. You can select the outbound interfaces for Unbound in the Resolver settings.

If I'm getting DNS responses (nslookups) from 8.8.8.8 for example, while the VPN is up, and nothing when the VPN is down, this would imply the NO_WAN_EGRESS rule is doing its job?

Either your floating rule is blocking it or your policy routing or simply your configuration if you chose only the VPN for outbound Unbound. You can set your floating rule to log traffic, shutoff your VPN and see if you get anything in the logs to find out if it's the rule or not.

I'm assuming requests via Unbound through the use of DNSSEC, remains plain text?

Yes, DNSSEC is PT with authentication, DNCCRYPT is CT, but not included in pfSense.

As mentioned above, will ISP DNS or Unbound be more useful in better akamai/CDN performance? geocaching etc.

Unbound will cache your networks DNS requests, but on a small network that probably won't mean much. ISPs and other Third party DNS servers will be snappier for just about any small network.
–------------------

My desire is that any traffic originating from 10.1.1.2 remain completely anonymous, including DNS requests.

Then Resolve only and use only the VPN gateway for Unbound.

mscaff · Apr 17, 2017, 7:05 AM

Thanks for your reply.

As mentioned, I do not wish to route my whole LAN's Unbound requests through the VPN, only the specific client.

I think I've found a good solution however, I've now proven to myself by taking the VPN down, that DNS requests are indeed taking place through the VPN (from 10.1.1.2).

So - Unbound has 10.1.1.2 blocked by access list (just in case) - and DHCP has pushed 2 DNS servers to the client, which are now resolving through the VPN.

I'm happy with this setup - I will experiment with Unbound and forwarding, so I can utilise my ISP DNS servers for the LAN.

Thanks for the help guys :)

johnpoz · Apr 17, 2017, 10:35 AM

"I not benefit from proper geocaching/akamai that one would generally benefit from with the use of ISP DNS?"

Huh?? Use of the VPN could mess up your geo location for CDNs that point you to the best placed based upon your location.. For example your in CA.. Based upon where your dns query came from they would respond with IP of the best location to go to get whatever it is serving up the data from the CDN.

Forcing your query to look like it came from the VPN endpoint could make it look like your in Nebraska or something.. Where is your vpn endpoint??

"I will experiment with Unbound and forwarding"

Why should you be forwarding? If our worried about where a CDN is going to point you based upon your query - resolving is going to give them your IP.. Forwarding gives them the IP of the forwarder you forwarded too.. Where is it located? Again you might be in CA.. And the IP of isp dns might look like its Arizona… All comes down to the geo location databases the CDN would be using and what they show for your location.. I think you need to do a bit more research how that stuff actually works and resolving and forwarding.. I think you hung up that asking your isp gets you something?? It gets you nothing you can not get on your own with a resolver.. Other than maybe bad old data ;)

mscaff · Apr 17, 2017, 10:50 AM

With all do respect John, I don't believe you've interpreted my questions correctly:/

I'll clarify - geocaching/akamai optimisation is for my LAN
- I am only routing one client through the VPN
- All other clients the goes through WAN
- Unbound currently serves my whole LAN, directly through WAN.
- The VPN client utilises a non-logging DNS service.

The question I had does not relate to the VPN client, consider that sorted.
My question was - would switching my LAN from Unbound resolution, to Unbound forwarding to my ISP servers, improve akamai/geocaching performance and server selection, as opposed to full resolution from Unbound.

Hopefully this clears it up, apologies for the ambiguity :/

johnpoz · Apr 17, 2017, 12:43 PM

No.. it would not.. I already went over how geo locations for sending your traffic to the closest CDN servers.. Using unbound in resolver mode is going to directly access the NS for the fqdn of where you trying to go. If they are going to return an IP for a based upon the IP of the query. The best thing you can do is to resolve!!

If your wanting to use your isp CACHE of some CDN content.. Then you would want to use your isp dns, that would point to their cache they are running for that specific CDN. Not all isp do this, and quite often their caches are overloaded anyway ;)

Are you talking about geo location, or using a ISP cache of CDN data.. You used the term geocaching.. Which has nothing to do with any of this and is a kind of hobby or game people place finding stuff or locations people hide based up long and lat which you use your gps to find, etc.

mscaff · Apr 18, 2017, 4:51 AM

Thanks John - so in a nutshell, the resolver should be good for almost all circumstances, but selecting ISP DNS might improving CDN/akamai caching then?

I'm going to experiment with both - at the moment I'm just noticing (rarely) buffering of Facebook content for example, which might be a CDN/akamai based issue.

Cheers