Long-term Memory » DNS 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 World IPv6 day – lessons learned http://blog.dest-unreach.be/2011/06/14/world-ipv6-day-lessons-learned http://blog.dest-unreach.be/2011/06/14/world-ipv6-day-lessons-learned#comments Tue, 14 Jun 2011 12:22:26 +0000 Niobos http://blog.dest-unreach.be/?p=2032 Together with most of the internet, we tested IPv6 on World IPv6 day last week. I won’t go into details on what IPv6 is and why it’s important. Although IPv6 has been tested intensely in isolated networks, this is the first time it was tested on such a large scale. Technically, the participants would just add AAAA-records for their websites to DNS. This small change causes a huge effect. Since most browsers are configured to prefer IPv6 AAAA-records over IPv4 A-records, this causes all IPv6-connected users to suddenly connect over IPv6 instead of IPv4.

For the most part, this major changeover happened without as much of a hitch. In fact, if I hadn’t known it was World IPv6 day, I wouldn’t have noticed anything. But I’m not a normal web-user, so I did notice some issues.

Where it did went wrong

After some troubleshooting, they all boiled down to a single cause of oversight. They were not bugs or issues with IPv6 per se, just some “expected behavior” that we didn’t anticipate: IPv4-only VPNs.

Most servers in our datacenter are not publicly accessible; none of them are manageable over the public internet. In order to connect to them, you need a VPN connection. This serves multiple purposes: it secures all communication between client and server (so even plain-text http can be used securely to manage servers), it limits the number of users with access and most importantly (in the IPv4 world) it allows us to use RFC1918 addresses internally and still get the routing to work out. Technically it behaves an an extra (virtual) network card with a (virtual) cable connected straight to the datacenter. Additionally, some routes are configured automatically on the client to make sure traffic to the servers is sent over this “cable”.

We use two kinds of VPN-connections, but none of them was IPv6 enabled (i.e. could carry IPv6 data through the tunnel). Since by default client software prefers IPv6 connections, this caused the IPv6-internet connection to be preferred above the IPv4-VPN connection. Obviously, the firewall at the datacenter didn’t agree and refused access.

The solution was fairly obvious to state (enable IPv6 through the tunnels) but difficult to implement. In fact, I have not been able to get it to work well enough to install it on someone else’s computer.

The attempts

IPsec in transport mode

The “natural” solution would be to secure the IPv6 packets with IPsec, preferably in transport mode, between the client and the firewall. Since there are no NAT-issues, tunnel mode is not required.

network diagram: server (2001:db8:0:1::1) — (2001:db8:0:1::2) Firewall (2001:db8:1:0::2) — (2001:db8:1:1::3) client

However, I was not able to get this to work, even in manual keying mode (i.e. without ISAKMP). I couldn’t get setkey to accept the src-dst parameter in the SPD:

# setkey -c
spdadd 2001:db8:0:1::1 2001:db8:1:1::3 any -P fwd ipsec esp/transport/2001:db8:1:0:2-2001:db8:1:1::3/require;
^D
# setkey -DP
2001:db8:0:1::1[any] 2001:db8:1:1::3[any] any
 fwd prio def ipsec
 esp/transport//require
 created: Jun 14 12:13:53 2011  lastused:                    
 lifetime: 0(s) validtime: 0(s)
 spid=1641 seq=1 pid=10485
 refcnt=1

This seems to be a Linux issue (Ubuntu 10.04 LTS with kernel 2.6.32-28-generic and ipsec-tools 0.7.1), since this does work on MacOSX (10.6.7).

IPsec tunnel mode

Since I’m not entirely sure that what I tried above (transport mode) is even supposed to work, I also tried tunnel mode. This worked, but is a pain to configure. I only tried manual keying, but using racoon to do username/password authentication will be even harder to explain to users…

The Mac built-in VPN client only supports “Cisco IPsec“. This uses the mode configuration stage to communicate the set of “networks” to tunnel (i.e. the SPD). However, according to racoon.conf man-page, I can only push IPv4 networks in the split_network directive.

OpenVPN with tun driver

According to the OpenVPN FAQ, IPv6 is only supported if the underlying TUN-driver supports it. The tuntaposx-page does not mention IPv6 at all and hasn’t been updated for almost 2 years, so this seems unlikely to work.

Also, OpenVPN does not provide configuration directives to push IPv6 routes over from server to client.

OpenVPN with tap driver

Even when using the TAP-driver and router advertisements, MacOSX does not seem to like enabling IPv6… Even after manually enabling it, MacOSX still doesn’t pick up its SLAAC address:

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 open (pid 3847)

# ip6config start-v6 tap0
Starting IPv6 on tap0.

# sleep 60 # Wait for Router advertisement to show up

# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 ether 7e:95:80:00:90:0e
 inet 192.0.2.10 netmask 0xffffff00 broadcast 10.90.9.255
 inet6 fe80::7c95:80ff:fe00:900e%tap0 prefixlen 64 tentative scopeid 0xa
 open (pid 3847)

And this still doesn’t allow me to push IPv6 routes to the clients upon connecting.

The conclusion

IPv6 is very stable and capable, but there are certain network-issues where there is still some work to do. If you happen to know a VPN-solution which supports IPv6 and works on Windows, linux and Mac, please let me know!

Edit: I worked out my own solution.

]]> http://blog.dest-unreach.be/2011/06/14/world-ipv6-day-lessons-learned/feed 3 Using nsupdate in dd-wrt http://blog.dest-unreach.be/2010/12/06/using-nsupdate-in-dd-wrt http://blog.dest-unreach.be/2010/12/06/using-nsupdate-in-dd-wrt#comments Mon, 06 Dec 2010 18:17:06 +0000 Niobos http://blog.dest-unreach.be/?p=1954 dd-wrt has built-in support for a whole list of Dynamic DNS services. Unfortunately, they only support HTTP-based services. I use a standard RFC2136 DNS update. Here’s how to add nsupdate support to dd-wrt.

Installing

I again used the openwrt modules, nsupdate is contained within bind-client. There are, however, several dependencies:

  • libbind9.so.40.0.3, libdns.so.43.0.0, libisc.so.41.1.0, libisccc.so.40.0.0, libisccfg.so.40.0.3, liblwres.so.40.0.0 (and symlinks) from bind-libs
  • libcrypto.so.0.9.8 from libopenssl

These are some serious libraries, takeing up 2.7MB of free space…

Configuring

I tried to use SIG(0), but that failed. nsupdate complains about a missing symbol ‘flockfile’. So I settled for TSIG authentication. Since this is a post about dd-wrt, I’ll assume the sever is already set up and tested (this will guide you through if it’s not), so I’ll go straight to the config files:

/jffs/etc/ddns.key:

fqdn.of.key. 0huPr3nqFnxUETlrM/VxGg==

/jffs/etc/config/ddns-update.wanup:

#!/bin/sh

# wanup scripts seem to run without LD_LIBRARY_PATH set
export LD_LIBRARY_PATH='/lib:/usr/lib:/jffs/lib:/jffs/usr/lib:/jffs/usr/local/lib:/mmc/lib:/mmc/usr/lib:/opt/lib:/opt/usr/lib'

# wanup scripts have the IPLOCAL variable set, but cron does not
if [ -z "$IPLOCAL" ]; then
 IPLOCAL=`ip addr sh dev ppp0 | grep 'inet ' | cut '-d ' -f6`
fi

sleep 30 # wait for IPv6, DNS, … to stabilize

echo -e "server ddns.master.server.fqdn\nkey `cat /jffs/etc/ddns.key`\n
update delete fqdn.to.set A\nupdate delete fqdn.te.set TXT\n
update add fqdn.to.set 300 A $IPLOCAL\nupdate add fqdn.to.set 300 TXT `date "+%Y-%m-%d_%H:%M:%S"`\n
send" | /jffs/bin/nsupdate

I cut that last echo-line into pieces for readability, make sure that it’s one single line (from echo all the way to nsupdate).

I added the following line to the Additional cron jobs on the webinterface. Contrary to the dd-wrt wiki page, /jffs/etc/crontab does not seem to work. This will run the ddns-update script every hour, at 5 minutes past the hour:

5 * * * *  root  /jffs/etc/config/ddns-update.wanup
]]> http://blog.dest-unreach.be/2010/12/06/using-nsupdate-in-dd-wrt/feed 0 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 Secure dynamic DNS updates http://blog.dest-unreach.be/2009/04/27/secure-dynamic-dns-updates http://blog.dest-unreach.be/2009/04/27/secure-dynamic-dns-updates#comments Mon, 27 Apr 2009 15:54:52 +0000 Niobos http://blog.dest-unreach.be/?p=1106 When hosts have a dynamic IP, it’s very convenient to have its DNS-name follow that dynamic IP. There are several services on the net that do this. However, the regular DNS already provides this feature. The nsupdate tool (comes with BIND) allows you to send an update to the DNS servers. By default, a DNS server does not allow updates for security reasons.

To keep the whole world from updating your zone, there are several possibilities to restrict who can update what. The easiest to setup is an IP restriction: specify from which IPs updates are to be accepted. In my setup, however, I’d like the host to update its own record. Since the host’s IP is dynamic, this is not an option.

The other way to limit updates is by using cryptography: only people knowing the secret can send updates. This comes in two variants: TSIG and SIG(0). This site goes more into the details, but here are the basics.

$ dnssec-keygen -a RSASHA1 -b 768 -k -n HOST keyid.example.net.

Note that the keyid should be inside your zone! This generates two files, a .key and a .private file. The key should be added to the zone; the private file should be kept secret (obviously).

Next, configure what the key can do inside the named.conf:

zone "example.net" {
    type master;
    file "pri/example.net";
    update-policy {
        grant keyid.example.net. name specific.example.net. A;
        grant otherkeyid.example.net. subdomain example.net. ANY;
        grant * self * A TXT;  // allow any key to update its own A and TXT records
    };
};

You can test the update with:

$ nsupdate -k /path/to/private/key/Kkeyid.example.net.+005+29297.key
> server ns.example.net
> update add test.example.net. 300 A 127.0.0.1
> send
> quit
$ dig @ns.example.net -t A test.example.net

Don’t try to check the raw zone-file. The new record will not be in there (yet). If you really want the zone-file to be updated (e.g. if you want to edit it), you need to (temporarily) disable dynamic updates:

# rndc freeze example.net           # disable updates
# vim /etc/bind/pri/example.net     # remember to update the serial
# rndc reload example.net
# rndc thaw example.net             # enable updates

Since Bind now receives updates through DNS, be sure to check the permissions on your zone-files: bind should be allowed to write to them!

]]> http://blog.dest-unreach.be/2009/04/27/secure-dynamic-dns-updates/feed 1