DNS
DS records published for spoofedpacket.net
Nov 1st
The DS records for spoofedpacket.net are now published in the .net zone, making DNSSEC live for anyone who has a security-aware resolver with the signed root configured.
DNSViz shows some nice graphs of the delegation chain.
spoofedpacket.net signed (again)
Mar 2nd
For real this time
My previous attempts at signing spoofedpacket.net fell into disrepair and the zone expired soon afterwards, since I was doing everything manually. However, the whole lot is automatically managed by OpenDNSSEC now, apart from the KSK rollover of course. But there are some clever things you can do to fix that, with the DelegationSignerSubmitCommand.
So here’s the current trust anchor for spoofedpacket.net in DNSKEY format, and in
DS format.
Unfortunately, joker (my registrar) don’t appear to be accepting DS records at this point. So neither of the above are in the wider DNS even though .net is now signed. However, I did register mechazawa.net with godaddy, who are currently accepting DS records through their somewhat clunky interface.
Stub/local zones and DNSSEC in Unbound
Dec 17th
I have a couple of local DNS zones on my home network that are served from a BIND running on the same machine as my Unbound resolver. It listens on a different address, so Unbound, being the default resolver for the network, is configured to forward all requests for that particular zone to BIND.
This has worked fine, until I enabled the signed root in Unbound. Suddenly, the entire local zone was being treated as bogus, since, obviously, it appears nowhere in the root. This was manifested as SERVFAIL responses and general badness on the network – including my NAS losing it’s DHCP address whilst I was watching an episode of Full Metal Alchemist: Brotherhood….not good.
After scanning down through the sample unbound.conf, a simple solution presented itself:
domain-insecure: "localdomain"
This tells unbound to put up with the fact that a particular domain may be bogus/insecure, and life goes on. It could be argued that it’s not a good idea to let some domains be treated differently than others when it comes to DNSSEC, but I think it’s good that the developers of Unbound had the presence of mind to include a solution to this particular corner-case.
Switching to NSD
Mar 7th
Whilst BIND is a nameserver I use nearly every day, it’s somewhat large and unwieldy being a reference implementation of the DNS spec.
Where possible, I always like to split out resolving and authoritative functionality into two seperate pieces of software. Unbound does a great job in the latter role – also from the authors of NSD, NLnetlabs – so I thought I’d give NSD a go on ns.spoofedpacket.net.
This machine serves only handful of zones, so it’s easy enough to migrate. The transition is made even simpler since NSD supports the old bind zonefile format out of the box. I decided to install NSD from source, following the tried and tested method:
cd /usr/local/src wget http://www.nlnetlabs.nl/downloads/nsd/nsd-3.2.4.tar.gz tar zxvf nsd-3.2.4.tar.gz cd nsd-3.2.4 ./configure make make install
The dependencies are very few, it should compile without much fuss on nearly any modern *nix system.
By default, all configuration files and zones go into /etc/nsd. There is also an nsd.conf.sample that you can use as a base config. The config file is extremely simple, for a basic setup you only need to look at the server: and the n-number of zone: sections. In the server: section, I only changed the location of the zone files:
zonesdir: "/etc/nsd/zones"
At this point, it’s always good practice to organise your zonefiles into directories according to their roles. Here is what I have:
/etc/nsd/zones/master /etc/nsd/zones/slave (nothing here yet) /etc/nsd/zones/master/forward /etc/nsd/zones/master/reverse /etc/nsd/zones/master/reverse/IPv4 /etc/nsd/zones/master/reverse/IPv6
If you have an old BIND install that you are replacing, it is just a simple matter of copying/moving the existing zonefiles to their new locations. The zones can then be configured in nsd.conf as follows:
# spoofedpacket.net
zone:
name: "spoofedpacket.net"
zonefile: "master/forward/spoofedpacket.net.zone"
notify: 193.1.193.194 NOKEY
provide-xfr: 193.1.193.194 NOKEY
name and zonefile are pretty self explanatory, just remember that the path to your zonefile is always prefixed with the zonesdir statement from earlier on. notify lists all the nameservers you wish to send DNS notifies to when a zone is updated. provide-xfr controls who can carry out zone transfers (AFXR) from your nameserver. The NOKEY statement tells NSD that no cryptographic keys are required to authenticate the notifies or zone transfers between your nameserver and the secondary nameservers.
Once you’ve finished editing nsd.conf, you must now compile your zonefiles into the binary format that NSD understands. This is one of the main reasons for NSDs speed and low footprint:
nsdc rebuild nsdc reload
Verify that nsd is running and serving zones:
pgrep -lf nsd dig @ns.spoofedpacket.net www.spoofedpacket.net
spoofedpacket.net signed
Dec 1st
I recently signed spoofedpacket.net, here’s the DS sets:
spoofedpacket.net. IN DS 15871 5 1 6D6B3C370091ECF38D81B2D91B54C7B2EB6D47E6 spoofedpacket.net. IN DS 15871 5 2 41D36F7DEC5827F650E772DE1DA33A219B3B994757DDF763830EBC12 E2DCEC80
And the keysets:
spoofedpacket.net 604800 IN DNSKEY 257 3 5 (
AwEAAa1qyDcvEEsXZYvzI5TwlJks8pK95OSE
RjMtg0aN/cBfpNeyyYwX1O5zQy1G13qklxYR
CbPHbbeZkxMxfVxc3pUSDOqYtu6IBhhPTv9Z
Gwnjn6CRBdKVrkdMI5ZPJ3uwvMj9yk6a9jjg
tUZZfIRkbURa/Q75AaqB8ihQN7pU5N9Tui0i
V3eoKZrVfc5mUDATnggSw/Pk7blHKn8OWwEJ
b7Q5Uulg4fmHYSxX2sTzt5kgZxWAVbaZ5IWn
XwMJkUN7kM9Lz04exn4JmpeMpfAo3+tyDC1F
LLJVPAk4KmhDKPhiY1y9yeZxLiloYh8KvG4b
W18D465/RQRkoLufF+/6htk=
) ; key id = 15871