Replying to @PowerDNS_Bert

overwhelm the resolver with nsec3s and then \(quote Duke Nukem\): “Let God sort them out.”

Mon Jan 31 08:56:47 +0000 2011

The 3 in NSEC3 represents the number of people that actually understand all the corner cases. #dnssec #nsec3

Mon Jan 31 09:00:45 +0000 2011

RT @bdekruijff: Can anyone at #samsung please fire the guy who concieved #kies!? What a worthless piece of crapware..

Mon Jan 31 20:29:21 +0000 2011

How about on-the-fly signing? In this example we add a signature to any packet dealing with www.example.org. Again it is a matter of defining the matching, action and setup functions.

Matching

We don’t have to match anything coming in, we only need to sign pkts on their way out. So the function becomes:

func match(m *dns.Msg, d int) (*dns.Msg, bool) {
        // Matching criteria
        switch d { 
        case IN: 
                // nothing
        case OUT:
                // nothing
        }   
        // Packet Mangling
        switch d { 
        case IN: 
                // nothing
        case OUT:
                if m.Question[0].Name == "www.example.org." {
                        // On the way out sign the packet
                        m = sign(m) // keys are global
                }   
        }   
        return m, true
}

As you can see, it calls the sign() function where the actual signing takes place. We just sign the first RR in the answer section — if there is one.

You need to install Go and Go DNS, but then you can play with Funkensturm:

• Architecture and announcement;
• Transparant proxy example;
• Delaying proxy example;
• Signing proxy example.

Another application for Funkensturm is: delaying packets. Here we only delay packets with the recursion desired bit (RD) set, but it can be easily be changed to check for other properties of a packet, see godoc dns for all elements of DNS packets.

The configuration is similar as described here.

Matching pkts with RD bit set

The matching function becomes:

// the only matching we do is on the RD bit
// for incoming packets.
func match(m *dns.Msg, d int) (*dns.Msg, bool) {
        // Matching criteria
        var ok bool
        switch d {
        case IN:
                // only delay pkts with RD bit 
                ok = m.MsgHdr.RecursionDesired == true
        case OUT:
                // nothing
        }

        // Packet Mangling
        switch d {
        case IN:
                // nothing
        case OUT:
                // nothing
        }
        return m, ok
}

Action function

First a delay helper function. As shown here it returns true if the delay time isn’t reached, and false if a something should be delayed.

A transparent proxy is a proxy that does nothing, but it serves as a nice introduction into Funkensturm.

See this post for an architectural overview of Funkensturm.

Currently a configuration is compiled into the Funkensturm binary. As such it must look like a normal Go program.

Matching function

The matching function checks a packet for features and can optionally modify it.

This is the prototype of a matching function:

func match(m *dns.Msg, d int) (*dns.Msg, bool)

It receives a *dns.Msg which is a packet in Go DNS and a direction d which can be IN (first incoming packet) or OUT when the packet is on its way back to the client. It returns a DNS packet and a boolean value signaling a match.

What’s a DNS proxy?

A proxy is something this sits between a client and a server and does something with the data flowing through it. So a DNS proxy does this for DNS packets.

How does Funkensturm work?

Funkensturm consists out of 3 configuration parts:

1. A setup function for the initial setup.
2. Match/Modify function(s) — This function checks the packet for configured properties. If there is match true is returned.
3. Action function(s) — Taking the truth value from 2. (and the packet) as input, it does something with it.

With this setup you can change incoming packets before they are send through to the server. And you can change packet coming from the server that are send back to the client.

…Or why shell scripting is not really programming. Two scripts, one called bash-hate:

#!/bin/bash
count=0
cat /dev/null -  | while read line; do
    ((count++))
done
echo $count

and the other one zsh-love:

#!/bin/zsh
count=0
cat /dev/null -  | while read line; do
    ((count++))
done
echo $count

Then:

% cat testfile | ./bash-hate
0

% cat testfile | ./zsh-love
9

(Yes, I know about subshells. Just learn a real programming language.)

Doing cryptography is hard, luckily there are enough libraries out there that help you with it. OpenSSL is probably one of the best (known). Go has its own crypto library, which is written in pure Go.

Now with these aids crypto becomes doable for mere mortals, but all these libraries work with buffers which hold the data, the signature and sometimes the key also. Off-by-one errors in composing these buffers leads to a “Bogus signature” error (in DNSSEC). The problem here is that you don’t get any other clue on what went wrong. For me as a programmer an error such as “Shift buffer A one byte to the left and you’re OK”, would be much better. But due to the nature of crypto these kind of errors are not possible, nor desirable.

I’ve implemented axfr in my Go DNS library in nice and Go-like way (at least that’s what I like to think). Starting an axfr results in a channel which can then be used with the range keyword to loop over it, until the entire axfr is received.

Using it

First the normal begin of a Go program:

package main
import (
    "fmt"
    "dns"           // DNS package
)

Then we start the main function in which we define a new resolver and a channel for receiving the axfr messages. The channels will send dns.xfr messages which is defined as:

Lekker dat schuifelen over de ijzel

Fri Dec 31 09:33:13 +0000 2010

@WebAudience die was makkelijk! #nsa maar wel leuk

Fri Dec 31 09:37:28 +0000 2010

RT @jeroenbulten: Yes. De validating resolver doet het. http://twitpic.com/3ljnmz

Fri Dec 31 11:55:42 +0000 2010

So I can pack/unpack uint8/16/32, string, hex, etc. Looking at TSIG RFC: time_signed: uint48, 48! *GRRRR* #godns

Fri Dec 31 15:14:38 +0000 2010

Staan hier 2 jongetjes vuurwerk af te steken en het wordt meteen al mistiger. Beloofd wat voor vanavond.

And finally, after so many years miek.nl can be DNSSEC validated from the root down. Check it yourself.