1

In a non-professional capacity, I look after the DNS of some 18 domains: mostly personal/vanity domains for immediate family. The whole shebang is outsourced to an inexpensive managed hosting provider who have a web interface through which I manage the zones.

These domains are so unimportant that an attack targeted at them seems much less likely than a general compromise of my provider's systems, at which point the records of all their customers might be changed to misdirect traffic (perhaps with extremely long TTLs). DNSSEC could mitigate such an attack, but only if the zones' private keys are not held by the hosting provider.

So, I wonder: how can one keep DNSSEC private keys offline yet still transfer signed zones to an outsourced DNS host?

The most obvious answer (to me, at least) is to run one's own shadow/hidden master (from which the provider can slave) and then copy offline-signed zonefiles to the master as required.

The problem is that the only machine I (want to*) control is my personal laptop, which usually connects from a typical home ADSL (i.e. behind NAT over a dynamically-assigned IP address). Having them slave from that (e.g. with a very long Expiry time on the zone for periods when my laptop is offline/unavailable) would not only require a dynamic DNS record from which they can slave (if indeed they can slave from a named host rather than an explicit IP address), but would also involve me running a DNS server on my laptop and opening both it and my home network up to the incoming zone transfer requests: not ideal.

I would prefer a much more push-oriented design, whereby my laptop initiates transfer of offline-signed zonefiles/updates to the provider.

I looked into whether nsupdate could fit the bill: documentation is a little sketchy, but my testing (with BIND 9.7) suggests it can indeed update DNSSEC zones, but only where the server holds the keys to perform the zone signing; I have not found a way to have it take an update including the relevant RRSIG/NSEC/etc. records and have the server accept them. Is this a supported use-case?

If not, I suspect the only solutions which could fit the bill will involve non-DNS-based transfer of the zone updates and would welcome recommendations that are supported by (hopefully inexpensive) hosting providers: SFTP/SCP? rsync? RDBMS replication? Proprietary API?

Finally, what would be the practical implications of such a setup? Key rotation is jumping out at me as being an obvious difficulty, especially if my laptop is offline for extended periods. But the zones are extremely stable, so perhaps I could get away with long-lived ZSKs**...?


* Whilst I could run a shadow/hidden master on e.g. an outsourced VPS, I dislike the overhead of having to secure / manage / monitor / maintain yet another system; not to mention the additional financial costs of so doing.

** Okay, this would enable a determined attacker to replay expired records—but the risk and impact of such are both tolerable in the case of these domains.

1 Answer 1

2

Your problem is not so much key rotation, as RRSIG expiry.

Keys typically have lifetimes measured in the 6 month to 3 year timescale, and there's a growing school of thought that says you shouldn't even roll your keys at all.

However to avoid replay attacks you do need to re-sign all of your records on a regular basis, and the RRSIG validity is commonly of the period of 1 to 2 weeks.

If you signed the zone yourself and transferred it to a host you would need to do that before every RRSIG expiry event, at the same time taking TTL expiry etc into account (see draft-ietf-dnsop-dnssec-key-timing and RFC 4641).

If your DNS provider is doing things properly they should have a (very) long-lived Key Signing Key which should be kept in a Hardware Security Module and only brought online when needed which should be effectively impenetrable.

Only the Zone Signing Key then needs to be kept online.

4
  • What would be the disadvantages of longer RRSIG validity, bearing in mind the second footnote to my original question? Separation of KSK and ZSK could indeed reduce the impact of the attack described (fraudulent records would persist, at worst, until ZSK expiry) - but that assumes the KSK module cannot be invoked to sign a fraudulent ZSK (given recent successful attacks on Certification Authorities, which have achieved very similar, I have little confidence).
    – eggyal
    Nov 14, 2011 at 11:19
  • @eggyal a longer RRSIG validity increases the window of opportunity for replay attacks. If the zones are stable the risk is minor, I guess - it just means someone could spoof a record that reproduces old data.
    – Alnitak
    Nov 14, 2011 at 15:42
  • Thanks, as I thought. I don't expect these domains to change much and seriously doubt anyone will be inclined to replay old data when they do; even if they did, traffic can only end up at a previously valid address, so unless an attacker has control of that too it really isn't an issue. Finding a suitable method of uploading offline-signed zonefiles to a hosting provider is, however, still an open question...
    – eggyal
    Nov 14, 2011 at 15:55
  • @eggyal yup, not many provide that level of access to upload new zone data, and as you say nsupdate is only intended to work with zones that are signed on the fly whenever a dynamic update is received. FWIW, I would just let the DNS host get on and do their stuff - for personal vanity domains it's just not worth the hassle.
    – Alnitak
    Nov 14, 2011 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .