Trend-Watcher

This cartoon appeared in the July 2011 issue of the IETF Journal

This cartoon appeared in the october 2011 issue of the IETF Journal and was inspired the broken Diginotar CA.

To appear in the IETF Journal.

To appear in the IETF Journal.

On 16 June 2010 around 21:20 UTC I witnessed a key generation procedure by which a DNSSEC Key Signing Key for signing the DNS root has been created.

The representation of this key in the DS RR format is as follows:

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5

The hash of this DS RR represented as a biometric wordlist reads:

deckhand pedigree snapline breakaway kickoff hemisphere flytrap detergent guidance coherence eating outfielder facial hurricane hamlet fortitude keyboard Bradbury cranky leprosy Dupont adroitness willow Chicago tempest sandalwood tactics component uproot distortion payday positive

For more information about the publication of the trust anchor see:

http://www.root-dnssec.org/wp-content/uploads/2010/01/draft-icann-dnssec-trust-anchor-00.txt

For more information on the signing of the root see:

http://www.root-dnssec.org/

Olaf Kolkman
July 13, 2010

A PGP signed version of this declaration can be found here.

I recently plugged in the old KORG Poly800. One of the early mass produced polyphonic Synths.

Unfortunately the batteries had drained, and the sound settings were completely gone. Now it is possible to restore the sound settings from the 20 year old cassette tape, if you a) would be able to find the original tape, and b) would have a cassette player. Unfortunately I have neither.

There are two ways you can go about this. Either you can restore all original sound settings manually from the documentation (pdf here) or you can download a “wav” file  with the original program from the POLY800 cassette. Connecting the Poly800 to your computer and fiddling a bit with the output level took me about 5 minutes.

I gave in.. after mucking around with LifeType for a few years I decided to migrate my blogs to wordpress.  Dan Rooke’s plog import plugin helped me to port all the posts. While I managed to get both the net-dns blog as well as this one running from the FreeBSD port install using the  Virtual Multiblog plugin.

After the usual tweaking of themes I’m done and I hope I can stay away from the actual install and configuration for a while.

You might ask: why not drupal.

Answer: I couldn’t find an easy migration tool for the LifeType blog.

In Geoff Huston’s recent ISP Column “Roll Over and Die?”, Roy Arends made a thorough analysis of the behavior of Unbound in the face of increased traffic towards authoritative servers after a failed key-rollover.

Key of Roy’s analysis is the observation that Unbound holds back after finding a bogus DNSKEY but does that on a per query instead of a per zone basis.

The default value of 60 seconds causes UNBOUND to restrain itself. However, since its a per-message cache, it only restrains itself for that qname/qclass/qtype tuple. Hence, if a different query is asked, UNBOUND needs to validate the response, sees a bogus DNSKEY in the cache and starts to re-fetch the dnskey keyset. In other words, a lame root key will cause DNSKEY queries for every unique query seen per 60 second window.

We will address this using a caching mechanism that will treat DNSSEC validation failures on a zone wide basis instead of treating them as intermittent RR-set failures. That should reduce the traffic to authoritative servers significantly.

The reason why this particular problem is interesting is that, as developers, we are constantly trying to make the tradeoff between the ability to recover from failure and the costs that those recovery mechanism impose on third parties. Failure to validate a signature can have many reasons, varying from misconfiguration or synchronization failure at the authoritative side, to on-path failure or attack, to misconfiguration a the receiving side. In this case we have not been conservative enough when making the trade-offs.

The fact that these sort of issues are identified are a healthy sign of what is still early deployment and we are eager to learn from these experiences. We use two resources for gathering experience that can help us making implementation choices: the IETF DNSOP working group and OARC. OARC is an organization where data is collected and shared so that impact of certain implementation behavior is quantified. We would like to ask people to contribute measurement data and share experiences.

Back to the particular issue of stale keys. The column points out that there are mechanisms to prevent stale keys being retained after a key rollover: the mechanism described in RFC5011. As of version 1.4.0 Unbound has native support for maintaining the trust-anchor for key-rollovers based on RFC5011. We have also made “autotrust” <link> available for cases where trust-anchors need to be maintained  and Unbound is not used.

In the particular case described in the columnm, RFC5011 methodology might not have worked; an old OS distribution carrying a stale key that is several generations old cannot be tracked using RFC5011 techniques. Wijngaards and Kolkman have been working on a proposal to fix that particular issue: “DNSSEC Trust Anchor History Service

Controleer of het adres begint met <a class="body_text_link" href="https://www.trend-watcher.org/JavaScript:openWin(‘/ing/pp/page/external_link/redirect/0,3042,1859_180483_849292156,00.html?ExternalLinkId=849292156′,’arcot’,'scrollbars=yes,left=10,top=10,location=yes,resizable=yes,toolbar=yes,menubar=yes,status=yes,height=600,width=800′);" target="_top" onclick="linkCode(this,’o',’https://postbank.arcot.com – 849292156′,’849292156′);">https://postbank.arcot.com</a>. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.