1 / 17

DNS Transfers in DNSSEC world

DNS Transfers in DNSSEC world. Olafur Gudmundsson Steve Crocker Shinkuro, Inc. 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.

Download Presentation

DNS Transfers in DNSSEC world

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DNS Transfers in DNSSEC world Olafur Gudmundsson Steve Crocker Shinkuro, Inc.

  2. 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. DNS Transfer for Signed Domains

  3. 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 DNS Transfer for Signed Domains

  4. 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 DNS Transfer for Signed Domains

  5. DNS transfer today DNS Transfer for Signed Domains

  6. 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 DNS Transfer for Signed Domains

  7. 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 DNS Transfer for Signed Domains

  8. 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 DNS Transfer for Signed Domains

  9. DNSSEC added to current transfer DNS Transfer for Signed Domains

  10. 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! DNS Transfer for Signed Domains

  11. 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 DNS Transfer for Signed Domains

  12. 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 DNS Transfer for Signed Domains

  13. Cooperative Transfer Table DNS Transfer for Signed Domains

  14. 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. DNS Transfer for Signed Domains

  15. 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 DNS Transfer for Signed Domains

  16. 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 DNS Transfer for Signed Domains

  17. Way forward Different operating worlds need to agree on which alternative they want to use. Need to map the solution their systems DNS Transfer for Signed Domains

More Related