Blocks in 193.in-addr.arpa domain document

Folks,

Here's the updated document. I was planning on sending this out over the
weekend, but forgot the modem cable ;-( Anyway, let's see if we can get
agreement on this. Please note that the database specific things I do not
want to spend too much on, this should be done at the RIPE meeting.

A few more days to comment. Want to start delegating blocks end of the week,
and during next week (although I will be at the IETF).

-Marten



			Guidelines for the delegation
			  of class C blocks in the
			   193.in-addr.arpa domain

			       Marten Terpstra

				 March 1993

				    V1.1


Introduction

This document describes the procedures for the delegation of authority
of zones in the 193.in-addr.arpa domain. As of March 16th 1993 the
RIPE NCC has been delegated the authority for the 193.in-addr.arpa
domain from the root. Due to the fact that in the 193.x.y address space
blocks of 256 class C network numbers are further delegated to local
registries and national registries, the possibility exists to also
delegate the zone for these blocks in the 193.in-addr.arpa domain.
This document describes some guidelines and procedures for
this type of delegation.


A bit more explained

With the assignment of class C network numbers following the CIDR (RFC
1338) model, in which large chunks of the address space are delegated to
one region, and within that region blocks of class C network numbers are
delegated to service providers and national registries, some hierarchy
in the address space is created, similar to the hierarchy in the domain
name space. Due to this hierarchy the reverse Domain Name System mapping can
also be delegated in a similar model as used for the normal Domain Name
System. For instance, the RIPE NCC has been delegated the complete class
C address space starting with 193. It is therefore possible to delegate
the 193.in-addr.arpa domain completely to the RIPE NCC, in stead of each
and every reverse mapping in the 193.in-addr.arpa domain to be
registered with the INTERNIC. This implies that all 193.in-addr.arpa
resistrations will be done by the RIPE NCC. Even better, since service
providers receive complete class C network blocks from the RIPE NCC, the
RIPE NCC can delegate the reverse registrations for such complete blocks
to these local registries. This implies that customers of these service
providers no longer have to register their reverse domain mapping with
the root, but the service provider have authority over that part of the
reverse mapping. This decreases the workload on the INTERNIC and the
RIPE NCC, and at the same time increase the service a provider can offer
its customers and response times for such additions. However there are
some things that need to be examined a bit more closely to avoid
confusion and inconsistencies. These issues are covered in the next
section.

Procedures

1. A secondary nameserver at ns.ripe.net is mandatory for all blocks of
class C network numbers delegated in the 193.in-addr.arpa domain.

2. Because of the increasing importance of correct reverse address
mapping, for all delegated blocks a good set of secondaries must be
defined. There should be at least 2 nameservers for all blocks
delegated, excluding the RIPE NCC secondary.

3. The delegation of a class C block in the 193.in-addr.arpa domain can
be requested by sending in a domain object for the RIPE database to
<hostmaster at ripe.net> with all necessary contact and nameserver
information. The RIPE NCC will then forward all current reverse zones
inside this block to the registry, and after addition by the registry,
the NCC will check the working of the reverse server. Once everything is
setup properly, the NCC will delegate the block, and submit the database
object for inclusion in the database. An example domain object can be
at the end of this document.

4. All reverse servers for blocks must be reachable from the whole of
the Internet. In short, all servers must meet similar connectivity
requirements as top-level domain servers.

5. Running the reverse server for class C blocks does not imply that one
controls that part of the reverse domain, it only implies that one
administers that part of the reverse domain.

6. Before adding individual nets, the administrator of a reverse domain
must check wether all servers to be added for these nets are indeed
setup properly.

7. There are some serious implications when a customer of a service
provider that uses address space out of the service provider class C
blocks, moves to another service provider. The service provider cannot
force its ex-customer to change network addresses, and will have to
continue to provide the appropriate delegation records for reverse
mapping of these addresses, even though it is no longer a customer of
his.

8. The registration of the reverse zones for individual class C networks
will usually be done by the registry administering the class C block
this network has been assigned from. The registry will make the
necessary changes to the zone, and update the network objects in the
RIPE database for these networks, to reflect the correct "rev-srv"
fields. In case the RIPE NCC receives a request for the reverse zone of
an individual class C network out of a block that has been delegated,
the request will be forwarded to the zone contact for this reverse
block.

Above procedures are defined to ensure the necessary high availability for
the 193 reverse domains, and to minimize confusion. The NCC will ensure fast
repsonse times for addition requests, and will in principle update the
193.in-addr.arpa domain at least once per working day.

The NCC also suggests that similar procedures are set up for the delegation
of reverse zones from the registries to individual organisations.

Example domain object to request a block delegation

domain:  202.193.in-addr.arpa
descr:   Pan European Organisations class C block
admin-c: Daniel Karrenberg
tech-c:  Marten Terpstra
zone-c:  Marten Terpstra
nserver: ns.eu.net
nserver: sunic.sunet.se
nserver: ns.ripe.net
changed: marten at ripe.net 930319
source:  RIPE