[Dnssec-trigger] split dns, was Re: dnssec-trigger patches

[Paul Wouters]

On Wed, 21 Jan 2015, Pavel Simerda wrote:

>> Committed them both. I assume the VPN preference is very nice for VPN
>> users. :-)
>
> It may be quite a rare use case, though. Most VPN users are happy to choose
> between all access through VPN and access only to services under VPN domains
> and IP addresses.

Indeed. Wouter, don't be tempted to make the new patch the default. The
problem of dnssec-trigger+unbound is that people depend on split view
DNS and in some cases that involves dozens or more domains, so not just
the one you are informed about via DHCP or a VPN.

So, on the one hand, I want my non-VPN queries to not go over the VPN,
as my personal queries are non of my employers business. I run a split
VPN and only *.redhat.com queries to to the internal DNS servers.

On the other hand, large campuses tend to have dozens of internal-only
domains, so you are kind of forced to throw all DNS at the campus DNS
server, even if you VPN in. Because you simply have no list of domains
to forward to the campus VPN server.

Some of the recent flush vs no-flush on network changes also come into
play here. The simple case with VPN and 1 domain (eg redhat.com) already
works. When I (dis)connect the VPN the received domain from VPN gets
flushed from cache. But that does not help the "campus case", where
you need to flush all cache once you move between campus/non-campus.

While "always flushing everything" solves the campus issue, it is really
bad for two reasons. I find myself often on flaky wifi, and if I get my
cache cleared when my wifi stutters, then I'll never have any working
DNS on those networks. Additionally, when my laptop opens, I'm sure my
launched programs create a nice fingerprint of DNS requests, which would
leak into the world if my cache was empty, allowing pervasive monitors
to track me.

>From an ideology point if view, I want to tell the campus networks to
migrate away from split view DNS (which are terrible with DNSSEC and
validating stubs) or at the very least use very low TTLs so their campus
only DNS data doesn't survive in my cache. The campus deployments want
us to "not break things".

The sad end result is probably more DNS options for the clueless enduser :(

Paul