Input needed: DNS on the endpoint: dnssec-trigger and the hotspot warfare

[Paul Wouters]

Hi,

There is a package in review that allows one to simply run DNSSEC
on the endnode by dynamically reconfiguring the locally running
DNS server. This process is mostly invisible to the user.

https://bugzilla.redhat.com/show_bug.cgi?id=754583

What happens is basically the following:
- network manager connects to a new network
- dnssec-triggerd probes to see how clean it is:
   - Can we use the DHCP listed DNS servers?
   - If not, can we query authoritative servers directly?
   - if not, can we use an open resolver on port 443?
   - if not, can we use an open resolver on port 443 using
     TLS encapsulation
   - if not, offer the user to go "insecure" or "cache only"
     (via dnssec-trigger-panel)

If the user needs some bogus DNS, eg for a hotspot redirect, it has a
"hotspot" mode where you can briefly allow insecure DNS without putting
it in your cache, then when you have accepted the terms (or paid) you
can reprobe and re-enable DNSSEC.

This works fairly well, though we can still do better on NM integration.

The real question I have is the port 443 resolver. It is surprising how
many hotspots still transparently take (and break) port 53, even after
signon, so the port 443 transport is quite regularly used (eg here in
Canada, with most coffee places like Starbucks and Second Cup). Currently,
there is an open resolver configured by upstream, but they are not able
to handle a "Fedora size" userbase on such a resolver.

Is there infrastructure within the Fedora Project to run some of these
resolvers? I am willing to take on maintenance for those if we do.

Is there infrastructure within the Fedora Community to run some of these
resolvers in an "ntp pool" like way? I can donate a few mbps in Europe,
but have no good resources in North America.

Can we send Fedora users to DNS(SEC) servers operated by third
parties? While security is not much of a concern (DNSSEC is in use for
those domains willing to protect themselves) there is a potential issue
of privacy on the DNS queries.

I would really like to get some feedback on this. Both the software and
the infrastructure questions.

Paul

[Kevin Fenzi]

On Mon, 28 Nov 2011 10:29:22 -0500 (EST)
Paul Wouters <paul(a)xelerance.com&gt; wrote:

>  
>  Hi,
>  
>  There is a package in review that allows one to simply run DNSSEC
>  on the endnode by dynamically reconfiguring the locally running
>  DNS server. This process is mostly invisible to the user.
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=754583
>  
>  What happens is basically the following: 
...snip...

>  The real question I have is the port 443 resolver. It is surprising
>  how many hotspots still transparently take (and break) port 53, even
>  after signon, so the port 443 transport is quite regularly used (eg
>  here in Canada, with most coffee places like Starbucks and Second
>  Cup). Currently, there is an open resolver configured by upstream,
>  but they are not able to handle a "Fedora size" userbase on such a
>  resolver.
>  
>  Is there infrastructure within the Fedora Project to run some of these
>  resolvers? I am willing to take on maintenance for those if we do. 
I'm not sure how keen we are on running open recursive DNS servers. ;( 

Would any of the existing free services work for this? 
Googles open dns servers or opendns for example?

>  Is there infrastructure within the Fedora Community to run some of
>  these resolvers in an "ntp pool" like way? I can donate a few mbps in
>  Europe, but have no good resources in North America. 
I think we could find resources, but I would be concerned that this
would open us up to DOS attacks, bind vulnerabilities and lots of
traffic. 

>  Can we send Fedora users to DNS(SEC) servers operated by third
>  parties? While security is not much of a concern (DNSSEC is in use for
>  those domains willing to protect themselves) there is a potential
>  issue of privacy on the DNS queries. 
Yeah, not sure on that. I would say we would want to inform our users
of what we are doing before transparently redirecting their queries. I
don't know how feasible that might be however. 

kevin