The tool for DNS fingerprinting is fpdns, which is Perl based. In recent times development seems to have picked up, but a little competition never hurt anyone, so I wrote fp in Go. Fp is also a fingerprint program for DNS servers. Its aim is to be more readable then fpdns is (was?). And make it more easy to add new server types.

Help needed!

Do you have some old(er) nameserver laying around that can be queried? Does your (sick) mind know of a few extra evil queries that can be sent to nameservers? If so, please contact me: query@evilquery.nl. I want to get to a point where fp sends about 10 queries that can be used to identify a server.

Fingerprint

A fingerprint in fp looks like this:

.,CH,TXT,QUERY,NOERROR,qr,aa,tc,RD,ra,ad,cd,z,1,0,0,0,DO,4097,NSID

It has 20 fields, which are:

1. Domain name, . in this example;
2. Class, CH here;
3. Type, TXT here;
4. Opcode, QUERY;
5. Rcode, NOERROR;
6. Query response, qr, lowercase means false (not set), uppercase means true;
7. Authoritative, aa, lowercase. Thus not set here;
8. Truncated, tc, not set;
9. Recursion Desired, RD, uppercase, thus set;
10. Recursion Available, ra;
11. Authenticated Data, ad;
12. Checking Disabled, cd;
13. Zero, z;
14. Question section length, 1 here;
15. Answer section length, 0;
16. Authoritative section length, 0;
17. Additional section length, 0;
18. DNSSEC OK, DO (uppercase, thus set);
19. UDP bufsize, set to 4097;
20. NSID, uppercase: request NSID (or NSID was set).

These fingerprints are also used in creating the DNS queries that are send to nameserver(s) being tested.

A full nameserver fingerprint consists out of multiple of these fingerprints. Right now fp fires off 3 queries to test a server, so each nameserver fingerprint must also consist out of 3 fingerprints. The nameserver fingerprint of BIND9 looks like:

# BIND9 fingerprints
.,CH,TXT,QUERY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,NSID
auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,AA,tc,rd,ra,ad,cd,z,1,15,1,0,do,0,nsid
bind.,NONE,SOA,NOTIFY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,0,do,0,nsid

When fp is extended with an extra fingerprint, this BIND9 fingerprint also needs to get an extra fingerprint.

Trying it yourself

As said, Currently fp only uses three queries, but this is expected to be increased in the near future. In the data directory, the file q holds the fingerprints of the queries to ask. Currently it looks like this:

# These are the queries that we ask the nameserver being identified
#
# The order is important, as the data files of the known nameservers are compared
# in this order.
.,CH,TXT,QUERY,NOERROR,qr,aa,tc,RD,ra,ad,cd,z,1,0,0,0,DO,4097,NSID
auThoRs.bInD.,CH,TXT,QUERY,NOERROR,qr,aa,tc,rd,ra,ad,cd,z,1,0,0,0,do,0,nsid
bind.,NONE,SOA,NOTIFY,NOERROR,qr,AA,tc,RD,ra,ad,cd,Z,1,0,0,0,do,0,nsid

A local run looks like this (this is abbreviated):

% ./fp @localhost
Server type     Diffs       Fingerprint         Recevied
Bind9   0 .,CH,TXT,QUERY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,NSID .,CH,TXT,QUERY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,NSID
Bind9   0 auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,AA,tc,rd,ra,ad,cd,z,1,15,1,0,do,0,nsid auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,AA,tc,rd,ra,ad,cd,z,1,15,1,0,do,0,nsid
Bind9   0 bind.,NONE,SOA,NOTIFY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,0,do,0,nsid bind.,NONE,SOA,NOTIFY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,0,do,0,nsid
        =
Differences:    0

Nsd3    2 .,CH,TXT,QUERY,NOERROR,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,nsid .,CH,TXT,QUERY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,NSID
Nsd3    3 auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,aa,tc,rd,ra,ad,cd,z,1,0,0,0,do,0,nsid auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,AA,tc,rd,ra,ad,cd,z,1,15,1,0,do,0,nsid
Nsd3    6 .,CLASS0,TYPE0,NOTIFY,NXDOMAIN,QR,AA,tc,RD,ra,ad,cd,z,0,0,0,0,do,0,nsid bind.,NONE,SOA,NOTIFY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,0,do,0,nsid
            =
Differences:    11

What do you see here? On the left the nameserver type we're testing, then a number. This number represent the number of differences with the stored fingerprint for this server. When this number is zero, it means the reply from the unknown server is an exact match with one of the stored fingerprints. In general, the lower the number, the more exact the hit was. For bind9 in the example above, the accumulated number of differences is zero. This indicates the server is probably a BIND9 server.

For nsd3 the story is completely different. The accumulated number of differences is 11, so this server probably isn't a NSD3 server.

Report

With, -report fp will just show the fingerprint of a nameserver. If the server is positively identified, the finger print can be added to fp:

% ./fp -report @localhost
# Fingerprint of <Nameserver> <version>
# Supplied by <Name> on <Date>
#
.,CH,TXT,QUERY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,1,DO,4096,NSID
auThoRs.bInD.,CH,TXT,QUERY,NOERROR,QR,AA,tc,rd,ra,ad,cd,z,1,15,1,0,do,0,nsid
bind.,NONE,SOA,NOTIFY,REFUSED,QR,aa,tc,RD,ra,ad,cd,z,1,0,0,0,do,0,nsid

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

• 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.

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.

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.

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>

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).

But how do you merge a commit from a forked git repository? Turns out it is not that difficult.

The commit I want has the hash 5a11e88ddbef4ce7513aae93bdcd377449f45efb.

The steps:

• Create a remote branch:

  git remote add hamnis https://github.com/hamnis/pandoc2rfc
  

• Fetch the contents of it:

  git fetch hamnis
  

• Cherry-pick the commit you need:

  git cherry-pick -c 5a11e88ddbef4ce7513aae93bdcd377449f45efb
  [master 7501f13] transform.xsl: Supporting the output from pandoc 1.8.2.1:  
  * table/title 
  instead of table/caption  
  * table/tgroup/thead/row/entry instead of table/thead/tr/th  
  * table/tgroup/tbody/row/entry instead of table/tbody/tr/td
   Author: Trygve Laugstøl <trygvis@inamo.no>
   1 files changed, 3 insertions(+), 3 deletions(-)
  

Voila.