Aristotle Balogh February 2000 NSI Registry Update NANOG 18, San Jose, California Aristotle Balogh February 6, 2000

Aristotle BaloghFebruary 2000

NSI Registry Update

NANOG 18, San Jose, CaliforniaAristotle BaloghFebruary 6, 2000


Agenda

• Background• Registry Operating Metrics• gTLD RFP and deployment plans/status• Root and gTLD stat’s• Next-generation stuff

– Multicast satellite dist– DNSSEC


NSI Registry System Loads I

• Live operations with NSI registrar in April 1999• First non-NSI registrar in June 1999• By August 1999

– 8 total registrars– Read-Write Create/Update/Delete Loads

• 132,000 operations per day• 3.67 operations per second during busy hour

– Read-Only Query Loads• 1,300,000 operations per day• 36.11 operations per second during busy hour


NSI Registry System Loads II

• February 2000– 25+ total registrars– Read-Write Create/Update/Delete Loads

• 256,000 operations per day (94% increase)• 7.11 operations per second during busy hour

– Read-Only Query Loads• 5.2M operations per day (300% increase)• 144.44 operations per second during busy hour


Reliability, Availability, Scalability

• “Dial Tone” Quality Product– “Hot” primary/secondary data centers– Read-Only (RO) operations separated from Create,

Update, and Delete (CUD) operations– Self-help tools and protocol enhancements

• Repeatable Engineering Processes– Requirements, configuration, release, defect

tracking, and escalation management with integrated tool support

– Automated stress, performance and integrity testing

– Detailed project planning, tracking, and oversight


gTLD Site Selection Request for Proposal

RFP Objective:“Identify and place the gTLD servers at the topological cores of the Internet; put gTLD DNS infrastructure under contractual framework”

Requirements• Proximity to Internet hosts and users• Internet connectivity• Peering relationships• Adequate site facilities• Technical support• Price

Process:• RFP distributed to over 80 qualified vendors in Nov/Dec 1999


gTLD Site Selection Request for Proposal

RFP Results• 28 vendors registered to provide proposals• 20 vendors responded with proposals• Proposals currently being evaluated• Sites being visited• Selected vendors to be identified during February 2000

Schedule• Deployment of next generation systems scheduled to begin Feb, 2000 through July 15, 2000


Average QPS for A, J & J.gtld

0

500

1000

1500

2000

2500

a.root-servers.net j.root-servers.net j.gtld-servers.net


Root and GTLD Servers

• Growth in .com is accelerating• Pushing resources to the limits• Axfer off of a.root-servers.net is no longer

feasible (E450)• Zone propagation is growing (3+ hours) to

distant sites.• Queries per second (QPS is growing).


Average QPS for A & J Root Servers

0

500

1000

1500

2000

2500

a.root-servers.net j.root-servers.net


Top 10 a.root-servers.net Queries

69.989%

17.021%

6.392%4.407%

1.475%0.241% 0.237% 0.042% 0.036% 0.035%

0.000%

10.000%

20.000%

30.000%

40.000%

50.000%

60.000%

70.000%

80.000%

A queries PTR queries MX queries ANY queries NS queries CNAME queries SOA queries Unknow n querytypes

type 33 queries TXT queries


Top 10 j.root-servers.net Queries

72.628%

14.205%

7.192%

2.899% 2.089%0.411% 0.152% 0.094% 0.091% 0.070%

0.000%

10.000%

20.000%

30.000%

40.000%

50.000%

60.000%

70.000%

80.000%

A queries PTR queries MX queries NS queries ANY queries SOA queries type 33 queries CNAME queries Unknow n querytypes

AAAA queries


Top 10 j.gtld-servers.net Queries84.486%

7.624% 7.519%

0.137% 0.082% 0.046% 0.033% 0.026% 0.017% 0.010%0.000%

10.000%

20.000%

30.000%

40.000%

50.000%

60.000%

70.000%

80.000%

90.000%

A queries ANY queries MX queries CNAME queries SOA queries NS queries PTR queries MG queries type 33 queries AAAA queries


Named Memory Usage

0

10,000,000

20,000,000

30,000,000

40,000,000

50,000,000

60,000,000

70,000,000

Jan-

99

Mar

-99

May

-99

Jul-9

9

Sep-9

9

Nov-99

Jan-

00

Mar

-00

May

-00

Jul-0

0

Sep-0

0

Nov-00

Jan-

01

Mar

-01

May

-01

Jul-0

1

Sep-0

1

Nov-01

Time

Do

mai

n N

ames

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Mem

ory

(m

b)

Domain Growth

Memory Growth

August 200032-bit Memory Wall


Average QPS - a.root-servers.net

0

500

1000

1500

2000

2500

3000

3500

4000

Sep-9

4

Nov-9

4

Jan-

95

Mar

-95

May

-95

Jul-9

5

Sep-9

5

Nov-9

5

Jan-

96

Mar

-96

May

-96

Jul-9

6

Sep-9

6

Nov-9

6

Jan-

97

Mar

-97

May

-97

Jul-9

7

Sep-9

7

Nov-9

7

Jan-

98

Mar

-98

May

-98

Jul-9

8

Sep-9

8

Nov-9

8

Jan-

99

Mar

-99

May

-99

Jul-9

9

Sep-9

9

Nov-9

9

Jan-

00

Mar

-00

May

-00

Jul-0

0

Sep-0

0

Nov-0

0


Average QPS - j.root-servers.net

0

200

400

600

800

1000

1200

1400

1600

Feb-9

7

Apr-9

7

Jun-

97

Aug-9

7

Oct-

97

Dec-9

7

Feb-9

8

Apr-9

8

Jun-

98

Aug-9

8

Oct-

98

Dec-9

8

Feb-9

9

Apr-9

9

Jun-

99

Aug-9

9

Oct-

99

Dec-9

9

Feb-0

0

Apr-0

0

Jun-

00

Aug-0

0

Oct-

00


Average QPS - j.gtld-servers.net

0

500

1000

1500

2000

2500

Aug-9

7

Oct-

97

Dec-9

7

Feb-9

8

Apr-9

8

Jun-

98

Aug-9

8

Oct-

98

Dec-9

8

Feb-9

9

Apr-9

9

Jun-

99

Aug-9

9

Oct-

99

Dec-9

9

Feb-0

0

Apr-0

0

Jun-

00

Aug-0

0

Oct-

00

Dec-0

0


Satellite Based Zone File Distribution

• Challenges with current zone file distribution– Large file size (e.g. com.xfer is about 1.4 GB)– Files sizes growing exponentially– Variable latency and congestion on the

Internet causes problems during zone transfer.

– Long transfer times for remote sites (e.g. 4 hrs for Hong Kong site)

– Zone file distribution time limits frequency of zone file distribution (currently twice a day)


• Distributing zone files via satellite:– Enables use of compressed zone files

(com.xfer.gz is 120 MB)– Scalable: Impact of file size growth is less– Provides fixed latency and congestion free

transport– Simultaneous delivery of zones – Less load on zone distribution servers– Enables more frequent zone file updates

(e.g. 4 times a day)



Milestones Due Date

Concept of operation completed

Test plan 02/ 11/ 00 Verification testing 03/ 15/ 00 Detailed design and implementation plan

03/ 31/ 00

Production test plan 04/ 31/ 00 Production implementation 05/ 31/ 00

Timeline:



DNS Security Issues

• Participated in a number of workshops– non-trivial to setup– current implementation is buggy

• What the future holds– Has to only work in EDNS-aware servers (packet

overflow on the roots for UDP on present 512 byte limitation).

– Bind 8.x will not work.


DNS Security Changes

• Registrar/Registry split means that client has to go through registrar to have registry to sign.

• Steps:– Registrar needs to identify the domain holder and

selects key that they desire to have signed with)– Registrar identifies itself with the registry– Verify that domain is with registrar– Signs domain public key – Signed key is returned to domain holder


DNS Security Changes

• Issues for NSI Registry– Registrars need to setup a front-end signing service

for their domain holders)– RRP (the protocol that is between the registrar and

registry) needs to be enhanced– Performance issues– Security issues on the key


Contact Info

• Registry Engineering

– Ari Balogh• [email protected]

• DNS/gTLD Programs

– Tom Newell• [email protected]

– Mark Kosters• [email protected]

Documents

Aristotle Balogh February 2000 NSI Registry Update NANOG 18, San Jose, California Aristotle Balogh February 6, 2000