Agenda Bashing
 Name Service Daemon and DISTEL (D. Karrenberg)
 RIR presentation (R. PLzak)
 Routing Beacons and other things (H. Uijterwaa)
 GEANT Deployment of Premium IP (S Leinen)
 Looking at ccTLD server behaviour (N. Brownlee)
 Dial-By-ASN (B. Woodcock)
 Sources of ongoing damage to DNS System (K Claffy)

1. A Name Service Daemon

Daniel Karrenberg

distel2.pdf (ppt)(Also at

nsd.pdf (ppt) (Also at

a Name Service Daemon Why?

What is nsd? Authoratitive only DNS name server

Performance Outcomes

Who could use nsd?





present a reproducible load to the server

None of the difference encountered will be noticed by resolvers conforming to the Internet standards. Issues of reproduction of timing of replay of load with anomalies of microsleep function in FreeBSD was resolved with the use of a busy wait to correct microsleep anomalies.

Talk to Daniel if intersted in the test lab - there is no manual and nothing other than best efforts of support.

Q: are you interested in volunteer assistance?
A: what someone to take the tarball and log their experience and turn the log into installation instructions

A: suggestions for synthetic loads would appreciated

Q: you you have any sampled loads from the root server dos attacks?
A: no

Q: have you measured the speed to reload for nsd for a large zone file
A: you don't need to load it, as the database provides the answers for queries. You don't notice reload time normally

Q: how big?
A: .nl (750K delegations, 200M compiled size) .de (couple of million, takes a 4G drive on a 32 bit machione - a 64 bit machine would be prefereable for such a zone size)

Q: you have tried all kinds of different zones?
A: yes

People interested in real sizes of compiled zones should contact Daniel. Also those interested to run this, see Daniel and the nl lab people.

2. Joint RIR Presentation

Ray Plzak

rir.pdf (ppt)

Welcome to LACNIC as the most recently chartered RIR

Review V4 allocation

ASN assignments

V6 allocation review

Joint Activities

Comment: PLease have non-overlapping meeting dates for RIR meeings.

Routing Beacons and other things

H. Uijterwaal

beacons.pdf (ppt)

Look at route flapping, flap dampening, BGP under stress. Use a test rig that announces and withdraws a know prefix at known intervals. There are usually 2 or 3 beacons active at any particular time.

Request to set up more beacons - RIPE NCC to set up more at their route collector sites (9). Uses a /19 for this as an experimental effort. Announcements are at 0, 4, 8, ... GNT witgh withdrawals at 2, 6, ... GMT. The beaconing prefix is,, ... at each route collector point.

What do you see?

Latency roughly consistent with previous studies same effect of expanding paths as per previous studies questions and work remain

Update on RIR - IPv6

Update on Test Traffic - CDMA clocks for the synchronized measurement - IPv6 also available - Contact Henk for details

Q: Are beacons similar to the IPMA fault injector?
A: This was an experiment some time ago and no longer active.

3. GEANT Deployment of Premium IP

Simon Leinen


Environment of a Backbone network, with heterogenous national networks with campus networks. GEANT has been active for around 12 months, using a 10G STM-64 POS core. Heavily overprovisioned network.

SEQUIN Project of DIffServ deployment. Objective to find a replacement for a managed bandwidth virtual circuit service that based on ATM in a previous incarnation of the pan-European network.

A need for two elevated services: premium low jitter rate limited service, and some form of "IP+" using some kind of assurred rate model (e.g. min dandwidth guarantee - couldn't build). Note this is multi-domain in cores plus national feeder networks.

Implementaiton of low jitter service within a domain - this is "classical" EF-based implementation use different policing granularity - core does AS pairs, edges may do network pairs. BUT routers do not have easy way to specify policing with respect to origin AS. not implemented.

There is a desire to be "lenient" with respect to bursts. Bursts were just let through. No egress shaping. Not worth the effort. INgress policing was assumed close to the source, and the backbone simply policed between domains in an approximate fashion.

Implementation through over-provisioning was an option for the feeder networks.

Hard to draw conclusions with this effort so far as the core is extensively over-provisioned.

Room discussion of trial using long latency 64K lines. Lab tests of recent hardware found line rate sustained with QoS features turned on.

Tests using H.323 packet traces across the backbone. Capture a stream and replay it using different paramters and compare the new capture ot the original. Noted packet recordering on packets of different sizes with 300Kbit bit rate. Noted with variation of packet sizes. reordering packet size traceroute shows this. Also use a modified traceroute to see a modified DSCP.

Lessons - its a lot of work, it requires comprehensive edge policing, overlay networks are difficult, user satisfaction and performance are not related, provisioning needs to be streamlimned.

Focus now shifting the SLAs and an end-to-end performance problem.

Q: Distributed denial of service attack with EF traffic flooding.

Looking at ccTLD server behaviour

Nevil Brownlee

Look at round trip tip time of cctld name servers using NetTraMet.

Data collection at two points, collecting the request and matching response packet pairs and looking at RTT.

Initial investigation revealks higher variation of RTT as compared to the roots and gTLDs on the whole, althought this is a highly approximate observation.


Bill Woodcock A Phone system that will contact of the NOC associated with an AS. Uses SIP as the base. The phone boot DHCPs an address and registers with a SIP registry. The problems so far are with NAT traversal (of course). But it can be done with static configuration. STUN is also relevant to the NAT issue.

QoS is completely unnecessary!

Sound quality exceeds the PSTN even under the worst conditions.

This works on any SIP phone, including various soft phones and 802.11 phones

Sources of ongoing damage to DNS System

K Claffy

Monitoring dns root server performance. The DOS attack on the root servers is noticable in terms of monitoring root server response time. It was noted that this has happened in the previous week(s) as well.

Reference Duane Wessell's presentation at NANOG October 2002 noting that some 2% of F root queries were valid and the other 98% were not! This tallioes with an earlier CAIDA study. Two tools are available.

One of the categories of root traffic are RFC1918 updates being sent to the root nameserver system. This traffic is being measured and analysed. Stroing diurnal pattern evident. Largely DSL and cablemodem providers appear to be leaking these updates to the roots. Predominant OS is Windows-based. This can be fixed, at 6 menus deep in the OS. The default software design and its configuration of these Microsoft OS platforms is evidently causing a massive amount of traffic sent to the root name server system.