Enabling DNSSEC for farnz.org.uk using BIND 9.9

DNSSEC with BIND 9.9

I've been pleasantly surprised by this; BIND 9.9 has made enabling DNSSEC for a zone really easy. The only problem I hit along the way is that the defaults for dnssec-keygen aren't as secure as I'd like.

Note that this is not a howto - it's a guide to the steps I took.

Prerequisites

• Access to the BIND ARM for the version of BIND you're running. I followed the instructions in chapter 4 of the ARM to do this.
• You need a recent BIND 9 - I'm using 9.9, although the functionality has been present since 9.7.
• Your zones must be working fine without DNSSEC; all that this process does is teach BIND to sign your zone for you.
• You need access to your nameserver's configuration files, and space on disk to store DNSSEC keys.

Getting going

First, teach BIND to automatically sign your zone for you, by changing the zone configuration. I started with:

    zone "farnz.org.uk."
    {
    type master;
    file "/var/named/forward/farnz.org.uk";
    };
  

and added three lines to get:

    zone "farnz.org.uk."
    {
    type master;
    file "/var/named/forward/farnz.org.uk";
    key-directory "/var/named/dnssec/farnz.org.uk";
    auto-dnssec maintain;
    inline-signing yes;
    };
  

Reload the configuration rndc reconfig.

Create the key directory - in my case /var/named/dnssec/farnz.org.uk, and make it accessible to named. You will put keys in here, which will cause BIND to take your existing unsigned zone and maintain a signed copy for you.

Create your key signing keys (KSKs). I created two - one currently in use with dnssec-keygen -a 8 -b 2048 -fk -K /var/named/dnssec/farnz.org.uk farnz.org.uk, and one that's published but not in use created with dnssec-keygen -a 8 -b 2048 -fk -K -A none /var/named/dnssec/farnz.org.uk farnz.org.uk. The idea here is that the one that's published but not in use is signed with the KSK that's in use; when I roll over my KSK, anyone who's cached the old KSK will be able to verify the new KSK. There's thus no need to delay when rolling over the KSK - cached old versions are not a problem.

Create a zone signing key dnssec-keygen -a 8 -b 1024 -K /var/named/dnssec/farnz.org.uk farnz.org.uk.

Tell BIND to sign the zone rndc sign farnz.org.uk.

If you get this far, you should have BIND automatically signing your zone. You now need to obtain a DS record for your active KSK dnssec-dsfromkey -2 Kfarnz.org.uk.+008+52165.key changing the key name accordingly. Send this DS record to your parent zone - in my case, as the domain is hosted by AAISP, I added the DS record to their DNS management interface, and had them send it to Nominet.

At this point, your domain is signed and traceable to the root key - you can test it via DNSViz and DNSSEC Analyzer.

Rolling over the ZSK

Rolling over the ZSK should be a quick and simple process, as you don't need to communicate with other server operators. There are three steps:

1. Create a new ZSK: dnssec-keygen -a 8 -b 1024 -K /var/named/dnssec/farnz.org.uk farnz.org.uk
2. Mark the old ZSK for inactivation and deletion in the future: dnssec-settime -I+1d -D+7d Kfarnz.org.uk.+008+12156.key
3. Tell BIND to catch up: rndc sign farnz.org.uk

The marks on the old ZSK do not tell BIND to delete it from disk; instead, when the old ZSK becomes inactive, it will no longer be used to sign RRSETs being returned to clients (so the time to inactivation should be longer than the ZSK's TTL), and when it's deleted, it will no longer be published in DNS at all.

Rolling over the KSK

This is more involved, because it needs co-operation with your parent zone:

1. Make your not-in-use KSK active: dnssec-settime -A now /var/named/dnssec/Kfarnz.org.uk.+008+43885.key
2. Tell BIND to catch up: rndc sign farnz.org.uk
3. Get the DS record for your newly activated KSK, and send it to your parent zone: dnssec-dsfromkey -2 /var/named/dnssec/Kfarnz.org.uk.+008+43885.key
4. Wait for your parent zone to be publishing the new DS record.
5. Inactivate and delete the old KSK: dnssec-settime -I+7d -D+28d Kfarnz.org.uk.+008+52165.key
6. Tell BIND to catch up: rndc sign farnz.org.uk

Scheduling a ZSK roll over

It's also possible to schedule a ZSK roll over in advance:

1. Set an inactivation and deletion date well in the future for the key you're rolling over: dnssec-settime -I+30d -D+40d Kfarnz.org.uk.+008+12156.key
2. Create a successor key with a sensible prepublication interval: dnssec-keygen -i7d -S Kfarnz.org.uk.+008+12156.key
3. Tell BIND to catch up: rndc sign farnz.org.uk

Note that you can do this with multiple keys, including keys that aren't yet in use - you can thus schedule a year's worth of monthly key changes at a time if you so desire.

My new OpenPGP key setup

I've been a user of OpenPGP for some time, but I've been using an old 1024 bit long DSA key, which I've now revoked. Instead, I'm moving to a more complex key setup, based around a master key (which is the one I will get people to sign in future), and regularly expiring subkeys.

This enables me to use the same keys at home and at work (tying the two identities together), although it will lead to a transition where my key is untrusted. I hope to deal with enough geeks over time to rectify this. For now, though, if you see stuff from me signed with key ID F2E084D6 or one of its subkeys, don't panic - it's my new key.

Fixing the City pension fees problem

I read this Guardian article on City fees for pensions (an article which explains why I don't currently have a decent pensions), and a simple fix occurred to me: insist that the fees are charged only on growth, not on capital invested, and that fees are quoted as a %age of the expected growth as well as any absolute amounts.

After all, the reason you pay into one of these funds is that the City promises growth above and beyond keeping your money in the mattress. By restricting the fees to a proportion of the growth obtained over the time period the fees apply to, I would expect two beneficial side effects:

1. The management fees quoted become easier to understand in comparison to other financial options like savings accounts - if you are quoted as losing 50% of the growth or £50 (whichever is higher) to management fees, and the anticipated growth rate is 4%, it's easier to see that this is likely to be equivalent to 2% interest on a bank account, but has a worse downside in the event that the growth in value never materialises.
2. There's a built-in penalty for the City if it doesn't meet its promises; if the fees are 1% of capital managed, and you invest £5,000 in the expectation of 10% growth, they collect £55 if they achieve expectations (leaving you with £5,445); they also collect £40 if they lose £1,000 of your money (leaving you with just £3,960). If, on the other hand, fees are limited to the growth they achieve, then they get nothing if they don't achieve any growth (or make a loss with your money).

It's also my gut feeling that the City would have to try harder for its money if people understood just how high the fees they want are; 1% of capital managed doesn't sound like a huge amount. Taking my example earlier, they managed £500 of growth, so would need 11% fees to make the same money; if they average 5% growth, they'd need 22% fees to make the same income; at 1% growth, they'd need to charge fees of more than 100% of growth to make the same money they make from 1% of capital managed, making it obvious that their fees exceed the gain from investing with them.

You could go further - you could choose to insist that fees are capped to the growth obtained, but I suspect that would eliminate high-gain, high-risk investments. I would, however, choose to insist that any investment where fees can exceed the total gain in value from the investment is clearly labelled with an FSA "be aware that you can lose your entire investment to fees, even if the fund makes a profit" warning, explaining the risks clearly. With any luck, the requirement to label high-fee investments as high-risk would encourage the City to mostly offer investments where the fees are capped to growth, so that the City suffers when you make a loss.

Making car insurance affordable

Motor insurance prices have been in the news recently, as the cost of legally required third party insurance has been rising recently. The claim made by the industry is that injury claims are the biggest cause.

It seems to me that there's a pair of simple fixes, which could be funded by a further tax on motor insurance.

First, you cannot claim for injury after an accident unless the accident was reported to the police within 24 hours of the accident; if you are incapacitated by the accident, this time is extended until 24 hours after you become medically capable of reporting the accident. This ties into the requirement to report injury accidents to the police that already exists (Road Traffic Act section 170), and just has the injured party also required to report to the police if they might choose to claim later. In theory, therefore, this is no burden on the authorities, as they are dealing with these reports anyway.

Additionally, an injury claim is only valid if two things apply:

1. You make arrangements to see an NHS doctor within 14 days of the accident - being taken to hospital by emergency ambulance counts here, as does making an appointment to see your GP.
   
2. An NHS doctor, at risk of losing their licence to practice if found to be lying, agrees that your injury is such that compensation is appropriate.
   

In other words, make it cheap to dismiss injury claims that aren't backed by medical evidence. Put the onus on claimants to seek medical advice - if you really think you're injured, you should be seeing a GP anyway, and we should have mechanisms in place to deal with you if you're abusing NHS services (a topic for another rant).

On the cost of regulations

I've been pointed at the Telegraph article on Steve Hilton's advice to the UK government, and one thing stands out in the article; Mr Hilton is able to count the cost of regulation, but not the benefits.

It's trivially obvious that (to take one of Mr Hilton's examples) consumer rights laws cost some businesses money; what's not discussed is the benefits of those laws, and the cost to society of not having them. Let me lead you through an example, using an expensive consumer product that many people have: a television.

You can buy televisions at many different prices, each with different features; just looking at 24" screens, I can find a cheap TV at £129, or I can spend over £1,000 on a similar looking set that's the same physical size. It's when I start to look at the differences between the sets that the sheer diversity of product becomes clear; my cheap set has one HDMI input, and a DVB-T tuner. It must be powered from a 230V nominal 50Hz AC source (e.g. household mains). My expensive set has multiple HDMI inputs, a DVB-T2 tuner as well as the DVB-T tuner, the ability to be powered directly from a car "cigarette lighter" socket (e.g. for in-caravan use) as well as from AC between 75V and 250V nominal, at frequencies between 50Hz and 400Hz nominal (making it suitable for powering from a typical luxury yacht power socket). It has the ability to record TV programmes to an attached USB HDD, and to play them back later; generally, it is of much higher specification than the cheap set.

So far, this sounds reasonable; the expensive set is a much more desirable piece of equipment. Yes, I'd have to pay more for it, but I'll get what I'm paying for. Now imagine removing consumer rights laws - let's take the law that says that goods must be fit for the purpose they are sold for. Without that law, a dishonest trader could buy the £129 TV, put appropriate connectors on the case, and sell the TV for (say) £800. They'd make a hefty profit on every set they've sold, and because consumer rights laws don't exist, nothing stops them conning a few customers, changing their trading name (so all the noise about how crooked they are doesn't impact sales), and continuing to rip people off.

Who gains in this situation, and who loses? Obviously, the dishonest trader gains. The manufacturer of the cheap TV set gains. Consumers who get ripped off lose. Less obviously, honest traders lose out; because I can't be confident that a set is genuinely what it's claimed to be, I am less likely to buy an expensive set that does everything I want, preferring to buy a cheaper set, and easier-to-verify adapters to get the added functionality.

Worse, if you say that I should rely on well-written contracts to protect me, you get into a situation where every purchase I make is slowed down, as I get the retailer to read, analyse, and eventually agree to the contract terms I insist on to make the sale. The costs to all retailers and consumers of having to deal with individual contracts, each with their own quirks are high; the benefit of consumer rights laws is that we have a baseline that the retailer cannot attempt to wriggle out of that I, as a consumer, am happy to accept. Businesses thus only need spend the costs of understanding the laws once; consumers accept that they can trust businesses, and rely on the law protecting them from the few bad apples. Neither side pays day-in, day-out for the costs of protecting themselves against the rogues in the market - instead, the legal apparatus puts as much of that cost as possible on the rogues. Further, the nature of regulation means that the net cost to legitimate businesses of consumer protection is lower than it would be if each transaction attempted to include the terms required in an individual contract.

In short, even regulations that cost money in the short term don't necessarily cost money in the long run; often, the regulations exist so that honest businesses can survive in the market, even in the presence of crooks. The trouble is that the cost of regulation is obvious up-front; the benefits are not only sometimes taken for granted, but often are spread across all of society.

IPv4 run-out has started - prepare for IPv6

So, checking technical blogs and tweets this morning, I learn that APNIC have triggered IANA IPv4 exhaustion. What does this mean for the non-technical user? Well, in the short term, nothing - RIRs like RIPE and ARIN still have stocks of IPv4.

In the medium term, it means you have to move to IPv6 soon. Given the rate at which IANA ran out, you have about a year from now before IPv4 is simply unavailable to you, and services will have to be IPv6 enabled or else. If you're buying network-enabled kit that you expect to keep using in 12 months time, make sure it's IPv6 ready. If it's not, talk to your salesman, and tell them that the reason you're delaying the purchase is that you want IPv6 support.

As a product developer, I'm not seeing any pressure from the field to get IPv6 into our Internet enabled devices; it's simply not something that impinges on people who buy equipment. You need to change this now. Within the lifetime of anything you buy today, IPv4 will run out, and you will need your equipment to be IPv6 enabled if it's going to continue working.

Please, put pressure on sales teams to IPv6 enable everything - it won't happen until you do. If you don't, don't be surprised when you're rebuying everything in a year or two, simply because IPv4-only kit is no longer usable for the task you bought it for.

Why allocating /48s for end users in IPv6 is a good idea.

There are people out there already worrying that assigning /48s to end users in IPv6 is going to cause problems in the long term, matching the existing IPv4 problems with address shortages. I'm going to try and present a few ways to understand just why it's not going to happen that way.

Firstly, we'll need to think about the world population. Current figures show that we're at around 7 billion people. Taking the worst-case model the UN is prepared to consider, we're unlikely to reach more than 35 billion people worldwide before 2100. Against that, we have assigned a single /3 for unicast, and kept 5 /3 blocks in reserve.

A quick bit of maths shows us that we have 2⁴⁵ /48s to assign, before we have to use up more of the reserved address space. This is (roughly) 35,000 billion blocks to use. We have already determined that we're not going to have more than 35 billion people any time soon; so, let's assume that there are 3,500 billion people on Earth, or 500 times the current population. That's still enough /48s for each person to use an average of 10. So, one /48 at home (65,000 individual networks, of which a "typical" home might have two WiFi networks, one "server" network and a wired network). One /48 in the office (again, 65,000 individual networks in the office). Three /48s on the mobile network (one for each handset, plus one for your mobile broadband dongle). We're still only using 5 of the 10 we can allow after a 500 times population growth. Assume that ISP overheads (running routers and the like) cost a typical user another /48, and we're still within a safety margin.

Note also that we haven't yet permitted the use of the reserved /3s. If we have population growth well beyond that which we currently believe the planet can sustain, and we use more blocks that I have considered (I've assumed one connection at work, three mobile connections, one at home), we still have room to expand into. And it gets better: if the UN's worst-case projection is vaguely accurate, and we stabilise at under 70 billion people, we can each fill 50 /48s before we have to use some of the reserves.

In short, big numbers are hard. It's all too easy to see that the IPv6 address is only 96 bits longer than the IPv4 address, but hard to get a handle on just how much extra space that represents.