==== DNSSEC ====
This is a workspace set up to discuss DNSSEC as it relates to OpenNIC.

=== Resources ===
~- http://www.dnssec.net/
~- [[http://www.apricot.net/apricot2009/images/lecture_files/dnssec_in_6_minutes.pdf | DNSSEC in 6 Minutes]] - Set of PDF slides
~- [[http://www.nlnetlabs.nl/publications/dnssec_howto/index.html | DNSSEC Howto]]
~- [[http://clayshek.wordpress.com/2009/01/13/enabling-dnssec-on-bind/ | Validating DNSSEC]]
~- [[http://clayshek.wordpress.com/2009/01/06/dnssec-101/ | DNSSEC 101]] Correct link of dead link in article above
~- [[http://www.matasano.com/log/756/a-case-against-dnssec-count-1-solves-a-non-problem/ | What problem does DNSSEC solve?]]
~- [[http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/ | DNSSEC flow]] - Warning, might make your head explode

=== Test DNSSEC implementation on gopher zone ===
~- Used resources listed above
~- Using BIND 9.3.4-P1, single instance, two "views" (one is authoritative for gopher, the other is a recursive server)
~- Followed steps in the "DNSSEC in 6 Minutes" like above, except omitted ##dnssec-validation yes;## (not supported in BIND 9.3)
~- I exported two 1M files of random data from another machine:
%%
cat /dev/random > /tmp/random
...let run for a few seconds...
dd if=/tmp/random of=/tmp/random_1.1M count=2048
dd if=/tmp/random of=/tmp/random_2.1M count=2048 skip=2048
%%
Alternatively, one might use /dev/urandom since it does not block (but the jury is out on how "random" the generated bits are after the entropy pool is depleted):
%%
dd if=/tmp/urandom of=/tmp/random_1.1M count=2048
dd if=/tmp/urandom of=/tmp/random_2.1M count=2048
%%

~- Works best if each zone file is in its own directory
~- BIND 9.3 doesn't support the ##-N INCREMENT## option, so don't forget to increment your zone serial number before signing it
~- Quick synopsis:
%%
mkdir zones/gopher.zone
mv gopher.zone zones/gopher.zone
cd zones/gopher.zone
/usr/sbin/dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -r ~/random_1.1M gopher # generate zsk (DS) key
/usr/sbin/dnssec-keygen -a RSASHA1 -b 4096 -n ZONE -f KSK -r ~/random_2.1M gopher
cat Kgopher.+005+*.key >> gopher.zone
/usr/sbin/dnssec-signzone -o gopher gopher.zone
%%
~- Add the following to the T2 ##named.conf## (see note below about trusted-keys entry):
%%
options {
dnssec-enable yes; // use for both authoritative and recursive servers
dnssec-validation yes; // omit for BIND 9.3 (not needed)
};

// Only needed for Tier2 servers at this time, but once ns0 has a valid key, another ##trusted-keys## section
// in the T1 servers will be needed to complete the "chain of trust"
trusted-keys {
"gopher." 257 3 5 "AwEAA...Nij";
};
%%
Alternatively, T2s can simply enable the dnssec options above and add a root zone "anchor":
%%
trusted-keys {
"." 257 3 5 "APdle...N3d";
};
%%

~- I used the technique in the "Validating DNSSEC" link above to create the ##trusted-keys## section. Basically:
%%
dig gopher. dnskey // Considered insecure, as this key might be spoofed in compromised servers
%%
Alternatively, retrieve the root zone anchor (DS key):
%%
dig . dnskey
%%
One idea is to serve up a GPG signature of the DS key as a TXT file, to be verified by the receiving T2.

~- Copy and paste key starting with "257" into the ##trusted-keys## section above
~- To verify DNSSEC is working correctly, query your recursive (T2) server:
%%
brian@alabaster <03:23 AM>$ dig geek. +dnssec

; <<>> DiG 9.3.4-P1 <<>> geek. +dnssec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15189
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
%%
~- The ##ad## flag indicates "authenticated data". This flag will only appear on the T2 server, not the T0/T1.

=== DNSSEC periodic maintenance ===
To do!