Revision history for DnsSec
Revision [3777]
Last edited on 2016-05-30 22:49:37 by dingo [Replaces old-style internal links with new pipe-split links.]Additions:
~- [[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
~- [[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
Deletions:
~- [[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
Revision [3550]
Edited on 2015-03-31 08:46:48 by dingo [Other mirror, probably from the original author]Additions:
~- [[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://clayshek.wordpress.com/2009/01/06/dnssec-101/ DNSSEC 101]] Correct link of dead link in article above
Deletions:
Additions:
~- [[http://www.apricot.net/apricot2009/images/lecture_files/dnssec_in_6_minutes.pdf DNSSEC in 6 Minutes]] - Set of PDF slides
Deletions:
Additions:
~- [[http://it.toolbox.com/blogs/techscrawl/enabling-dnssec-on-bind-29315 Validating DNSSEC]]
"." 257 3 5 "APdle...N3d";
"." 257 3 5 "APdle...N3d";
Deletions:
"." 257 3 5 "APdle...N3d";
Additions:
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
dd if=/tmp/urandom of=/tmp/random_1.1M count=2048
dd if=/tmp/urandom of=/tmp/random_2.1M count=2048
Deletions:
Additions:
/usr/sbin/dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -r ~/random_1.1M gopher # generate zsk (DS) key
Deletions:
Additions:
~- I exported two 1M files of random data from another machine:
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).
~- Add the following to the T2 ##named.conf## (see note below about trusted-keys entry):
// in the T1 servers will be needed to complete the "chain of trust"
"gopher." 257 3 5 "AwEAA...Nij";
Alternatively, T2s can simply enable the dnssec options above and add a root zone "anchor":
"." 257 3 5 "APdle...N3d";
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.
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).
~- Add the following to the T2 ##named.conf## (see note below about trusted-keys entry):
// in the T1 servers will be needed to complete the "chain of trust"
"gopher." 257 3 5 "AwEAA...Nij";
Alternatively, T2s can simply enable the dnssec options above and add a root zone "anchor":
"." 257 3 5 "APdle...N3d";
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.
Deletions:
~- Add the following to ##named.conf## (see note below about trusted-keys entry):
// in the T1 servers will be
// needed to complete the "chain of trust"
"geek." 257 3 5 "AwEAA...Nij";
dig geek. dnskey // Considered insecure, as this key might be spoofed in compromised servers
Additions:
~- The ##ad## flag indicates "authenticated data". This flag will only appear on the T2 server, not the T0/T1.
Deletions:
Additions:
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
"geek." 257 3 5 "AwEAA...Nij";
dig geek. dnskey // Considered insecure, as this key might be spoofed in compromised servers
brian@alabaster <03:23 AM>$ dig geek. +dnssec
; <<>> DiG 9.3.4-P1 <<>> geek. +dnssec
// Only needed for Tier2 servers at this time, but once ns0 has a valid key, another ##trusted-keys## section
"geek." 257 3 5 "AwEAA...Nij";
dig geek. dnskey // Considered insecure, as this key might be spoofed in compromised servers
brian@alabaster <03:23 AM>$ dig geek. +dnssec
; <<>> DiG 9.3.4-P1 <<>> geek. +dnssec
Deletions:
// Only needed for recursive servers at this time, but once ns0 has a valid key, another ##trusted-keys## section
"gopher" 257 3 5 "AwEAA...Nij";
dig @66.244.95.11 gopher dnskey // Considered insecure, as this key might be spoofed in compromised servers
brian@alabaster <03:23 AM>$ dig www.gopher +dnssec
; <<>> DiG 9.3.4-P1 <<>> www.gopher +dnssec
Additions:
~- [[http://www.matasano.com/log/756/a-case-against-dnssec-count-1-solves-a-non-problem/ What problem does DNSSEC solve?]]
Additions:
~- [[http://www.matasano.com/log/772/a-case-against-dnssec-count-2-too-complicated-to-deploy/ DNSSEC flow]] - Warning, might make your head explode
Additions:
=== 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)
~- /dev/random for some reason would not provide enough random bits to generate keys, so 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
%%
~- 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
/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 ##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
};
// Only needed for recursive 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";
};
%%
~- I used the technique in the "Validating DNSSEC" link above to create the ##trusted-keys## section. Basically:
%%
dig @66.244.95.11 gopher dnskey // Considered insecure, as this key might be spoofed in compromised servers
%%
~- 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 www.gopher +dnssec
; <<>> DiG 9.3.4-P1 <<>> www.gopher +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"
=== DNSSEC periodic maintenance ===
To do!
~- 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)
~- /dev/random for some reason would not provide enough random bits to generate keys, so 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
%%
~- 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
/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 ##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
};
// Only needed for recursive 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";
};
%%
~- I used the technique in the "Validating DNSSEC" link above to create the ##trusted-keys## section. Basically:
%%
dig @66.244.95.11 gopher dnskey // Considered insecure, as this key might be spoofed in compromised servers
%%
~- 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 www.gopher +dnssec
; <<>> DiG 9.3.4-P1 <<>> www.gopher +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"
=== DNSSEC periodic maintenance ===
To do!
Additions:
~- [[http://blog.techscrawl.com/2009/01/13/enabling-dnssec-on-bind/ Validating DNSSEC]]
Additions:
~- [[http://www.nlnetlabs.nl/publications/dnssec_howto/index.html DNSSEC Howto]]
Additions:
~- [[http://alan.clegg.com/files/DNSSEC_in_6_minutes.pdf DNSSEC in 6 Minutes]] - Set of PDF slides
