DNS Transfers in DNSSEC world

DNS Transfers in DNSSEC world

Olafur Gudmundsson

Steve Crocker

Shinkuro, Inc.

DNS Transfer for Signed Domains

Introduction

• DNS Transfer is the movement of operations of domain X from one operator to another one.

• We are looking at – the general case, not just the ICANN RRR case. – from protocol and operational perspective.

• We seek “ripple-free” transfer, i.e.– For Resolvers that are actively querying the domain,

queries are resolved smoothly and signatures continue to be validated.

2


DNS operator transfer != DNS registrar transfer

• In this presentation assuming:– only the DNS operation is changing hands

• We do this to get handle on:– what information needs to flow between the operators

and the parent. – How long information needs to be in DNS before next

step can be taken– What will go wrong and for how long

• From this we will hope to map actions needed into the different operating environments

3


DNS transfer notation• RRsets at Old (lower case) and New (upper case)

• n = name servers for Old; TTL = nt• N = name servers for New; TTL = Nt

• Parent RRsets: • n = NS set from Old, • N = NS set from New

– Both covered by TTL value Pt– We assume parent keeps the same TTL on RRset before and after change

• Function: – M() = Max() function where the timers start after the action is performed

• Table Interpretation:– Only show values when something changes in that actor.

i.e. blank fields imply no change– If no value in delay field, there is no delay required– If multiple actions on a line, actions can be performed in any order

4


DNS transfer today

Step Delay Parent OLD NEW Resolver

NS

0 n n n

1 N

2 N

M(Pt, nt) N

3 stops

5


DNSSEC complications

• Parent stores a DS record to vouch for the (KSK) keys in the DNSKEY record.

• A validating DNSSEC resolver needs to have the DNSKEY RRset for the delegation and a DS set that vouches for it. – It needs to be in one of these states:

• Have the key corresponds to the zone signing key

• Not have a DNSKEY RRset and look it up.

• Preconditions: – D > K – Z > RRsig by Z

6


DNSSEC Transfer RRset Notation

• RRsets at Old (lower case) and New (upper case)– Name Servers (NS) as before, n, N– DNSKEY

• k = KSK for Old • K = KSK for New • z = ZSK for Old• Z = ZSK for new • \ is separator between active\inactive keys • kz\Z DNSKEY set containing all these keys but only z and k

generate signatures.• Parent RRsets:

– NS n = NS from Old, N = NS from New – DS

• d = DS from Old corresponds to k ,• D = DS from New corresponds to K • dD = DS from both Old and New

7


DNSSEC Transfers Timers Notation

• Operators: – Parent: NS set and DS set

• Pt = TTL on NS, • Dt = TTL on DS

– Old: NS set (n) and DNSKEY (zk) • nt = TTL on NS, • kt = TTL on DNSKEY

– New: NS set (N) and DNSKEY (ZK) • Nt = TTL on NS, • Kt = TTL on DNSKEY

• Function:– M() = MAX() function, timers start after corresponding

action has taken place

8


DNSSEC added to current transfer

Step Delay Parent Old Operator (n)New Operator

(N)Validating Resolver

NS DS NS KEY NS KEY NS KEY

0 n d n kz n d kz

1 N KZ\z

2 n dD

Dt n dD kz

3 N dD

0N dD kz

N dD zKZ

M(Pt, nt) + kt N dD zKZ

4 Stops Stops

5 N D N KZ

M(Kt, Dt) N D KZ

9


DNSSEC added to current transfer:what went wrong?

• Verification error happens if a Validator sees a RRset accompanied by signatures by NO keys in the current copy of DNSKEY!– Validator has Old’s DNSKEY set: kz– Validator got RRset signed by Z from new

Error

• New operators ZSK MUST be in Old’s DNSKEY set before transfer!

10


Cooperative DNSSEC transfer• New instantiates the zone

– DNSKEY sets MUST include z from Old and Z from New• New imports z from Old• New sends Z to Old

Old MUST add that to the DNSKEY set• New sends K/D to Parent

Parent adds D to DS set.

• After both Old and Parent have updated the keying information, actual transfer can take place

– Old MUST do one of the following – Slave New– Change NS set to point to N– Proxy New i.e. forward all queries to N server’s

– New updates NS set at Parent to N – Parent changes NS set to point to New (N)

• After information from Old has been flushed out• Old can stop serving• New can start purging data

11


Cooperative DNSSEC transfer

• Before Transfer:– DNSKEY sets must contain both z and Z– DS must contain d and D

• Old MUST do one of the following just before transfer

– Slave New– Change NS set to point to N– Proxy New i.e. forward all queries to N server’s

• After Transfer and after information from Old has timed out– Flush z and d from the system

12


Cooperative Transfer Table

Step Delay Parent Old Operator (n)New Operator

(N)Validating Resolver

NS DS NS KEY NS KEY NS KEY

0 n d n kz n d kz

1 N KZ\z

2 n dD n kz\Z

M(kt, Dt) n dD kzZ

3 N kz\Z

4 N dD

M(Pt, nt) + kt N dD zKZ

5 Stops Stops

6 N D N KZ

M(Kt, Dt) N D KZ

13


Sticky Resolver Problem

• Some resolvers “stretch” the TTL– When they see an NS set that matches what’s

in the cache, they extend the expiration time.

• This can prevent a resolver from ever discovering that a transfer is in progress.

• The cooperative transfer procedure prevents this because the Old server pushes the new information.

14


Alternatives: Unsigned

• New can instruct parent to purge the DS set– Have Old show up as unsigned

• Transfer

• After the transfer New can add his DS record

15


Alternatives: Short TTL

• To make the outage as short as possible decreasing TTL’s in old is a possibility. – The idea is to force the Validator to have NS

and DNSKEY time out fast enough that no reuse takes place.

– This increases the traffic to Old servers during transfer, as Old must serve the zone with short TTL for at least old nt before transfer and at least Pt after the transfer.

• Think nt < 30 sec

16


Way forward

• Different operating worlds need to agree on which alternative they want to use.

• Need to map the solution their systems

17

Documents

DNS Transfers in DNSSEC world