1. Bruce Campbell. ISOC Workshopl, 21 June 2004, Amsterdam. http://www.ripe.net RIPE NCC DNS Architecture (for ccTLD secondarying) Nameserver Planning for the long term. Bruce Campbell

2. Bruce Campbell. ISOC Workshop, 21 June 2004, Amsterdam. http://www.ripe.net Problem Outline Policy of secondarying ccTLDs: –We’ll secondary anyone’s ccTLD. Single name (ns.ripe.net): –Single machine. –Memory footprint issues (lots of large zones). –Can’t 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. Bruce Campbell. ISOC Workshop, 21 June 2004, Amsterdam. http://www.ripe.net 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 machine’s 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. Bruce Campbell. ISOC Workshop, 21 June 2004, Amsterdam. http://www.ripe.net 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 don’t bite.

5. Bruce Campbell. ISOC Workshop, 21 June 2004, Amsterdam. http://www.ripe.net Names to delegate to: ns-BI.ripe.net –193.0.12.24, 2001:610:240:0:53:cc:12:24 ns-BJ.ripe.net –193.0.12.36, 2001:610:240:0:53:cc:12:36 ns-LK.ripe.net –193.0.12.208, 2001:610:240:0:53:cc:12:208 ns-NP.ripe.net –193.0.12.154, 2001:610:240:0:53:cc:12:154 ns-TH.ripe.net –193.0.12.219, 2001:610:240:0:53:cc:12:219 ns-UY.ripe.net –193.0.12.237, 2001:610:240:0:53:cc:12:237

6. Bruce Campbell. ISOC Workshop, 21 June 2004, Amsterdam. http://www.ripe.net Summary and Questions Trying to avoid ‘last minute’ renumbering and possible frustrations. Easy upgrade path for NCC’s 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.