Changes to Guidelines For The Delegation Of Zones In The 193.in-addr.arpa Domain

Introduction delete: <br /> delete: <br /> This document describes the procedures for the delegation of au- delete: <br /> thority of zones in the 193.in-addr.arpa domain. As of March delete: <br /> 16th 1993 the RIPE NCC has been delegated the authority for the delete: <br /> 193.in-addr.arpa domain from the root. Due to the fact that in delete: <br /> the 193.x.y address space blocks of 256 class C network numbers delete: <br /> are further delegated to local registries , the possibility ex- delete: <br /> ists to also delegate the zone for these blocks in the 193.in- delete: <br /> addr.arpa domain. This document describes some guidelines and delete: <br /> procedures for this type of delegation and the delegation of re- delete: <br /> verse zones for individual class C networks in 193.x.y. delete: <br /> delete: <br /> delete: <br /> A bit more explained delete: <br /> delete: <br /> With the assignment of class C network numbers following the CIDR delete: <br /> (RFC 1338) model, in which large chunks of the address space are delete: <br /> delegated to one region, and within that region blocks of class C delete: <br /> network numbers are delegated to service providers and non- delete: <br /> provider registries, some hierarchy in the address space is delete: <br /> created, similar to the hierarchy in the domain name space. Due delete: <br /> to this hierarchy the reverse Domain Name System mapping can also delete: <br /> be delegated in a similar model as used for the normal Domain delete: <br /> Name System. For instance, the RIPE NCC has been assigned the delete: <br /> complete class C address space starting with 193. It is there- delete: <br /> fore possible to delegate the 193.in-addr.arpa domain completely delete: <br /> to the RIPE NCC, instead of each and every reverse mapping in the delete: <br /> 193.in-addr.arpa domain to be registered with the INTERNIC. This delete: <br /> implies that all 193.in-addr.arpa resistrations will be done by delete: <br /> the RIPE NCC. Even better, since service providers receive com- delete: <br /> plete class C network blocks from the RIPE NCC, the RIPE NCC can delete: <br /> delegate the reverse registrations for such complete blocks to delete: <br /> these local registries. This implies that customers of these delete: <br /> service providers no longer have to register their reverse domain delete: <br /> mapping with the root, but the service provider have authority delete: <br /> over that part of the reverse mapping. This decreases the work- delete: <br /> load on the INTERNIC and the RIPE NCC, and at the same time in- delete: <br /> crease the service a provider can offer its customers by improve delete: <br /> response times for reverse mapping changes . However there are delete: <br /> some things that need to be examined a bit more closely to avoid delete: <br /> confusion and inconsistencies. These issues are covered in the delete: <br /> next section. delete: <br /> delete: <br /> delete: <br /> Procedures for the delegation of direct subdomains of 193.in- delete: <br /> addr.arpa delete: <br /> delete: <br /> 1. A secondary nameserver at ns.ripe.net is mandatory for all delete: <br /> blocks of class C network numbers delegated in the 193.in- delete: <br /> addr.arpa domain. delete: <br /> delete: <br /> 2. Because of the increasing importance of correct reverse ad- delete: <br /> dress mapping, for all delegated blocks a good set of secondaries delete: <br /> must be defined. There should be at least 2 nameservers for all delete: <br /> blocks delegated, excluding the RIPE NCC secondary. delete: <br /> delete: <br /> 3. The delegation of a class C block in the 193.in-addr.arpa delete: <br /> domain can be requested by sending in a domain object for the delete: <br /> RIPE database to <[email protected]> with all necessary contact delete: <br /> and nameserver information. The RIPE NCC will then forward all delete: <br /> current reverse zones inside this block to the registry, and delete: <br /> after addition of these by the registry, the NCC will check the delete: <br /> working of the reverse server. Once everything is setup proper- delete: <br /> ly, the NCC will delegate the block, and submit the database ob- delete: <br /> ject for inclusion in the database. An example domain object can delete: <br /> be found at the end of this document. delete: <br /> delete: <br /> 4. All reverse servers for blocks must be reachable from the delete: <br /> whole of the Internet. In short, all servers must meet similar delete: <br /> connectivity requirements as top-level domain servers. delete: <br /> delete: <br /> 5. Running the reverse server for class C blocks does not imply delete: <br /> that one controls that part of the reverse domain, it only im- delete: <br /> plies that one administers that part of the reverse domain. delete: <br /> delete: <br /> 6. Before adding individual nets, the administrator of a reverse delete: <br /> domain must check wether all servers to be added for these nets delete: <br /> are indeed setup properly. delete: <br /> delete: <br /> 7. There are some serious implications when a customer of a ser- delete: <br /> vice provider that uses address space out of the service provider delete: <br /> class C blocks, moves to another service provider. The previous delete: <br /> service provider cannot force its ex-customer to change network delete: <br /> addresses, and will have to continue to provide the appropriate delete: <br /> delegation records for reverse mapping of these addresses, even delete: <br /> though it they are no longer belonging to a customer. delete: <br /> delete: <br /> 8. The registration of the reverse zones for individual class C delete: <br /> networks will usually be done by the registry administering the delete: <br /> class C block this network has been assigned from. The registry delete: <br /> will make the necessary changes to the zone, and update the net- delete: <br /> work objects in the RIPE database for these networks, to reflect delete: <br /> the correct "rev-srv" fields. In case the RIPE NCC receives a delete: <br /> request for the reverse zone of an individual class C network out delete: <br /> of a block that has been delegated, the request will be forwarded delete: <br /> to the zone contact for this reverse block. delete: <br /> delete: <br /> 9. The NCC advises the following timers and counters for direct delete: <br /> subdomains of 193.in-addr.arpa: 8 hours refresh (28800 seconds), delete: <br /> 2 hours retry (7200 seconds), 7 days expire (604800 seconds) and delete: <br /> 1 day Time To Live (86400 seconds). The retry counter should be delete: <br /> lowered where connectivity is unstable. delete: <br /> delete: <br /> Above procedures are defined to ensure the necessary high availa- delete: <br /> bility for the 193 reverse domains, and to minimize confusion. delete: <br /> The NCC will ensure fast repsonse times for addition requests, delete: <br /> and will in principle update the 193.in-addr.arpa domain at least delete: <br /> once per working day. delete: <br /> delete: <br /> Example domain object to request a block delegation delete: <br /> delete: <br /> domain: 202.193.in-addr.arpa delete: <br /> descr: Pan European Organisations class C block delete: <br /> admin-c: Daniel Karrenberg delete: <br /> tech-c: Marten Terpstra delete: <br /> zone-c: Marten Terpstra delete: <br /> nserver: ns.eu.net delete: <br /> nserver: sunic.sunet.se delete: <br /> nserver: ns.ripe.net delete: <br /> changed: [email protected] 930319 delete: <br /> source: RIPE delete: <br /> delete: <br /> delete: <br /> delete: <br /> Procedures for the delegation of individual network zones by the delete: <br /> RIPE NCC. delete: <br /> delete: <br /> The registration of the reverse zones for individual class C net- delete: <br /> works will usually be done by the registry administering the delete: <br /> class C block this network has been assigned from. In case the delete: <br /> zone corresponding to the class C block has not been delegated, delete: <br /> the RIPE NCC will automatically add the reverse nameserver as delete: <br /> specified in the "rev-srv" attribute of the RIPE database object delete: <br /> for this network, using the following procedures: delete: <br /> delete: <br /> 1. Because of the increasing importance of correct reverse ad- delete: <br /> dress mapping, for all delegated networks a good set of secon- delete: <br /> daries must be defined. There should be at least two nameservers delete: <br /> for all networks delegated. delete: <br /> delete: <br /> 2. The "rev-srv" field should ONLY contain one fully qualified delete: <br /> domain name of a nameserver which is authoritative for the re- delete: <br /> verse zone for this network. delete: <br /> delete: <br /> 3. If a network has or is going to have any external connectivi- delete: <br /> ty, it is strongly recommended that it has at least one reverse delete: <br /> nameserver that can be reached from all of the Internet. delete: <br /> delete: <br /> 4. The checking and addition of the reverse zones for single net- delete: <br /> works is completely automated at the RIPE NCC. Although we do delete: <br /> our best to check the setup of the nameservers, these does not delete: <br /> receive the same level of scrutiny as nameservers for blocks of delete: <br /> class C network numbers. It is the responsibility of the network delete: <br /> contacts to ensure proper operation. delete: <br /> delete: <br /> 5. Any problems regarding the reverse zones in 193.in-addr.arpa delete: <br /> should be directed to <[email protected]>. delete: <br /> delete: <br /> The NCC also suggests that similar procedures are set up for the delete: <br /> delegation of reverse zones for individual class C networks from delete: <br /> the registries to individual organisations. delete: </p>