This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
193.in-addr.arpa block delegation procedures (draft)
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marten Terpstra
Marten.Terpstra at ripe.net
Tue Mar 16 12:45:46 CET 1993
Folks, It seems that the delegation of the 193.in-addr.arpa domain will take place during the root zone update of today. In order to be able to delegate class C blocks in this zone, we have drafted some procedures for this. Please read the paper below and comment within one week. We will finalize this paper next week, and then start delegating blocks of Cs in the domain. Cheers, -Marten Guidelines for the delegation of class C blocks in the 193.in-addr.arpa domain Marten Terpstra March 1993 1.0 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. 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. 4. 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. 5. 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. 6. 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. 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.
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]