RIPE Working Groups

Draft Minutes from RIPE 44

• content to the Chair of the working group.
  
• format to webmaster@ripe.net.

DNS WG Minutes

Scribe: Olaf Kolkman and Daniel Diaz

The slides itself are available on the RIPE site and the content is
not minuted. The presentations will be available at 
http://www.ripe.net/ripe/meetings/ripe-44/presentations/

A. Administrative

 - Minutes approved.

 - There were no open Action Items

 - Transition of IPv6 transition issues will be added to the agenda

 - Patrick Falstrom will co-chair the WG.

 - Video recordings: There are no objections if no profits are not
   made from it.

 - Jim reminds the audience that RIPE NCC has DNSSEC courses, one per
   month.

B. Using SRV records to locate WHOIS data.
   Marcos Sanz (DENIC)
  
   The presentation addresses a mechanism to locate WHOIS servers via
   the DNS as published in a RIPE DNS-WG draft.
  

   Question: 
   Lars-Johan Liman (LJN): Why is the client searching top-down. 

   Answer: The top-down model is best suited for resources that are centrally
   managed and allocated top-down such as domain names and IP addresses.

   LJN: But there is more specific info further down the tree.

   Answer: The client needs to decide if the tree needs to be walked further
   down.
     

   LJN: This is the wrong way to go.
   Peter Koch: For IP addresses have to find bottom up.
         In the bottom up approach there is an attack vector:
	 A spammer may have a 'fake whois' on the most specific
	 addresses.
 
   LJN: WHOIS lookups can be very complicated, you want to have the servers
        at the leaves do most of the work.

   NICNAME is the IANA registered name of the service

   Brad Knowles: lower level servers may have more problems with cache
        pollutions.

   Patrick Falstrom (PAF): Given multiple entries, given that the data
       in the WHOIS servers is inconsistent and given that you want
       the closest contact you want to walk the tree bottom up.
     
   Chair concludes there is no real consensus on the operational issues with 
   respect to the algorithm. 

   Daniel Karrenberg (DFK): suggests to accept the draft with an
   appendix on the different ways one can implement the agenda.
  
   Action point: Next iteration will appear as an Internet draft.
   (Gerhard Winkler & Marcos Sanz)


C. BIND News
  Suzanne Woolf - ISC

  Suzanne presented a general update of the BIND Forum.  Reminded the
  audience of of the BIND forum goals; of ISC supporting BIND8 and
  BIND9; that there will be a CVS repository as of Feb 1; that the
  development focus is on IPv6, DNSSEC, and IDN.
  
  Mohsen Soussi: Can the Bind Forum information available on the ISC
  website be made more visible?
  Suzanne:  This will be done soon.


D. Diverse DNS implementations on sunic.sunet.se
   Mans Nilsson - KTH

   In his presentation named "Running Bind or ? in large scale",
   Mans presented an overview of the history of sunic.sunet.se and
   gave a number of operational insights. He discussed the several possible
   authoritative servers that are being considered.

   Questions: Is UltraDNS being considered.
   Brad Knowles: Ultra DNS is a managed service, not a software product.
   Mans Nilson: Wants to operate service himself.
  
   Miek Gieben: In contrast to the prediction of 100% memory increase
   the real increase is more on the order of 700%.

   Bill Manning advised that bandwidth demands increases too.
   

E. Anycasting k.root-servers.net
   Daniel Karrenberg - RIPE NCC

   Slides are not available for this presentation.
   Daniel explained the content of:
   www.ripe.net/ripe/draft-documents/k-root-anycasting.html
   
   Questions:
   Brad Knowles: What about TCP?
   Answer: not an issues with the current root zone content.
   
   Bill Manning addresses a number of possible 'Cons' that are all
   addressed in the draft. Bill Manning would like to see this
   deployed with some mechanism where data integrity can be
   established and refers to Ihrens proposal (later on the agenda). 
   
   There is consensus in the room that this proposal should move forward.
   Chair: what are the time lines?

   DFK: this will need to be done prudently, do not expect more than
   the London and the Amsterdam server to be on anycast by RIPE45.

   Others root-servers do different/similar things. F.root is doing
   anycast. But root-servers operate in different manners, which is
   part of the defence. An anycasting scheme is under consideration
   for the root server in Stockholm but first wants to replace the
   current hardware.

   IPv6 questions (not strictly related to anycast but to root-servers
   in general): Why aren't there AAAA RRs as glue in the root zone?
   Gert Doering: IPv6 in the Root is always postponed, disappointed
   This is an ICANN issue. Bill Manning refers to his presentation in
   DNR; he runs a testbed with AAAA RRs.  The RIPE community has
   clearly stated that we want this.

   Falstrom (IESG chair) requests to be contacted if AAAA requests for
   the root have been rejected.

   DFK plugs his presentation in DNR.

   Action items identified:

   1) DFK: "move forward"
   2) WG:  Those TLD registries that have tried to register AAAA glue
      please identify themselves and communicate details of success or
      rejection to Patrik/IESG/WG chairs


F. DNS Benchmark Comparisons: BIND8 v BIND9 v djbdns v ???
   Brad Knowles - Snow bv

   Chair: This is a topic that is of interest of the community and
   relates to work by Karrenberg (DISTEL)
   
   Brad presents his benchmarks of most of the currently available
   nameserver software. He showed that a large fraction (53.6%) of TLD
   servers run on at least one server that is also recursive.  He
   presented performance statistics of several DNS server
   implementations either authoritative only or caching.  He showed
   the details of the installation process of all the different
   servers.  Most TLDs are on BIND8, a number on bind8 and only 1 or 2
   TLDs run UltraDNS.


   DFK: NSD does do EDNS0

   DFK: Clarification, to prevent misunderstandings: The root-servers
   _do not_ run recursively.

   Chair: suggested to make a testlab, like RIPE NCC's DISTEL, available
   for DNS tests.

G. Signing the root zone
   Johan Ihren - Autonomica 

   Johan proposed a way to gain experiences with key management at the
   root. He suggests to start experimenting with signing the root
   'today' and to have the root-operators be the keepers of the zone-
   signing key while the RIRs, being neutral and trusted entities,
   keep the key-signing keys. In this scheme operators are not in the
   position to generate new keys but can rotate keys.

   Bill Manning: The 'experimental root' is available is for these
   testing.

   DFK: If the community tells us we should help to implement this
   proposal, this we will do this. There are no technical problems.
  
   Ihren: testbeds have been played with for quite some time, but are
   not representative of the real world in terms of scalability and
   operations.  Besides, the key distribution problem is not addressed
   in a testbed. The distribution problem will not be addressed until keys
   are actually distributed in the root.
    
   DFK: There may be some overloading of RIR duties. 
   Falstrom: It is hard to find another place that people trust. The RIRs
   is a set of trusted organizations.

   Alvestrand: why not have the ccTLDs and gTLDs select five out of
   them to do this?
   Jim Reid (personal capacity): Organizations should be international,
   neutral and will need to represent stake holders.

   Mohsen Soussi: Why not the root-server operators?  
   Ihren: The root-server operators only publish; signing is
   essentially publishing data. The functions of signing and
   publishing should be separate.

   DFK: but isn't ICANN the owner of the zone?
   Ihren: Do we want  one organization be responsible for holding the key?

   Manning: The proposal does not specify where 'it' ends
   Ihren: Split key is a probable end-station, but that is not ready quite 
   yet.
 
   Koch: Thinks the RIRs are the appropriate people to do this. Given
   a technical consensus how do we go from here?  
   Ihren: There is a mechanism for editing the root-zone and
   authorizing changes. That mechanism would work.

   Chair: Ask RIPE NCC to consider this proposal, discuss the idea with
   the other RIRs and come with technical and political recommendations.

   Action on NCC; check whether constituency would support this approach
 

Extra agenda point
 - Andrei Robachevsky gave a small report on IPv6 related DNS issues 
 
   Reverse v6 delegations 
   Support for v6 reverse delegations, support delegations in ip6.int?
   - RFC3152 since August 2001.
   - Support delegations or phase out?

   

  Some comments from audience:
   + Proposal freeze new delegations in the .INT tree.  
   + Any resolver based on bind8 has ip6.int hard coded.  
   + Statistics may help to decide where to go.


  Reverse delegations for 6 to 4 space
  - draft-ietf-dnsop-ipv6-dens-issues-00
  - draft-moore-6to4dns-03.txt

  Andrei: RIPE NCC wants more feedback from the community to see how important
  this issue is as the IETF requested not to support this.

  Bill Manning: There is demand from the community as seen from
  delegation requests in 2002:: space. (most of them coming from
  Mexico, Finland and France)
  
  Andrei: We can present a proposal to support reverse 6to4
  delegations by the RIRs.


  Reverse delegation for 6bone space in ip6.arpa
  - 2phase approach
  - replicate 3.f.f.3.ip6.int with initial lameness check
  - Takes into account 6bone phase out 
    + Bob Fink's proposal for address management transfer
    + draft-fink-6bone-phaseout-00.txt
 
  IPv6 access to ns.ripe.net
   - Since 2 December 2002
 
  Chair invites volunteers to give input on these items.
  David Kessens invites people to continue the discussion in the IPv6 
  working group.