Today at the local (small) supermarket:
Well, at some point in history, both Spain and (parts of) Italy were part of the Hapsburg Empire, but the rest? Give me a break.
Categories
A sequel to this post:
My aim here was to build a compact set of 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:
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.
Categories
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?
(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?
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):
- DNSSEC validation is done at the ISP resolver:
DNSSEC doesn’t help the end-user here at all.
- 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.
- 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.
Categories
Diversions at work
Our office is at a busy intersection and sometimes this provides interesting views:
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.
The second picture is right before godzilla got her fingers on the track.