Long-term Memory » dnssec http://blog.dest-unreach.be A collection of note-to-self's Sun, 29 Jan 2012 16:05:00 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 DNS(SEC) – Firewall issues http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues#comments Wed, 10 Feb 2010 18:03:25 +0000 Niobos http://blog.dest-unreach.be/?p=1630 I just read this message by Mark Andrews on the BIND mailing list. It explains the possible issues with DNSSEC and over-protective firewalls, giving test-commands to verify your setup. This post is also interesting for regular DNS traffic, since a firewall doesn’t know the difference.

Here is the most interesting part:

First, you should verify that you can talk to L.ROOT-SERVERS.NET using plain DNS. This will ensure that failures in the subsequent tests are meaningful.

e.g.

dig +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +nodnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39974
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f

;; Query time: 189 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:05:49 2010
;; MSG SIZE  rcvd: 492

Next we will see whether you can receive an answer that is greater than 512 bytes. This test simulates how named makes its initial queries. Most signed responses fit between 512 bytes and 1500 bytes and are returned in a single un-fragmented UDP packet. This test is designed to check this case.

e.g.

dig +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore ns . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 381
;; flags: qr aa; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 12:51:28 2010
;; MSG SIZE  rcvd: 801

If you get a response like this then your firewall passes UDP responses greater than 512 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we will test to see whether you can get a response greater than 1500 bytes. Such responses are normally fragmented, and this test will find out whether your firewall will pass fragmented UDP packets. Failure to pass such responses will force named to fall back to using queries which are likely to trigger the use of TCP, which should be avoided. Failure to pass such answers will also slow up the resolution process.

e.g.

dig +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +ignore any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57084
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 191 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:15:19 2010
;; MSG SIZE  rcvd: 1906

If you get a reponse like this then your firewall passes UDP responses greater than 1500 bytes.

If you did not get a response like this, you need to fix your firewall.

Next we need to see whether your firewall passes outbound TCP queries. Even when using EDNS, some answers will not fit into a UDP packet. Such responses require queries to be performed over TCP.

e.g.

dig +dnssec +norec +vc any . @L.ROOT-SERVERS.NET

; <<>> DiG 9.3.6-P1 <<>> +dnssec +norec +vc any . @L.ROOT-SERVERS.NET
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20036
;; flags: qr aa; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 21

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	ANY

;; ANSWER SECTION:
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100214000000 20100206230000 23763 . haTtgLwOQ9Bm2F9BRqMtAzahIuUWrjcmRjFGI5s5jGUVpjgq/MOl7wRi IJ1nLQkXThzc8hn6b3faXXIhHE/8MShzOG4wFbHwJyltx8IT9E8XP4P5 Fz9TuE3EEElNE6GZNAg8UM4r8hyv/PSM8e7offdh7pg32kfW6fgoLsHy 8yQ=
.			86400	IN	DNSKEY	256 3 8 AwEAAa1Lh++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ +++++++8
.			86400	IN	DNSKEY	257 3 8 AwEAAawBe++++++++++++++++THIS/IS/AN/INVALID/KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++8=
.			86400	IN	RRSIG	DNSKEY 8 0 86400 20100214235959 20100131000000 19324 . v2DVoP16w3dqsOooCxAb393ExF6p1t3d3qJsYPkeV96/t3HIuVLnxpbV 02Wx+BR7dwLiURASmebvEhZrR4gNqO15M5gerrzDdY0IXA0q0xVAUj/J NvkdiniXjoQYGUwjJsdfqxvD7NQPtSz4YTuOvMlVffV1F2Bc6Woid7AK JGkb24MeQlAMy/gQqcLPs6c3a9RvZEwofMul66bUswGS+YsL8x9A6Cbt 1bdyhRUNYSl7AifA4++Pu+0MLpbrxH7DLI8O9ZfCA3LsEQUOFjYA+2jJ mzgFqZAU0HvxeQyStnLF3/bf7qifRegrn6+cTKjKtUZ52/kUFiaqgT2t 9TemTg==
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.
.			518400	IN	RRSIG	NS 8 0 518400 20100214000000 20100206230000 23763 . JWEPSBVBz37WV/cvjxtlBGGLFe88ojhBM3ZZW+ZC2umpQq5lMSnE/3vO WGVWq8gOFs/mlmXttk80WxwZfUvgDXddNtqbNoNWZaGPbH9F2O+B6yDX n6jE4EcMRcjoL752uZTDMZ8WHEiEorjxsVYr1ae1MYZO5K0CqzX/qkUW 1DY=
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010020701 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100214000000 20100206230000 23763 . KA46XFSIJT3xKdvlo2av5FmeFl5R8etArvA9PLJb4JUz2jioqYTjhDbT 6L5kJQaiavMF1Lic5spulaHlCHmVy+gLetI49Nc8htnd0QPWTn/MG3do isDlv9nh6uCR6cJj5W/anIkubiLHBmO11QLwVNa1IybTgTCKHNwefxG0 i/M=

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	192.228.79.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	128.8.10.90
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	128.63.2.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
h.root-servers.net.	518400	IN	AAAA	2001:500:1::803f:235
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:3::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 380 msec
;; SERVER: 2001:500:3::42#53(2001:500:3::42)
;; WHEN: Mon Feb  8 13:18:19 2010
;; MSG SIZE  rcvd: 1906

If you did not receive a answer like this, you need to fix your firewall.

If all the above tests succeeded, then you should have no issues when all the root servers are responding with signed versions of the root zone.

]]> http://blog.dest-unreach.be/2010/02/10/dnssec-firewall-issues/feed 0 DNSSEC – Implementation http://blog.dest-unreach.be/2010/01/24/dnssec-implementation http://blog.dest-unreach.be/2010/01/24/dnssec-implementation#comments Sun, 24 Jan 2010 12:13:41 +0000 Niobos http://blog.dest-unreach.be/?p=1116 DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

Time to put things together and setup a simple DNSSEC secured zone using BIND. Instead of providing a walkthrough, I’m just going to refer to the DNSSEC HOWTO (local mirror of the PDF version) of NLnetLabs. It provides a very thorough explanation of the whole DNSSEC concept, including copy-paste examples to try out. Also, it goes more into practical details such as key rollover, the benefits of using two keys (a Zone Signing Key, or ZSK, and a Key Signing Key, KSK).

I also want to note that it’s perfectly possible to combine DNSSEC with dynamic updates. The only drawback is that the keys (at least the ZSK) must be available to the running BIND process. Depending on your security model, this might be an issue. Personally I’d argue that the BIND process has the ability to screw up your DNS-zone anyway. To enable this dynamic updates with DNSSEC, just merge this configuration in, as suggested by Garnser:

options {
 key-directory "/etc/keys";
};
]]> http://blog.dest-unreach.be/2010/01/24/dnssec-implementation/feed 0 DNSSEC – The DNSKEY and DS record http://blog.dest-unreach.be/2010/01/22/dnssec-the-dnskey-and-ds-record http://blog.dest-unreach.be/2010/01/22/dnssec-the-dnskey-and-ds-record#comments Fri, 22 Jan 2010 15:13:39 +0000 Niobos http://blog.dest-unreach.be/?p=1595 DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

To verify the digital signatures inside the RRSIG records, the client needs to have access to the corresponding public key. What better mechanism than DNS itself could be used to convey this information to the clients? Public keys are stored in DNSKEY records inside the zone. To facilitate key rollovers, new keys are added ahead of time, while old keys remain in the zone until all entries have expired in the caches.Obviously, the DNSKEY record is protected by an RRSIG, but this isn’t enough: The correctness of the DNSKEY record can be verified by the RRSIG, which can be verified by the DNSKEY! An additional mechanism to verify the DNSKEY is thus required. This is where the DS record comes in. It stores a summary of the DNSKEY in the parent zone, protected by the parents DNSKEY. This goes on in a tree-like structure, up to the root DNS zone. This root DNSKEY needs to be protected by some other means.

The following table shows the chain of protection. Every record is protected by the next row. The last row needs to be protected out-of-band. Note that the RRSIG and DNSKEY are in the same zone, while the DS is one level up.

Owner name Record type Zone
www.example.net. A example.net.
www.example.net. RRSIG example.net.
example.net. DNSKEY example.net.
example.net. DS net.
example.net. RRSIG net.
net. DNSKEY net.
net. DS .
net. RRSIG .
. DNSKEY .

DLV

As said before, this whole chain depends on the root zone being signed. At this moment, this is not the case (current plans are july 2010). So instead of a single “Secure Entry Point” (the root), there are many: one for every orphan zone (in DNSSEC-sense). To provide a temporary workaround, DLV (DNSSEC Look-aside Validation) has been invented. This is a database containing the DS records of a lot of DNSSEC-zones, thereby providing a single Secure Entry Point (SEP) for the majority of the DNSSEC world.

The record data for DNSKEY

ripe.net.        3379 IN    DNSKEY 257 3 5 (
                            AwEAAa/KVVdwmvrpdIP650gGoFqbx/W76h+APAJyxfpx
                            YIuT3AJqXy+6reUNzaTC89O6UBmFMPKFoLP9iavAcfgc
                            QnmI50XoCWRCnCF30CIIaIOMJ5ze4s8QIT0MPHDHM5l5
                            vBo87Bu6CUNn3FrmiC0LJd9fqvwvI3P4Z4GQ+xb06w3a
                            h3NOxUaqhizoDcqsFERY8QGYmiFb33cOIseYJNkufomf
                            PLkVeTC2R6CU6zNdFXbeNOqv7pTW1/jftlsH5L6mJEdk
                            71VHg4+Y2q/VuR7+s/Ju/VpVELS5ggcyjK2O0Ei5kPKg
                            m9zpOjSw4wJWhbp7PVTxX3PnvyxuRlOJs2ksdcE=
                            ) ; key id = 12319

This is a summary of RFC 4034, chapter 2.

  1. The flags: bit 7 (256) indicated this is a ZONE-key (the kind of keys used for DNSSEC). Bit 15 (1) indicates this is a Secure Entry Point
  2. Protocol: The only currently defined value is 3.
  3. Algorithm: The type of key. In this case RSA/SHA-1
  4. The key itself

The record data for DS

gov.br.            86400 IN DS 8401 5 1 (
                            5248DB0EAE4E829924F19D33B005FBC8C4606058 )

This is a summary of RFC 4034, chapter 5.

  1. The key tag
  2. Algorithm: The type of key. RSA/SHA-1 in this case
  3. Digest type: the method used to calculate the digest. In this case SHA-1
  4. The digest itself
]]> http://blog.dest-unreach.be/2010/01/22/dnssec-the-dnskey-and-ds-record/feed 0 DNSSEC – the NSEC and NSEC3 record http://blog.dest-unreach.be/2010/01/20/dnssec-the-nsec-and-nsec3-record http://blog.dest-unreach.be/2010/01/20/dnssec-the-nsec-and-nsec3-record#comments Wed, 20 Jan 2010 15:11:40 +0000 Niobos http://blog.dest-unreach.be/?p=1582 DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

While the RRSIG record allows you to verify the authenticity of returned records, there is still a gap remaining. What if the requested name does not exist? Since the DNS server replies with an empty answer section, there is nothing to sign. That’s where NSEC (or its brother NSEC3) comes into play. An NSEC record (Next SECure) states the range of names that do not exist. By signing this NSEC record by a corresponding RRSIG record, one can prove that a domainname does in fact not exist.

For every existing name, there is a corresponding NSEC record. This NSEC record states what types are available for the current name, as well as the next valid name is in the sorted zone file. This brings us to the downside of NSEC: Since the NSEC records essentially chain through the complete zone, it’s possible to do “zone walking”. While every single entry isn’t a secret, handing out the complete zone is different. To quote Paul Albitz and Cricket Liu from their DNS and BIND:

It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory.

This is where NSEC3 comes into play. The principle is exactly the same as for NSEC, but in the hashed domain. Normal NSEC looks like this:

NSEC3 looks like this. I choose an artificial hash function, normal hash values are much longer.

Because the client knows how the hashes are calculated, it can still verify the assertion.

The proof of non-existance

Let’s assume a request is made for “charlie” for the above zone. The server answers with an NXDOMAIN status, and additionally provides an NSEC record:

beta.example.net. NSEC delta.example.net. A RRSIG NSEC

This asserts that there is no valid name between “beta” and “delta”. In addition it states that the only data available for “beta” is an A, RRSIG and NSEC record. Since “charlie” sorts between “beta” and “delta”, this is a proof that “charlie” does not exist.

The NSEC3 case is similar. First the server calculates the hash for “charlie”, in this example “a10c”. It then provides the following record:

810c.example.net. NSEC 1 0 5 5A17 c73a A RRSIG

This asserts that there is no valid hash between “810c” and “c73a”. It also states the algorithm used to calculate the hash (1) as well as the used salt (5A17) and iterations (5). This allows the client to calculate for itself the hash for “charlie” and verifying that it sorts between the two given hashes in the NSEC3 record.

However, this is not enough: DNS supports a wildcard function! So in addition to proving that the required name does not exist, the servers inserts an additional NSEC(3) record, proving that there is no wildcard that matches the request.

The record data for NSEC

dodo.ripe.net.        7147 IN    NSEC dog.ripe.net. A RRSIG NSEC

This is a summary of RFC 4034, chapter 4.

  1. The next owner name: All names between the owner name and this next domain name don’t exist.
  2. The type bitmap: List all types of data for the owner name. Other types don’t exist.

The record data for NSEC3

4mm2csfll0cb2su9pdbfkfapnc15f1tq.org. 900 IN NSEC3 1 1 1 D399EAAB
                                             4MS4SFN10P02UCOG4M1AMDC41CAO1ITQ A RRSI

This is a summary of RFC 5155, chapter 3.

  1. The hash algorithm used for the hash calculation (in this case SHA1)
  2. Flags: The only defined flag at this moment is the Opt-Out flag.
  3. Iterations: The hash-function can be iterated over. This increases calculation time and thus its cryptographic strength.
  4. Salt: An additional value used in the hash calculation. This increases the cryptographic strength.
  5. Next hashed owner name: The next item in the chain. All domain names with hashes between the owner name and this value don’t exist.
  6. The type bitmap: List all types of data for the (hashed) owner name. Other types don’t exist.
]]> http://blog.dest-unreach.be/2010/01/20/dnssec-the-nsec-and-nsec3-record/feed 0 DNSSEC – The RRSIG record http://blog.dest-unreach.be/2010/01/17/dnssec-the-rrsig-record http://blog.dest-unreach.be/2010/01/17/dnssec-the-rrsig-record#comments Sun, 17 Jan 2010 09:34:38 +0000 Niobos http://blog.dest-unreach.be/?p=1572 DNSSEC, short for DNS security, provides a security extension to the all important DNS system. A nice intro can be found on wikipedia. This is a part of a series on DNSSEC:

  1. The RRSIG record
  2. The NSEC and NSEC3 record
  3. The DNSKEY and DS record
  4. Implementation

The RRSIG record is the basic building block of DNSSEC. It accompanies every Resource Record Set (RRset) and provides a digital signature over the provided data. This record is only supplied if the client indicates that it understands DNSSEC. A client does so by setting the DO (DNSSEC OK) flag (part of EDNS). If the server adds this record, it can be used to prove that the received data is authentic and hasn’t been tampered with (or prove the opposite). If, on the other hand, the response doesn’t contain RRSIG records, there are two possibilities. Probably the zone just doesn’t use DNSSEC, but it’s also possible that the response has been tampered with and had its RRSIG removed. Unless you have some prior knowledge, it’s impossible to know which case you’re in. This should be solved once the root-zone becomes signed in July 2010.

The record data

ripe.net.        165001 IN A 193.0.6.139
ripe.net.        165001 IN RRSIG    A 5 2 172800 20100203123710 (
                         20100104123710 53562 ripe.net.
                         f9f11o1gl54uVZKlEGYm7hX9HZR5Hh4gYaWi9EuImPx7
                         pBD0OGluG48vMmXDIoPmu0iWi6Y9yhqKm3SsPKHUuOHB
                         +YFD+5ACXh6X8eqNzYo3vw/mik2bRNFB1nyE4gATAgaw
                         hJZy8o2BB/QgX7QE3V0hxN1Qvdy6roldSEcAJq7HsJmz
                         aR2T7F6GLaon6qOH9tLpNWAD )

This is a summary of RFC 4034, chapter 3.

  1. The type covered field: Which type of data is covered by this signature. In this case, the preceding A-record.
  2. The algorithm field: Indicates the algorithm used to calculate the signature. In this case 5 (RSA/SHA1).
  3. The labels field: Indicates how many labels the original ownername has. In this case 2 (i.e. ripe.net). This field serves to indicate if the RRSIG is synthesized from a wildcard record.
  4. The original TTL field: The TTL of the record on the authoritative name server. In this case 172800 seconds.
  5. Signature expiration and inception: Indicated from when till when this signature is valid. In this case from the 4th of January 2010 till roughly a month later.
  6. The key tag field: The key-id of the key used to produce this signature.
  7. The signer’s name field: The ownername of the DNSKEY record that contains the key used to produce this signature.
  8. The signature field: The signature itself. It secures: the records identified by its name and “type covered” field, as well as all previous fields of the RRSIG record itself.
]]> http://blog.dest-unreach.be/2010/01/17/dnssec-the-rrsig-record/feed 0