Revision [2541]
This is an old revision of DnsSec made by BrianKoontz on 2011-07-28 13:04:06.
DNSSEC
This is a workspace set up to discuss DNSSEC as it relates to OpenNIC.Resources
- http://www.dnssec.net/
- DNSSEC in 6 Minutes - Set of PDF slides
- DNSSEC Howto
- Validating DNSSEC
- What problem does DNSSEC solve?
- 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.
