[Proposal] Namecoin/DNSSEC integration

[ryanc]

Test domains:

dnssec.bit: Correct DNSSEC setup, should resolve fine
dnssec-failed.bit: DS record hashes do not match keys, should give SERVFAIL

[sugarpuff]

DNSNMC/okturtles appears to only be addressing what DANE does, not DNSSEC in general. I read the paper, it doesn't look like DNSNMC/okturtles can authenticate SRV/MX/TXT record data.

The goal of DNSNMC is to authenticate arbitrary data, it does not matter whether it is SRV/MX/TXT.

Maybe I misunderstood a bit, and biolizard is correct that these are somewhat orthogonal proposals that can be used together.

So, for clarity's sake, here's an example that uses DNSNMC with DNSSEC (or something else). Can you let me know whether I've understood your proposal correctly?

1. User asks for domain.bit
2. DNSNMC looks up the record and discovers that it contains: (1) the fingerprint of a DNS server, (2) the address of that server (can be an IP address, a CNAME from the old DNS system, or possibly even another Namecoin key in a different namespace). Let's say in this example it was a CNAME (ns1.foo.com)
3. DNSNMC creates an async request to ns1.foo.com and forwards the request.
4. It authenticates the response via some mechanism (DNSSEC, as you described, or simply a new NMC record type that contains a public key and a signature for the response).

Also, you can sign the .bit zone yourself and have authenticated data with no central point of trust.

Can you clarify in more detail what you mean by this?

[sugarpuff]

So I'm not clear on how DNSNMC makes this work unnecessary. [snip! see below] This work is for locally verifiable DNSSEC data, it's completely unrelated.

See my reply to ryanc above.

Doesn't DNSNMC force you to trust the operator of the DNSNMC server?

My response is the same as in the other thread. Yes, you would have to either trust yourself, or your friend:

It has been stated multiple times now: if you own the server, it is the same as though you were looking up the answers locally on your own machine.

And if you really trust the owner, then it is almost the same as that.

DNSNMC is intended to only be used with such servers. It does not matter whether you are traveling, at a café with a public wifispot, etc. The IP address remains the same and so does the server's fingerprint.

To use your words, running a client locally "doesn't scale", besides other issues.

[Pagel1928]

This is of course necessary if we are going to continue to support the ability to query external nameservers.

It doesn't make any sense to add this if we decide to pick the more secure and simpler choice to drop all external resolving.

*edit when I say secure, I include the privacy aspect of keeping domain resolution local

[Pagel1928]

My test server is up at namecoin.ryanc.org. DO NOT USE IT FOR ANYTHING CRITICAL! It's rate limited and I reserve the right to take it down and/or reconfigure it without notice or regard to anyone using it.

Instructions to follow sometime tomorrow.

Also note that my changes to NamecoinToBind have been merged into the official github repos.

I'm just wondering how you are validating the records? A normal DNS resolver would expect the DS records to be signed up to the root.

How did you setup your DNS server to authenticate them?

I noticed you have a RRSIG that can be validated by bit.

Code: Select all

dig DS dnssec.bit. @namecoin.ryanc.org +dnssec +short
31381 8 1 A40D566C75EA93556565C75B230CF35C079C7932
31381 8 2 B681C153534A3BDC31D0D6DC1CBB56BFD5D6606B12BCE3949DD7B18A D43A8FC1
DS 8 2 86400 20140123030814 20131224020814 41898 bit. EBJl1+MLtN3jGK+3pfevYPzWMZuQO+AbE3GldOaH8UlgxnUhLNbaz8HD k6pYQlfRaRri87YVQxVleShSHg1e9MdcvGUZfVqqjWnV+q43AZqHYYcb zOeJAdCd2TnSTVqaFJeb0UaBqHkfJwUAd8SwELmwSK2P/KaZAafK9QmH QHwjbOiIbCU+xuouRmF1XB+RzMVMadCrZWkWhTpgsxabc+pIkqtldx/c cEPShmfgo8wlsdadmL2Q3lolt5K2pYPR

But I can't fetch the DS or DNSKEY for bit., so I can't validate it myself.

I suppose everyone who runs their own namecoin enabled DNSSEC validating server, needs to generate their own bit. KSK and sign all the DS records when they are fetched from namecoin.

Public servers would just need to publish their DS/DNSKEY records for their bit. zone so users can add it to their trust anchor file.

[Pagel1928]

I propose we use base64 encoding instead of hex in order to make the representation a bit more compact.

I don't think it should be base64 encoded, because we do not base64 encode any other data to make it more compact.

If we really wanted the data to be compact we would use a format such as http://msgpack.org/ or gzip the data before inserting it into the blockchain. This could be discussed for the next spec revision.

Also good job getting it working

Just for my own notes:
RFC where sha256 is proposed: http://tools.ietf.org/search/rfc4509
RFC with more info about DNSSEC RRs: http://tools.ietf.org/search/rfc4034

[ryanc]

I don't think it should be base64 encoded, because we do not base64 encode any other data to make it more compact.

We don't have very much that would otherwise be represented in hex - TLS fingerprints are about the only other thing, and we should base64 those as well.

.... gzip the data before inserting it into the blockchain.

Key fingreprints cannot be compressed better than a raw representation, though the rest of the JSON could be.

[ryanc]

I'm just wondering how you are validating the records? A normal DNS resolver would expect the DS records to be signed up to the root.

How did you setup your DNS server to authenticate them?

I generated my own KSK and ZSKs for bit. and did some shenanigans involving views and adding the KSK to a trusted-keys config directive. DS records are generated from data stored in namecoin.

I have a script that I'm not quite done testing that generates the keys and dsset files on first run, and signs the zone on later runs.

I noticed you have a RRSIG that can be validated by bit.

Code: Select all

dig DS dnssec.bit. @namecoin.ryanc.org +dnssec +short
31381 8 1 A40D566C75EA93556565C75B230CF35C079C7932
31381 8 2 B681C153534A3BDC31D0D6DC1CBB56BFD5D6606B12BCE3949DD7B18A D43A8FC1
DS 8 2 86400 20140123030814 20131224020814 41898 bit. EBJl1+MLtN3jGK+3pfevYPzWMZuQO+AbE3GldOaH8UlgxnUhLNbaz8HD k6pYQlfRaRri87YVQxVleShSHg1e9MdcvGUZfVqqjWnV+q43AZqHYYcb zOeJAdCd2TnSTVqaFJeb0UaBqHkfJwUAd8SwELmwSK2P/KaZAafK9QmH QHwjbOiIbCU+xuouRmF1XB+RzMVMadCrZWkWhTpgsxabc+pIkqtldx/c cEPShmfgo8wlsdadmL2Q3lolt5K2pYPR

But I can't fetch the DS or DNSKEY for bit., so I can't validate it myself.

I was fiddling with it, it works again now:

Code: Select all

$ dig bit DNSKEY @namecoin.ryanc.org
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> bit DNSKEY @namecoin.ryanc.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20418
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bit.                           IN      DNSKEY

;; ANSWER SECTION:
bit.                    77504   IN      DNSKEY  256 3 8 AwEAAZnBbjURlsNQVUgE7siO6JvvGFzMc95OGcLKBP8hyTFwHDlnzGUf BpkPbfBKvCZRPwUja/mC5BvA6N9GisU+xTzI0ri3tfMMGzr5Kvhh2GVp bgCIFSArJGKRe9MLlaD0MzNaTOQhHUTeFRSJ69z4emmScbqzQJdXLTTL wBpDW3Za+6Jj7TsYPM/iF6ofXPfFiIEFzsMyJVn0SinGNItARiFgJwH7 kqCU6N3KIsaaHTy2+x7cjoTB/xapgZJBWNgmDQ==
bit.                    77504   IN      DNSKEY  256 3 8 AwEAAc8Hgkw57rsoXGTlXge481ePDGmE/Hdmi1FZ0uQejKSYTDJS/3k1 v1L+oAKB/IaKHRPIK3Ci+2db9OKdnR6ZkxNVryS+uiXvgLTrfU92TrZA Tvs5vDGJ6igx2FLuvLAO1++Pyuvg8gTS0Hq5n3ooxkO4lxPEYm9E0R60 a0QyY/lXhhT6888jfgVZmzu0/xGea4Je43oDzAuyPVeomP3L7N8W9hXI ukPnFxCcN/MS2seHrxQRb4M4iGwY2ezY2ABJsw==
bit.                    77504   IN      DNSKEY  257 3 8 AwEAAcK/9sAZOlc/ZG3IiDiDHjkU9Be2FZO5BD4ue5GHizV3cNwVYCoH G1jg0Bujy4AkYJ+MdRZNTJxMb5NRmSjkKogIky+QZ5Q2dextJHMorio7 Gt3VXN4HumkdiZalM7+Km2REpP2b8PQQXkgvHAJvoK/g0Fzr+2jNQtSI hfykaS2qmQiNzYY5Eq9B1GodvoGbGA0K+tWcOsQDh/hOPzrZ7Eh1tSup Ysmy9dAdcopLB9Wsd9dD5XkER9d+D3WmFBn6z1R2XLOyEzFIv9h0p2xu 66OIg0FBdiskeu666KR83hJhwSG9dGRhObSH+eoXbrH3VfVxFWIveYup uFOva+DvdITUlONjchRFNPgea4rs+c8Yn6tLeyuyeSVaVYRH9pymBUpX lzUhdY/7aTNb6aDhB85SSMqMrxJA/z5CUBnKaCDW1ewJ9an4OtAHy1Tp 5Oyndp8KWAsAlnBet66hNUFFXZP0nGPUWhs3GHVYTPTv+yoFwDuNdo/J 2qix93dFHWkgjQ==

;; Query time: 0 msec
;; SERVER: 162.243.202.92#53(162.243.202.92)
;; WHEN: Tue Dec 24 09:14:00 2013
;; MSG SIZE  rcvd: 849

I suppose everyone who runs their own namecoin enabled DNSSEC validating server, needs to generate their own bit. KSK and sign all the DS records when they are fetched from namecoin.

Public servers would just need to publish their DS/DNSKEY records for their bit. zone so users can add it to their trust anchor file.

It's a little more complicated that just adding it to the trust anchor file. You need a trusted-keys entry and a forward zone for bit. if you want to pull in the data from a public server.

[ryanc]

My robosigning script (WIP):

Code: Select all

#!/bin/bash
/usr/bin/php /home/namecoin/NamecoinToBind/namescan.php
echo

# Check if the zone needs to be recompiled
if [ ! -f "$DATA_DIR/bit.zone" -o "$DATA_DIR/db.namecoin.bit" -nt "$DATA_DIR/bit.zone" ]
then
        /usr/sbin/named-compilezone \
                -k ignore \
                -i none \
                -s full \
                -o "$DATA_DIR/bit.zone.new" \
                bit "$DATA_DIR/db.namecoin.bit"
        # Was named-compilezone successful?
        if [ $? -eq 0 ]
        then
                cd "$DATA_DIR"
                mv "$DATA_DIR/bit.zone.new" "$DATA_DIR/bit.zone"
                # Check if the keys have been initialized
                if [ ! -f "$DATA_DIR/dsset-bit." ]
                then
                        # Generate keys
                        /usr/sbin/zonesigner -random /dev/urandom -genkeys -ksklength 3072 -zsklength 1536 -zone bit bit.zone
                        # Find the key signing key(s)
                        for KSK in `grep -l key-signing $DATA_DIR/Kbit.+*.key`
                        do
                                # format them for use in a trusted-keys {}; block, requires a gnu version of sed (e.g. OS X doesn't support -r)
                                grep '^bit' $KSK | \
                                sed -r 's/\s+IN\s+DNSKEY\s+/ /;s/^(bit\.\s+[0-9]+\s+[0-9]+\s+[0-9]+\s+)/\t\1"/;s/$/";/;' >> \
                                "$DATA_DIR/trusted.keys"
                        done
                fi
                for ZONE in `egrep "^\S+\s+[0-9]+ IN DS\s+" "$DATA_DIR/bit.zone" | tee "$DATA_DIR/bit.zone.ds" | awk '{print $1}' | sort -u`
                do
                        egrep "^`echo $ZONE | sed 's/\./\\\./g'`\s+[0-9]+ IN DS\s+" "$DATA_DIR/bit.zone.ds" > "$DATA_DIR/dsset-$ZONE"
                done
                /usr/sbin/zonesigner -zone bit "$DATA_DIR/bit.zone" "$DATA_DIR/bit.zone.signed" &>/dev/null
                sudo /etc/init.d/bind9 reload
        else
                # TODO: Error handling/reporting
                echo Failed to compile zone.
        fi
fi

[Pagel1928]

I don't think it should be base64 encoded, because we do not base64 encode any other data to make it more compact.

We don't have very much that would otherwise be represented in hex - TLS fingerprints are about the only other thing, and we should base64 those as well.

.... gzip the data before inserting it into the blockchain.

Key fingreprints cannot be compressed better than a raw representation, though the rest of the JSON could be.

Well, the only reason we are using JSON currently is so that a human can easily understand the data in the blockchain directly.

If you base64 the data, you can no longer eyeball the fingerprint to compare it to the data directly/other places it is printed out in hex.

You are right keyfingerprints cannot be compressed better than a raw representation, I was just referring to the fact no attempt is made to compress data currently, the current spec does not have compression as a goal it has usability/eyeballing as a goal.

If the size of the data becomes important we will need a new a new spec with compression as a goal where we could use something like msgpack.

Anyway, cool stuff, and thanks for the explaination about how you have set it up I will try and get this working with nmcontrol.