Get the latest version (called weekly) of Go:

1. Get Go: hg clone -u release https://go.googlecode.com/hg/ go Note the directory you have downloaded it to and set $GOROOT to it: export GOROOT=$PWD/go. Add the GOROOT bin directory to your path: PATH=$PATH:$GOROOT/bin

2. Update Go to the latest weekly: cd $GOROOT; hg pull; hg update weekly

3. Compile Go: cd $GOROOT/src ; ./all.bash

   Install missing commands (gcc, sed, bison, etc.) if needed.

The latest Go is now installed.

Install GoDNS

1. Get GoDNS: cd ~; git clone git://github.com/miekg/godns.git
2. Compile it: cd godns; make ; make install
3. Compile the examples; cd examples; make ; make install
4. Query with q: q mx miek.nl
5. Report bugs

When using dig to debug DNS/DNSSEC errors, you (I have the need, I'm assuming you have it too) often want to know:

• Are the signatures in the message correct?
• Does the NSEC3 authenticated denial of existence proof look OK? (this is a work-in-progress)

With dig this is next to impossible, because we humans can not validate RSA signatures, nor hash names for NSEC3 validation.

This is why I added a little feature to q, the query-tool found in godns. The tool looks very much like dig or drill (from ldns).

Normal query

Querying for the MX records of miek.nl, works (and looks) just like using dig:

% q @open.nlnetlabs.nl mx miek.nl
;; opcode: QUERY, status: NOERROR, id: 41714
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;miek.nl.       IN       MX

;; ANSWER SECTION:
miek.nl.        345600  IN      MX      20 mail.atoom.net.
miek.nl.        345600  IN      MX      40 mx-ext.tjeb.nl.

;; AUTHORITY SECTION:
miek.nl.        345600  IN      NS      ext.ns.whyscream.net.
miek.nl.        345600  IN      NS      open.nlnetlabs.nl.
miek.nl.        345600  IN      NS      omval.tednet.nl.
miek.nl.        345600  IN      NS      elektron.atoom.net.

DNSSEC query

With the -dnssec option you request DNSSEC records and the -short option shortens long signatures and other records deemed too long.

% q -dnssec -short @open.nlnetlabs.nl mx miek.nl
;; opcode: QUERY, status: NOERROR, id: 54058
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1

;; QUESTION SECTION:
;miek.nl.       IN       MX

;; ANSWER SECTION:
miek.nl.        345600  IN      MX      20 mail.atoom.net.
miek.nl.        345600  IN      MX      40 mx-ext.tjeb.nl.
miek.nl.        345600  IN      RRSIG   MX 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...

;; AUTHORITY SECTION:
miek.nl.        345600  IN      NS      ext.ns.whyscream.net.
miek.nl.        345600  IN      NS      open.nlnetlabs.nl.
miek.nl.        345600  IN      NS      omval.tednet.nl.
miek.nl.        345600  IN      NS      elektron.atoom.net.
miek.nl.        345600  IN      RRSIG   NS 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 4096

But now the question remains, are those signatures valid? With the -check option you instruct q to go fetch the DNSKEYs (from the same server + port) and validate the signatures and RRSet with that key. The output you then get, looks like this:

% q -check -dnssec -short @open.nlnetlabs.nl mx miek.nl
;+ Secure signature, miek.nl. RRSIG(MX) validates RRSet with DNSKEY miek.nl./12051
;+ Secure signature, miek.nl. RRSIG(NS) validates RRSet with DNSKEY miek.nl./12051

;; opcode: QUERY, status: NOERROR, id: 53642
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1

;; QUESTION SECTION:
;miek.nl.       IN       MX

;; ANSWER SECTION:
miek.nl.        345600  IN      MX      20 mail.atoom.net.
miek.nl.        345600  IN      MX      40 mx-ext.tjeb.nl.
miek.nl.        345600  IN      RRSIG   MX 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...

;; AUTHORITY SECTION:
miek.nl.        345600  IN      NS      ext.ns.whyscream.net.
miek.nl.        345600  IN      NS      open.nlnetlabs.nl.
miek.nl.        345600  IN      NS      omval.tednet.nl.
miek.nl.        345600  IN      NS      elektron.atoom.net.
miek.nl.        345600  IN      RRSIG   NS 8 2 345600 19700101000000 19700101000000 12051 miek.nl. ...

;; ADDITIONAL SECTION:

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 4096

I think this is considered a #win.

(This is an English translation of this blog article over at sidnlabs.nl)

After the publication of the SIDN NSEC3 white paper we received feedback of a number of people. The most constructive feedback was from Karst Koymans of the University of Amsterdam. This, together with the other feedback has led to a version 2 of the white paper.

This version has the following differences with respect to version 1:

• A number of corrections;
• The NSEC3 example now returns three NSEC3 records in stead of two;
• Two figures are added;
• Empty non-terminals are explained (a little).

Version 2 of the white paper can be found here. Or here locally.

(This is a English translation of this Dutch blog article)

By writing the NSEC3 whitepaper, we gained a lot of insight in how "authenticated denial of existence" works. But some new questions popped up:

• Is NSEC3 the most efficient way to do (hashed) authenticated denial of existence?
• Are there ways to optimize the NSEC3 record that asserts or denies the wildcard?
• Can't we use Opt-Out for unhashed names too?

Answering these question led to the birth of NSEC4, which is documented in this internet draft.

This is only the first version (a -00 as its called by the IETF). Surely a -01 will follow and maybe an -02.

With NSEC4:

• We optimize the wildcard NSEC3 away by introducing a Wildcard bit flag. This shrinks negative answers with one NSEC4 (and signatures);
• We introduce "Zero Hashing", or no hashing at all. This creates an NSEC like record with Opt-Out; something the current NSEC lacks;
• We unify NSEC and NSEC3 into one new record: NSEC4.

We're aiming for the "experimental" track within the IETF, this removes the need for implementers to implement NSEC4, but saves the document for future generations. It's all about adding extra documentation to help people understand DNSSEC.

This came up during a recent Pandoc discussion. The discussion was about outputting <sectN> section styling when creating DocBook XML. Currently Pandoc outputs nested <section>s.

I argued you could easily change between the two formats and <section> is more flexible, so just leave Pandoc as it is. But it allowed me to play with XSLT once more. With the following results.

Translate to sectN

This XSLT translates <section> to <sectN> where N is 5. If the sections are nested deeper it switches to <section>.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="section">
<xsl:variable name="i" select="count(ancestor::node())"/>
    <xsl:choose>
        <xsl:when test="$i > 5">
            <section><xsl:apply-templates/></section>
        </xsl:when>
        <xsl:otherwise>
            <xsl:element name="sect{$i}"><xsl:apply-templates/></xsl:element>
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>
</xsl:stylesheet>

Translate to section

And this translate <sectN> to <section>, this was slightly easier, as you don't have to count anything.

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="sect1 | sect2 | sect3 | sect4 | sect5">
    <section><xsl:apply-templates/></section>
</xsl:template>
</xsl:stylesheet>

I've tweaked my vim color scheme quite a bit and tried to keep the colors of gvim (which I use less often) in sync.

This keeping in sync hasn't worked out, so I wrote this little script to convert the vim colors to the gvim ones:

Download the makegvim script, and use it like:

$ ./makegvim < ~/.vim/colors/<yourfile> > /tmp/x
$ mv /tmp/x ~/.vim/colors/<yourfile>

And now the colors of gvim should be identical to those of vim.

Note: colors like 000 must be used like cterm=0 otherwise the conversion fails (the script isn't that smart).