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
infrastructure.
*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
8.8.8.8 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:
http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00
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 "corp.paypal.com" 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.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
