For some time, I've had this idea brewing for how the 'net would work
without DNS. Initially I was mostly thinking of how to get rid of the
dark side of the registrar business, but it appears that maybe it
could help with security in general too. It may not be feasible at
all, or I may have forgotten extremely crucial points. I'm not a DNS
guru, so bear with me and consider this as a thought experiment. This
is, however, a proposal for how the Internet could be made truly
decentralized, or acentric.
Made so, because it currently is very
centralized on at least two counts: the DNS is an inherently
hierarchical structure of authority; and so is the situation with the
SSL certificates used for securing websites. Let's start with DNS,
if you will.
Basically, the idea is to replace the current Domain Name System,
which is centralised in nature (even if subdomains can be delegated)
with a fully decentralised system with no central authority.
The point of current DNS is to map names to IP addresses in a unique
way. It currently works by registering a this name is managed by
such-and-such server, ask for details at such-and-such IP address
message. Of course, since there's only one namespace (or a limited
number thereof, if you consider that TLDs are different namespaces),
there needs to be a central authority to resolve conflicts, because
some names will be more popular than others.
I propose to start with a cryptographic key pair (think GPG key).
Anyone can create their key pair; we assume that it's extremely
unlikely for two people to generate the same keys, and that it's also
very hard for two people to generate keys with the same fingerprint.
By (being the only one) knowing the secret part of a key, I am the
authority on what can be signed with it. I could for instance sign
records that say that
www points to this set of IP addresses, and
smtp points to that other address. Within my area of authority,
which is to say within my domain. Which is identified by the
fingerprint of my key pair.
What do we have so far? A mechanism that allows in a decentralised
way to verify who's authoritative on the
F5566852EB92BD779CF137190EA756B5144843F5 domain . In DNS terms, more
probably
F55...3F5.some-tld. Now let's publish the signed records
on a decentralised peer-to-peer network. I'm not up to date with the
latest trends in that domain, but I think something like Gnutella or
Freenet would qualify, since it doesn't need central hubs but only an
initial list of nodes, and it does automatic discovery of new nodes.
Projects such as the
FreedomBox
(name likely to be changed) will probably help with that. Anyway,
when looking up
www.F55...3F5.some-tld, the resolver gets the signed
record (and the public part of the key) from the P2P network, checks
the signature, and uses the contents of the record to determine the IP
address. No central or delegated registry involved at any point.
Lesser risk of a single point of failure, which means better
resilience against outages. Also, a better resilience against
DNS-based censorship, be it promoted by non-democratic states or by
greedy corporations.
Of course, F5566852EB92BD779CF137190EA756B5144843F5 isn't a terribly
easy name to remember or transmit. But the string of hex could be
presented to the user in some other form easier to recognize for
people without geek super-powers. My favourite would be the
bibi-binary representation, but I'm told that the bubble-babble method
works equally well. It would still be unreasonable to expect people
to remember such names, and especially to type them into their web
browsers or e-mail agents. A possible solution to that would be to
use a short form, such as 144843F5 (or its bibi-binary equivalent),
complemented by a visual representation of the full fingerprint such
as the one SSH does. That pair could be displayed on business cards,
email signatures, glossy brochures, advertisements and so on, and
allow users to just type the strange word or flash the 2D barcode,
check that the funny picture matches (in case the strange word returns
several results), and get the website they want. Which they can of
course bookmark under a name they can remember, probably even the same
name that everyone else uses to bookmark that website. And nothing
precludes convenient directories mapping names to full URLs (like
search engines currently do) as long as users check that the visual
representation of the site they go to matches what they've seen
elsewhere.
That elsewhere could, of course, take advantage of the natural web
of trust that emerges in of GPG-using communities. If I'm directed at
a website whose key I don't immediately recognize, then I can see who
trusts that key to be legitimate (by checking the signatures), and who
trusts them, and so on. Ultimately, the decision is
mine to make,
and mine only. In any case, once I know what URL I want to visit, I
can be sure this DNS replacement will give me the right IP address (or
addresses). DNS servers replying with advertisement sites instead of
correct ones, and DNS-based filtering, will be things of the past.
Of course, having the right IP address only solves the attacks on the
DNS part. Eavesdropping can also happen by diverting traffic at the
IP level. But we have a trustable way to know information related to
a domain, so let's use it: the signed record can also contain the
fingerprint of cryptographic keys (SSL or SSH or whatever). So we can
be sure we're actually talking to the correct server, rather than to
some man-in-the-middle spy. With the same guarantees of correctness
as the ones for the DNS, backed by the web of trust and out-of-band
validation. Again, we get rid of the hierarchy of certification
authorities , some of which have been known for helping organizations
get at the (supposedly secret) data people exchange over the net.
To summarize: with this scheme, if I know the site I want to access is
F55...3F5, then I can be certain that a) I get the right IP address
for it and b) I'm actually talking to it. And nobody in-between
can intercept the traffic, if the site is properly administrated and
its private key is kept secure. And from the site admin's point of
view, there's no need to trust DNS registrars and SSL certification
authorities not to fool around with the data, or blackmail me into
paying increasing fees for keeping my URL working or my SSL key
certified. There's still the problem of the allocation for the IP
addresses themselves, but two major parts of the centralized and
hierarchical net can be gotten rid of.
There are proposals attempting to fix part of the problems already,
but they're incomplete.
DNSSEC
only solves the authentication of DNS records, not the centralisation
problem.
Monkeysphere aims at adding
a web of trust to the SSL certificates system, but the CA chain
problem seems to persist (although I must admit I'm not up to speed
with the actual details).
This is of course only a rough draft, full of technical considerations
yet certainly not exhaustive. I've thought about it though, and I
believe there are no theoretical problems with the implementation of
such a scheme (apart for the handling of expiration and revocations,
probably). The main obstacle to mass-adoption I can envision is the
UI part, and the entrenched habit of just typing a keyword into a
search engine and implicitly trusting its results, then blindly
trusting the website itself; but even if mass-adoption isn't reached,
I can't see anything wrong with giving those who want to be careful a
more secure Internet.
Mostly everything in life boils down to the same troublesome issue: people are reading different things into what they read, and interpret them regularly in a way it wasn't meant to. It seems that in certain areas a culture of interpreting things in a bad way instead of good or asking how they were actually meant has established the rules of (not) working together but rather against each other and around each other. At times I would like to account it to language barriers, or cultural differences, but it happens with people from all areas so that reasoning would be too easy.
Even artists manage to do that, and in that certain area it creates something extremely creative and thoughtful. This blog entry thus contains three songs and six videos: Two different interpretations of the same lyrics. Maybe this is able to stir some thinking process whether the interpretation that one found for a given situation might be biased or even just looking from the wrong angle.
Today, you have very last chance to influence selection of 
The good folks at
This shows the market did indeed bounce off the oversold lows nicely
on a few occassions in 2009 and 2010 --- but also continued to slide after
hitting the condition. Nothing is foolproof, and certainly nothing as simple
as this is, so buyer beware. But it may prove useful in conjunction
with other tools.
The code for the script is
This week I've mostly been experimenting with lighting, most obviously in 
This brief announcement was published in the 
Tomorrow I won't have to deal with it getting dark at a soul-crushing 5:30
pm. Nor will I have to wake up blearily an hour early in the spring.
Instead I will be enjoying my new, custom time zone. It's "JEST", for "Joey's
Eastern (non)Standard Time", and in JEST, there is no spring forward or
fall back stress.
The folly of daylight savings time (Ben Franlin's best prank ever) really
becomes apparent when you have solar power. It's bad enough that the sun is
setting at 6:30 without compounding that by an hour. By keeping my clock
set so the sun sets in midwinter at 6 pm, I will maximise what little light
there is, and minimise time spent using batteries in the dark.
Of course, it helps that I'm my own boss, and that most of the people I
work with are probably not in a nearby timezone anyway, and that most
things are done asynchronously. Since JEST is an hour ahead of local time
here in the winter, I will, at worst, tend to be running early.
So I only have to change my clocks one time -- and by "change", I mean
create a custom timezone in Linux. Here's how to do that.
The 
