default local DNS caching name server

Paul Wouters paul at
Mon Apr 14 14:21:29 UTC 2014

On Mon, 14 Apr 2014, William Brown wrote:

> This seems like a sane(ish) method of doing this. What happens if the
> hotspot page is down? Why not use a mirror-like setup with yum where you
> try 2 or 3 mirrors and if they fail then you declare it to be a portal?

It has multiple A records matching the redundancy of the fedora

> *how* can you tell if it's dodgy. You can tell captivity from above, but
> you can't easily see if an ISP is say TTL tampering or data tampering?

TTL tampering does not really affect our operation. When caches are
chained, you always get lower TTLs. That's how cached data works.
Raising the TTL is only allowed within our confines.

Data tampering is detectable by DNSSEC. For those domains that are not
protected by DNSSEC we cannot detect tampering. If the publisher want
their data integrity, they will have to sign their zones.

>> unbound does not really care about transparent proxy's on port 53. As
>> long as they don't break DNS (and DNSSEC). If they redirect port 53 to
>> some broken DNS server, unbound will try to work around it. If port 53
>> is broken it will attempt DNS over port 80 of various fedoraproject DNS
>> servers, or DNS over TLS on port 443.
> How do you setup DNS over TLS?

Unbound has this capability already build in. unbound-control activates
via (currently via dnssec-triggerd, in the future via NM) using the
keywords tcp-upstream or ssl-upstream.

> Again, how can you guarantee that the fedora infrastructure won't go
> down? My devils advocate points out we are adding more reliance on
> "third party" infrastructure here. Could it again be a case similar to
> the mirrors where you can "become" a fedoraproject DNS node to help load
> balance?

Not yet, but it is a thought. Although it is probably more stable and
better to than see about getting sponsored services from one of the
large ANYcast DNS cloud providers. Note that when you get to the point
of needing port 80 or 443 for DNS, you are arguably already on a pretty
disfunctional rogue network where you probably shouldn't be on. It
hampers your (DNSSEC) security. So you can see these services as "better
than disconnecting from the network".

> It's not as much the case, which makes me happier, but I want to know
> the conditions on which you decide a DNS server is "dodgy" or not.

For a detailed list you will have to check the source code. But it
includes thing like DNSSEC records, proper wildcard NSEC(3) records,
CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older
versions of common DNS software. Cases the IETF actually experienced in
the wild.

>>> * If a forwarder exists on the network, unbound uses it for all queries.
>> Yes, but not for open wifi. Only for physical wire and secured wifi.
> Okay. Can this point be made clear on the proposal page? Also the
> conditions for Physical wire, and secured wifi?

Yes, we can do that.

> There are also a number of tethering situations that may actually be
> mis-interpreted as secure. IE my phone has a WPA2 hotspot with DNS that
> goes via 3g. How does unbound treat this? It would only see the secure
> wifi ...

We cannot protect against wired or secure wifi running insecure DNS. We
do run our tests and if it works install the forward. If it fails to
work we won't install the forward.

> Consider also some wifi hotspots have their own "local" zones that are
> needed, so again, I do think that unbound should use the local forwarder
> irrespective of network security, because else you may risk breaking
> things.

You sometimes cannot, because often those hotspot routers are old and
broken and have crappy DNS proxy/mangling, breaking DNSSEC. That's the
premise of how this entire DNS mess started - we could not use DNSSEC
when using DNS servers obtained from the network. Anyone injecting rogue
domains (what you call "local zones") cannot be distinguished from an
attack. Those hotspots should use proper DNS names and/or http
redirection for those local zones. Although note that currently
dnssec-trigger does give you the option to remain in "insecure mode"
which would use the local DNS, and give access to those zones.

> Or how would you suggest this is solved. For arguments sake lets
> say:
> SSID: myawesomeopenhotspot
> DHCP provides no domain-name info.
> I CNAME all records to my.hotspot. until authenticated.

If this does not do http(s) redirection, than it is a very very broken
setup. You would also need to block port 53 to prevent people using to bypass your authentication. So I do not see this in the wild
(and I've done the hard work of sitting in many coffee shops for
science). hotspots tend to intercept port 80 to a mini web server that
only serves a redirect, sometimes without any DNS name, often with a DNS
name only resolvable by using their DNS. And that is fully supported by
the current solution.

There are many possible scenarios to come up with that will not work.
There are manual overrides for that. In my years of experience, these
kind of problems are far more rare than for instance the hotspot network
using the same IP range as my remote VPN network, causing me to fail to
be able to establish a VPN connection.

> Your hotspot test will be triggered, but if unbound won't use the local
> forwarder, you won't be able to resolve my.hotspot. on the insecure
> wifi.

Arguably, you CNAMEs my domain away is a breach of the DNS "contract"
anyway. The method is wrong. It also just runs too many risks for the
hotspot vendor of not working.

> okay, but lets combine these two points. My ISP mucks with the TTL of
> some website from say 300 to 30000000. Unbound would respect this to
> that amount, or to the TTL max (Which is still 86400 iirc). If you
> aren't flushing the cache between networks you could end up with:
> * Suboptimal routes causing a poor user experience.
> * Incorrect cached zone data moving between networks with different DNS
> views of the world.

If we believe that artificial increase of TTL is a common manglement, we
can have dnssec-trigger (or the NM integrated version of that) check for
such mangling. I'm reluctant to try and solve every _imaginable_ problem
out there. If your ISPs badness causes suboptimal routes, than that's
not the end of the world, and you have your ISP to blame. One ISP
shouldn't be responsible for every fedora user flushing caches all the
time. Let's deal with this problem when we actually find it is a real
world problem.

> Ignoring the TTL change, lets just look at flushing between network
> state change. This would solve both the dot points listed. You only need
> to rebuild the cache on first network reconnect meaning:

"only rebuild"? You are asking everyone else to do hundreds of queries for
each time to join their 3G network. Remember, when validating, you don't
just have one record for a queried A record. Since you need to recurse
and do all the intermediate queries too because otherwise you don't have
the records to do full DNSSEC validation. It's not a reasonably thing to
flush the cache. We are working hard on ensuring the user _hits_ their
cache and gains speed up (including pre-fetching).  Waiting on various
roundtrips for DNS over 3G is going to cause a lot more delays than a
"suboptimal route". Your workaround will actually be detrimental to the
user experience.

Note, I'm trying to optimise that path too, see:

> Alternately, consider a per-network cache? IE on one network I build a
> named cache for that network, when I join the other I use that cache.

That's a lot of (over)engineering.

> This would also solve my 3g WPA hotspot case, given the cache built on
> the hotspot doesn't polute my work wifi for example.

That was already addressed with a full cache flush when you connect to
your (secure) work wifi and get "." as forwarded zone flushed.

> In summary (Possibly something to add to the wiki)
> * Unbound does captive portal detection. Detail how it's done (See above
> in this email)
> * Unbound tries to find dodgy DNS servers. Detail how this detection is
> done.
> * On an open (Insecure) access point, unbound bypasses the local
> forwarder, except for names listed in the single valued attribute
> "options domain-name"  from dhcp

No, we cannot do that. As I said, a rogue hotspot could give the
domain-name "" to fool me into thinking I'm connecting
to my internal corporate network. We cannot automatically insert those
forwards on open wifi, unless the user manually performs an override.

> * On a secure network (Encrypted wifi, lan) unbound will use the
> forwarders as provided by DHCP.

Provided they are functional (eg don't break DNSSEC)

> * Unbound will flush the cache between authenticated networks. (If I
> read your last point correctly)

If we did a "." forward, yes.


More information about the devel mailing list