An Minor Diversion into DNSSEC….

I realised recently an interesting milestone has been reached, that will thrill the people who have slaved on DNSSEC for over a decade: DNSSEC running end-to-end, into the house the way “it should really work” without requiring any configuration or intervention has happened.  After all the SOPA/PIPA anguish, seeing DNSSEC come to life is really, really nice. This post may also interest router hackers who’d like a real home router they can afford, particularly one that will do mesh routing.

Over the last five years, as part of my bufferbloat wanderings (and due to lightning), I have taste tested more home routers than I care to think about. In general, they have tasted rotten to the core.  No amount of spices have been able to cover the off flavour, of even the best on the market (note that I’ve tried all the major home router vendors except Apple in this wandering).

A couple weeks ago I upgraded my home network to Dave Taht’s latest CeroWrt build which is running Linux 3.3-RC6;  CeroWrt is a bleeding edge OpenWrt build that runs on a small set of hardware where we do our bufferbloat work. I now have two home routers meshed; all networks are routed, not bridged. At 6 networks/router, that makes 12 networks in my house.  CeroWrt is a real home router, and it’s beginning to taste very nice indeed. CeroWrt does lots of other neat stuff a router should do.

CeroWrt uses Bind 9.9, and has DNSSEC enabled; with both internal and external views, and caching for my local pleasure.

Here are recent DNSSEC milestones that made this all work:

  1. First half of 2010: the root name servers start actually running DNSSEC.
  2. January 2012: Comcast completes its DNSSEC deployment.
  3. Sometime before 2), as CeroWrt has had DNSSEC running for quite a while, the existence proof of running DNSSEC completely into the house occurred: precisely when, I don’t know. Previously, I was using Comcast’s test DNS servers manually configured, rather than the “regular” DNS server address handed out by DHCP by Comcast.
  4. When I installed CeroWrt again recently, everything “just worked” for DNSSEC after we managed to work around the one remaining CeroWrt/Bind bug. Since Comcast had finished its deployment, using their DNSSEC test servers was no longer needed. DNSSEC is now working end to end (with local caching, which is better than having to go to an ISP’s name servers for validation, or in this case, actually I’m two hops away from my ISP). I gather dnsmasq is also working on an dnssec proxy implementation.

As proof, I’ll offer a screen shot and a copy of my /etc/resolv.conf.DNSSEC demo screenshot.

# Generated by NetworkManager
domain home.lan
search home.lan
nameserver 172.30.48.65

The name server address is the CeroWrt router. This particular router is talking to my other primary router (remember, I’m running a two router mesh here), so in fact, that router happens to ask 192.168.1.1; but my primary router then shows it is using Comcast’s regular 75.75.75.75 and 75.75.76.76 addresses.  I’ll spare you two screen shots of that information.

While tons more work needs to be done by everyone to finish the DNSSEC job, all of those people who have slaved away make DNSSEC real so that it “just works” should all pat yourselves on the back, and we can all make a toast together.  There are certainly still bugs and further excitement (including one in CeroWrt), but DNSSEC has come a long, long way.

For the DNS people out there: the problem we’re having in CeroWrt is that DNSSEC needs the time to be correct within 60 minutes to validate certificates.  But there is no TOY clock in home routers, and you need to be able to do DNS lookups to find out what time it is.  As you can see, this is a circular problem that needs fixing for bind to be willing to validate addresses.

And, for the first time, I’m running a Linux version on my home router that is close to the same as my laptop, and is based on same as the latest release from kernel.org: Linux 3.3-RC6, which has BQL in it, even before Linus has been able to release RC7! My hat is off to Dave, and all the OpenWrt folks who have worked hard to make that happen, including juhos, otto, felix, and many others. From my iPAQ work a decade or so ago, and much more recently at OLPC, I know just how hard it is to keep up with mainline Linux development.

And, of course, I must thank all the OpenWrt contributors and Dave Taht, who leads the CeroWrt!

About these ads

8 Responses to “An Minor Diversion into DNSSEC….”

  1. dave taht Says:

    Um, er, additionally….

    As best as I recall we’d setup your dnssec forwarders to use ipv6.
    (one *more* step for dnssec, one giant leap for ipv6)

    If not, the relevant anycast ipv6 addresses for comcast are here:

    http://www.whatsmydns.net/dns/usa/comcast.html

    merely edit your forwarders file to include those.

  2. dave taht Says:

    The originators of dnssec deserve a lot of credit for (hopefully) designing a crypto authentication system *that works*, and those
    that work so hard behind the scenes to keep the DNS running

    What convinced me that we HAD to deploy dnssec ASAP was the dnschanger worm, which infected WELL over half a million routers (and several million users) last year.

    http://blog.eset.com/2011/11/09/dnschanger-and-protect-ip-fbi-hit-and-legislative-miss

    Paul Vixie and isc.org and the authorities deserve a lot of credit for fighting this one off. For continuing to fight that one off, actually.

    http://arstechnica.com/business/news/2012/02/500000-zombies-risk-death-as-dnschanger-court-order-nears-expiration.ars

    I’d learned of dnschanger, at roughtly the same time there were multiple failures of the SSL certificate system, with everything from cracker breakins to MITM attacks, to just plain stupidity, were convincing factors that our home ‘gateways’ really, really, really needed to work harder at being secure at the edge.

    So DNSSEC is NEEDED. Desparately. Everywhere.

    Now that I can talk about dnschanger mildly more freely, there are several specific things in cerowrt that are designed to also thoroughly thwart dnschanger’s behavior. (Am I going to say what they are? ask me privately)

    And still, the router providing dnssec needs to be adaquately protected.

    I am still not satisfied with cerowrt’s overall default levels of security (std default password, no ssl on the config interface,
    and I need to seriously evaluate the default firewall rules in the presence of ipv6 before it’s released) – but in a research project, there is a compromise between ease of use, and proof of concept, and security that is hard to achieve.

    I’m very glad to be able to demonstrate working dnssec, nearly-out-of-the-box at this point, and the official release of cerowrt WILL fix https://www.bufferbloat.net/issues/113.

    In the long term, we have a few ideas to secure the gates better (hint: see kerberos), while improving the end to end experience (ipv6, new protocols, and pcp)… while the battle against the bad guys continues, and we try to move ever further forward, in furthering the internet.

  3. Adam Williamson Says:

    Does the wireless work well on CeroWRT or has that not been a focus? Can you get high bandwidth 802.11n performance? I can get 20-30MB/sec with the 3700’s stock firmware.

    Right now I have ridiculous setup where I have a 3700 acting solely as a wireless bridge and a Linksys as the actual router, because I found that trying to use the 3700 as a router with dd-wrt, it had a weird bug where it would stop routing out to the internet for a couple of minutes, every few hours, then start up again, for no apparent reason and with no useful logs. But obviously, I’d be happiest with a firmware that let me use the 3700 as the sole router and ditch the other box.

    • gettys Says:

      Works well for me ™: but testing is still really in its early days and I’d hate to do side by side comparison or publish numbers without systematic careful testing. Care to do some systematic testing? CeroWrt runs on the WNDR3700v2 and WNDR3800.

      Felix Fietkau, Andrew McGregor and Dave Taht did quite a lot of work on the driver last fall; it was suffering from several problems: 1) excessive buffering for packet aggregation, and 2) infinite retransmit. These fixes are upstream in Linux these days (and in CeroWrt; I’m not sure if the fixes are in current OpenWrt or not for the Atheros chips).

      • Adam Williamson Says:

        I can probably give it a shot at some relatively quiet times, but this is my only network so I’m probably not going to try and switch to it in the middle of F17 Beta cycle if it’s still fragile :) Thanks for the info. It sounds like an interesting project to try out once I have time to devote to it and can live with it being down for a bit if that happens.

  4. dave taht Says:

    I easy get 60Mbit on 5ghz. In good conditions, with good hardware on both sides, sfqred mildly tuned, well over 110Mbit.

    2.4ghz, not so much, but that’s the pollution of the commons more than anything else.

  5. dave taht Says:

    “1) excessive buffering for packet aggregation, and 2) infinite retransmit. These fixes are upstream in Linux these days (and in CeroWrt; I’m not sure if the fixes are in current OpenWrt or not for the Atheros chips).”

    Those changes went into the linux 3.2 and linux 3.3 mainline kernels, as well as many other bufferbloat related fixes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 674 other followers

%d bloggers like this: