Tracks

Well, sometimes there is no time to build an elaborate set of tracks. Today, I just made a simple loop for Clemens to play with before I had to leave:

track 2009-06-30

DNSSEC and large packets

In the wake of .org going signed, we finally have good data what that means for the authoritative nameservers. Duane gave a good talk at the recent NANOG event, showing the increase of TCP connections.

So what is the problem?

In a nutshell: Packet sizes. DNS responses containing the DNSSEC specific RRSETs are larger, and setting the DO bit that triggers their inclusion is almost default these days. So we’re now routinely exceeding the 512 bytes that the original DNS spec required. Over the years, the IETF defined EDNS0 which allowed clients to announce their support for larger responses via UDP. Not this is finally really put to the test and we can see how fallback to TCP we still observe.

Continue reading DNSSEC and large packets

FUD, the Microsoft way

Dear Microsoft,

we all know that the “Fear, Uncertainty, and Doubt”-strategy worked quite well against Linux and other threats to your Monopoly business. By why do you apply the same tactic towards a Windows user that simply wants to open a zip-file?

microsoft-fud

(Translation: “This page contains an unspecified potential security risk. Do you want to continue?”)

What do you think a user should do with that information?

Heise, Slashdot, Broken Records, and DNSSEC

Almost whenever a security event involving Windows is featured on Slashdot or Heise, some Linux fanboys will invariably post their cocky “that would not have happened with Linux” messages.

I start to see the same thing with DNS incidents and DNSSEC.

This is just as childish and stupid, especially as the voices writing such notes are often enough established engineers and not your average adolescent geek.

In reality most of the recent DNS hacks were not perpetrated by crafting forged DNS responses to poison caches but were successful attacks against the Registrar/Registrant interfaces. No, DNSSEC would not have helped in such a case.

The same is true for DNSSEC and the domain-based censorship which was just passed by the German government. DNSSEC will not help here. It is no panacea against meddling with DNS answers. It depends on who is doing the validation and whether the offending domains are actually signed or not (not likely these days):

  1. DNSSEC validation is done at the ISP resolver:

    DNSSEC doesn’t help the end-user here at all.

  2. DNSSEC validation in the client, ISP recursor is used:

    If the domain is signed, then the user will get a NXDOMAIN (or maybe a better error-reporting) instead of the IP address of the STOP-sign website.

    So the censuring still works, just the alerting of the user (and the logging of the STOP-sign access) does not.

  3. DNSSEC validation in the client, full recursion at the client

    Censorship is ineffective. Just the same as when the local recursor does no DNSSEC checking.

Remember: DNSSEC is not about the availability part of security, it’s only about the integrity. Censorship does not really need to attack the integrity, it’s all about availability.

Tracks

track 2009-06-11a

This time I tried something new: the goal was to build a track where the electric locomotive would pass over all pieces when set on the track. That goal is simple to reach by building a simple loop or anything else topologically isomorphic to a circle. Getting the same result with a lot of switches and having the train run back over the same piece is a lot trickier. The only assumption you need to make is that the train will take the straight rail when encountering a switch.

track 2009-06-11b

The second picture is right before godzilla got her fingers on the track.