RIPE NCC DNS Architecture for ccTLD secondarying

1
RIPE NCC DNS Architecture(for ccTLD secondarying)

• Nameserver Planning for the long term.
• Bruce Campbell ltbruce_at_ripe.netgt

2
Problem Outline

• Policy of secondarying ccTLDs
• Well secondary anyones ccTLD.
• Single name (ns.ripe.net)
• Single machine.
• Memory footprint issues (lots of large zones).
• Cant renumber as need signoff from far too many
  parties individual redelegating for performance
  (eg .de) takes too long.
• DNSSEC is scary
• Increases individual zone footprint
  significantly.
• Machine has finite possible memory size.

3
Solution

• Shift away from single name (and address)
• Still single machine, but lots of IP aliases.
• Lots of glue records in root zone.
• Can go IPv6 on a per ccTLD basis, not all or
  nothing.
• No renumbering required when zone grows beyond
  machines capacity.
• Can drop in a new machine and remove IP alias on
  the previous machine at any time without needing
  editing of the root zone (IANA).

4
Renaming what to what?

• Old name ns.ripe.net
• New name ns-XX.ripe.net
• XX is the ISO3166 country code
  ns-af.ripe.net
• Separate address for each one eg 193.0.12.1,
  193.0.12.248
• Good chance to talk to IANA
• They dont bite.

5
Names to delegate to

• ns-BI.ripe.net
• 193.0.12.24 , 2001610240053cc1224
• ns-BJ.ripe.net
• 193.0.12.36 , 2001610240053cc1236
• ns-LK.ripe.net
• 193.0.12.208 , 2001610240053cc12208
• ns-NP.ripe.net
• 193.0.12.154 , 2001610240053cc12154
• ns-TH.ripe.net
• 193.0.12.219 , 2001610240053cc12219
• ns-UY.ripe.net
• 193.0.12.237 , 2001610240053cc12237

6
Summary and Questions

• Trying to avoid last minute renumbering and
  possible frustrations.
• Easy upgrade path for NCCs hardware as the total
  size of zones approaches upper memory limit on a
  single machine.
• Lets the NCC do maintenance work without
  interrupting service (IP aliases can be moved
  between spare machines easily)
• IPv6 connectivity for your zone with no pain to
  you.