Log in

No account? Create an account


Cutting a zone with DNSSEC

« previous entry | next entry »
21st Oct 2015 | 15:49

This week we will be delegating newton.cam.ac.uk (the Isaac Newton Institute's domain) to the Faculty of Mathematics, who have been running their own DNS since the very earliest days of Internet connectivity in Cambridge.

Unlike most new delegations, the newton.cam.ac.uk domain already exists and has a lot of records, so we have to keep them working during the process. And for added fun, cam.ac.uk is signed with DNSSEC, so we can't play fast and loose.

In the absence of DNSSEC, it is mostly OK to set up the new zone, get all the relevant name servers secondarying it, and then introduce the zone cut. During the rollout, some servers will be serving the domain from the old records in the parent zone, and other servers will serve the domain from the new child zone, which occludes the old records in its parent.

But this won't work with DNSSEC because validators are aware of zone cuts, and they check that delegations across cuts are consistent with the answers they have received. So with DNSSEC, the process you have to follow is fairly tightly constrained to be basically the opposite of the above.

The first step is to set up the new zone on name servers that are completely disjoint from those of the parent zone. This ensures that a resolver cannot prematurely get any answers from the new zone - they have to follow a delegation from the parent to find the name servers for the new zone. In the case of newton.cam.ac.uk, we are lucky that the Maths name servers satisfy this requirement.

The second step is to introduce the delegation into the parent zone. Ideally this should propagate to all the authoritative servers promptly, using NOTIFY and IXFR.

(I am a bit concerned about DNSSEC software which does validation as a separate process after normal iterative resolution, which is most of it. While the delegation is propagating it is possible to find the delegation when resolving, but get a missing delegation when validating. If the validator is persistent at re-querying for the delegation chain it should be able to recover from this; but quick propagation minimizes the problem.)

After the delegation is present on all the authoritative servers, and old data has timed out of caches, the new child zone can (if necessary) be added to the parent zone's name servers. In our case the central cam.ac.uk name servers and off-site secondaries also serve the Maths zones, so this step normalizes the setup for newton.cam.ac.uk.

| Leave a comment | Share

Comments {4}


from: nonameyet
date: 21st Oct 2015 15:05 (UTC)

Does it make much difference whether or not the Maths name servers support DNSSEC ?

Reply | Thread

Tony Finch

from: fanf
date: 21st Oct 2015 15:12 (UTC)

The process is the same either way. The important thing is that the delegation correctly describes the status of the new zone (secure or not).

Reply | Parent | Thread

Lower the TTLs

from: anonymous
date: 21st Oct 2015 23:47 (UTC)

Lower the TTL of any answers from the namespace (positive and negative) before introducing the delegation. This will minimise any impact from validation failures due to old cached data. With normal delegations you don't usually have cached answers in the namespace to be delegated so this is not normally a issue.

Reply | Thread

Tony Finch

Re: Lower the TTLs

from: fanf
date: 22nd Oct 2015 07:38 (UTC)

Good point, thanks!

In practice (sadly, still) there isn't much endpoint validation or other validation behind caches, so I didn't think of that problem properly, but you rightly point out that it should be handled.

I am still worried about the authoritative propagation aspect of this. It is fast for cam.ac.uk, but not for my personal zones, for example :-/ Mark Andrews' solution to this problem is ... advanced! https://lists.dns-oarc.net/pipermail/dns-operations/2015-October/013836.html

Reply | Parent | Thread