European Internet Registry:

                   Procedures for DNS Delegation

                     in the IN-ADDR.ARPA Domain



                           David Kessens

                             June 1994

                       Document-ID: ripe-105++
                         Obsoletes: ripe-105




                              ABSTRACT

           
Abstract
 This document describes the procedures for the
      delegation of zones in European subdomains of
      IN-ADDR.ARPA.



Introduction


The domain tree below IN-ADDR.ARPA is used to facilitate "reverse"
mapping from IP addresses to domain names [RFC883, RFC1033].  RIPE community's current IPv4 address allocation and assignment policies. They were developed through a bottom-up, consensus driven, open policy development process in the RIPE Address Policy Working Group (AP WG). The RIPE Network Coordination Centre (RIPE NCC) facilitates and supports this process. These policies apply to the RIPE NCC and the Local Internet Registries (LIRs) within the RIPE NCC service region.
Information on the Address Policy WG is available at:
https://www.ripe.net/participate/ripe/wg/ap Link: https://www.ripe.net/community/wg/active-wg/ap/ 
1.0 Introduction
The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. The distribution of IP space follows the hierarchical scheme described in the document "Internet Registry System Link: /community/internet-governance/internet-technical-community/the-rir-system/ ".
1.1 Scope
 This
document describes the procedures for the delegation of zones in
European subdomains of IN-ADDR.ARPA.


Randomly Assigned Numbers


There are two groups of European network numbers: hierarchically assigned
numbers and randomly assigned ones. The hierarchically assigned numbers
are part of the 193.x.y.0 and 194.x.y.0 network blocks. All other
European network numbers, class A, class B and 192.x.y.0 class Cs are
randomly assigned.


Hierarchically Assigned Numbers

The subdomains of IN-ADDR.ARPA corresponding to the hierarchically
assigned network numbers are administered by the RIPE NCC.  These
numbers are currently:


        193.0.0.0 - 194.255.255.255


The other addresses are administered by the other regional registries
that might have other procedures for requesting a reverse delegation.

For clarity we refer in the procedures and examples as described below to
the 193.x block of addresses, although we could have as well used the
other block(s) that RIPE administers.

With the assignment of class C network numbers following RFC1466,
large chunks of the address space are delegated to regional Internet
Registries. The regional registries delegate blocks of class C net-
work numbers to local Internet Registries. In this way a hierarchy
in policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. The policies documented here apply to all IPv4 address space allocated and assigned by the RIPE NCC. These policies must be implemented by all RIPE NCC member LIRs.
This document does not describe policies related to AS Numbers, IPv6, Multicast, or private address space. Nor does it describe address distribution policies used by other RIRs. The RIPE community's policies for ASN assignment and IPv6 are published in the RIPE Document Store at: 
https://www.ripe.net/publications/docs/ripe-policies/ Link: https://www.ripe.net/publications/docs/ripe-policies/ 
2.0 IPv4 Address Space
For the purposes of this document, IP addresses are 32-bit binary numbers used as addresses in the IPv4 protocol. There are three main types of IPv4 addresses:
Public IP addresses are distributed to be globally unique according to the goals described in Section 3 of this document. The two types of IPv4 address described in this document are Provider Aggregatable (PA) and Provider Independent (PI).
Some address ranges are set aside for the operation of private IP networks. Anyone may use these addresses in their private networks without registration or co-ordination. Hosts using these addresses cannot directly be reached from the Internet. Such connectivity is enabled by using the technique known as Network Address Translation (NAT). Private addresses restrict a network so that its hosts only have partial Internet connectivity. Where full Internet connectivity is needed, unique, public addresses should be used. 
For a detailed description of “Address Allocation for Private Internets” and the actual ranges of addresses set aside for that purpose, please refer to RFC 1918 found at: ftp://ftp.ripe.net/rfc/rfc1918.txt Link: ftp://ftp.ripe.net/rfc/rfc1918.txt 
For information on the “Architectural Implications of NAT”, please refer to RFC 2993, found at: ftp://ftp.ripe.net/rfc/rfc2993.txt Link: ftp://ftp.ripe.net/rfc/rfc2993.txt 
Some address ranges are reserved for special use purposes. These are described in the IANA IPv4 Special-Purpose Address Registry Link: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml and are beyond the scope of this document. 
3.0 Goals of the Internet Registry System
Public IPv4 address assignments should be made with the following goals in mind:
Uniqueness: Each public IPv4 address worldwide must be unique. This is an absolute requirement guaranteeing that every host on the Internet can be uniquely identified.
Aggregation: Distributing IPv4 addresses in an hierarchical manner permits the aggregation of routing information. This helps to ensure proper operation of Internet routing.
Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks.
Registration: The provision of a public registry documenting address space allocations and assignments must exist. This is necessary to ensure uniqueness and to provide information for Internet troubleshooting at all levels.
3.1 Confidentiality
Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR. When necessary, the information may be passed to a higher-level IR under the same conditions of confidentiality.
3.2 Language
Please note that all communication with the RIPE NCC must be in English.
4.0 Registration Requirements
All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. 

Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).
5.0 Policies and Guidelines for Allocations
An allocation is a block of IPv4 addresses from which assignments are taken.
All LIRs receiving address space from the RIPE NCC must adopt a set of policies that are consistent with the policies formulated by the RIPE community and described in this document.
5.1 Allocations made by the RIPE NCC to LIRs
Details of how to join the RIPE NCC can be found in the RIPE Document "Procedure for Becoming a Member of the RIPE NCC Link: /membership/member-support/become-a-member/ "
On application for IPv4 resources LIRs will receive IPv4 addresses according to the following:
All allocation requests are placed on a first-come-first-served waiting list. No guarantees are given about the waiting time.
The size of the allocation made will be exactly one /24.
The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy.
In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again.
5.2 Address Recycling
Any IPv4 address space that was originally assigned by the RIPE NCC for exclusive use by Internet Exchange Points (IXPs) will be added to the reserved IXP pool upon return.
Other address space blocks of a /24 or larger that are returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1 – smaller blocks will be put into the reserved pool for IXP use.
This section only applies to address space that is returned to the RIPE NCC and that will not be returned to the IANA but re-issued by the RIPE NCC itself.
5.3 Sub-allocations
Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0.
LIRs wishing to convert their allocations to PA status must contact the RIPE NCC by email at lir-help@ripe.net Link: mailto:lir-help@ripe.net  or via the LIR Portal at https://my.ripe.net Link: https://my.ripe.net .
LIRs may make sub-allocations to multiple downstream network operators.
The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.
Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is created, which is similar to the hierarchy
in the domain name space. Due to this hierarchy the reverse DNS map-
ping 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,
instead 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 delegations in turn will be done by the RIPE NCC.

Even better, since local registries usually receive blocks of 256 class C
networks from the RIPE NCC, the 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 InterNIC or the NCC, but
the service providers 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 improves the service a provider can offer its
customers by improving response times for reverse mapping changes.

In order to provide a reliable service some procedures have been agreed
and must be followed in order to avoid confusion and inconsistencies.
These procedures are covered in the procedure section.

The registration of the reverse zones for individual class C net-
works will  usually  be  done  by the registry administering the
class C block this network has been assigned from.

If the subdomain has not yet been delegated to the registry con-
cerned the RIPE NCC will register the individual networks. However
this service is only provided at a "best-effort" level and no ser-
vice guarantees are given.  The local registries should whenever
possible provide this service locally.


Responsibilities for the DNS administrator of a reverse block delegation:


As with all domain name space, 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. If
after repeated complaints the delegated name space is still not
administered properly the RIPE NCC has to revoke the delegation.

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

There are some serious implications when a customer that uses
address space out of the service provider class C blocks, moves
to another service provider. The  not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.
5.4 Transfers of Allocations
The transfer of Internet number resources is governed by the RIPE Document, "RIPE Resource Transfer Policies Link: http://www.ripe.net/publications/docs/transfer-policies ".
6.0 Policies and Guidelines for Assignments
6.1. Assignments to Internet Exchange Points
A /15 will be held in reserve for exclusive use by Internet Exchange Points (IXPs). On application for IPv4 resources, an IXP will receive a single number resource block according to the following:
Organisations receiving space under this policy must be IXPs and must meet the definition as described in section two of the RIPE Document "IPv6 Address Space for Internet Exchange Points Link: http://www.ripe.net/publications/docs/ipv6-policy-ixp ".
This space will be used to run an IXP peering LAN only; other uses are forbidden.
Assignments will only be made to IXPs that have applied for an IPv6 assignment for their peering LAN (or have already received one).
New IXPs will be initially assigned a /26 by default. Once more than 50% of the initial assignment has been utilised, IXPs can request an assignment up to a /24. In this case, the IXP must return the existing assignment (or existing PI previously issued for their IXP peering LAN).
Once IXPs require an assignment larger than /24, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.
If there are no more assignments of /26 available, smaller assignments can be made.
IXPs holding other PI IPv4 space for their peering LAN (i.e. they are seeking a larger assignment), and any IPv4 space assigned from this pool that is no longer in use, must be returned to the pool within 180 days of disuse or a new assignment. 
6.2 Network Infrastructure and End User Networks
When an LIR holding an IPv4 address allocation makes IPv4 address assignments, it must register these assignments in the RIPE Database.
These registrations can either be made as individual assignments or by inserting an object with a status value of 'AGGREGATED-BY-LIR'.
In case of an audit, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'AGGREGATED-BY-LIR'.
6.3 Validity of an Assignment
An assignment is valid as long as the original criteria on which it was based remain valid and it is properly registered in the RIPE Database. Changes to the original criteria must be documented in the RIPE Registry, or the assignment will no longer be considered valid. An assignment that was based on information that turns out to be incorrect is no longer valid.
6.4 Transfers of PI space
The transfer of Internet number resources is governed by the RIPE Document, "RIPE Resource Transfer Policies Link: http://www.ripe.net/publications/docs/transfer-policies ".
7.0 Types of Address Space
LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous 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
they are no longer belonging to a customer.

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 must be returned and the network renumbered.
Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:
Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.
LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:
ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider.
ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist.
ALLOCATED-ASSIGNED PA: This address space has been allocated to an LIR and entirely assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR.
SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider.
LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnummust be registered.
LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries.
ASSIGNED PA: This address space has been assigned from.  The
registry will make the necessary changes to the zone files.
The registry will also make sure that the network objects in
the RIPE database for these networks are updated with the
correct "rev-srv" attributes.

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 mailbox speci-
field in the SOA RR for the zone concerned and to the zone-
contact registered in the RIPE database for that zone.

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









Procedures


The procedure for asking the reverse delegation of a block (256 C's) of
addresses or network (1 or more C's) addresses is quite similar but there
are some differences. Therefor they are described as one procedure with
clear remarks when something only applies for block or network delegations.
Note that we will be a little bit more stringent on the rules for block
delegations since we need to be sure that other people can rely on you
for proper operation of the DNS system.

Above procedures are defined to ensure the necessary high availabil- ity
for the reverse domains, and to minimise confusion.  The NCC will ensure
fast response times for addition requests, and will in principle update
the 193.IN-ADDR.ARPA domain at least once per working day, if needed. Any
problems regarding the reverse zones in 193.IN-ADDR.ARPA should be
reported to <inaddr@ripe.net>.



 1.  We only reverse delegate when all addresses are assigned to you.

 2.  Your nameservers should be configured and running and should have
     good reachability on the internet. Nameservers for block delegations
     must meet similar connectivity requirements as top-level domain
     servers.

     The NCC recommends to use the following timers and counters (as
     advised by RFC1537):

	 28800	;refresh period (8 hours)
	 7200	;retry interval (2 hours)
	 604800	;expire time    (1 week)
	 86400	;default ttl    (1 day)

     It is mandatory for network (C) reverse delegations:

     - ns.ripe.net is NOT one of the secondary/primary nameservers

     - at least two nameservers should be used

     - We need a RIPE database 'inetnum' object with 'rev-srv:'
       attributes for the name (not IP address) of each nameserver.


     It is mandatory for block reverse delegations:

     - ns.ripe.net is one the secondary (never primary) nameservers

     - at least two other nameservers that don't reside on the same
       ethernet are required

     - Operators of the primary nameservers should be familiar with
       RFC1537 and this document

     - We need a RIPE database 'domain' object for each delegation
       with 'nserver:' attributes for the name (not IP address) of each
       nameserver


 3.  Send an E-mail request to <auto-inaddr@ripe.net> with:

     - In the header (or body if not possible) of your E-mail message:

       X-NCC-RegID: Country.RegistryName

       This is not required, though easy for keeping track of the
       requests. Of course, we don't need your local registry ID if you
       are not from a RIPE local registry.

     For network (C) reverse delegations:

     - We need a RIPE database 'inetnum' object with 'rev-srv:'
       attributes for the name (not IP address) of each nameserver

     For block reverse delegations:

     - State in your request that you know about RFC1537 & this document

     - A RIPE database 'domain' object for each delegation
       with 'nserver:' attributes for the name (not IP address) of each
       nameserver

 4.  Your request will first go through to an automatic checking program.
     The program will check your zone files and report you about errors
     (that should be fixed), warnings (that you might want to change), or
     that no errors have been found. If errors are found, you will be
     asked to fix them and resubmit your request and the automatic checks
     will be done again.

     If no errors (warnings are allowed, but we strongly suggest that you
     at least take a look at them) are found your request will be
     acknowledged and your request will be forwarded to the person in
     charge of the reverse delegation requests. He/she processes the
     request further. If no additional problems are found the object will
     included in the database and the block/network reverse delegated.
     You will always receive an acknowledgment when the delegation has
     been done or an explanation why not.


Example of a network delegation request:


From: "Anne X. Ample" <anne.x.ample@ample.nl>
To: RIPE Hostmaster <auto-inaddr@ripe.net>
Subject: LONGACK 2.1.193.in-addr.arpa delegation please

Please delegate 2.1.193.in-addr.arpa as specified below.

Thank you!

For the AMPLE Corporation

Anne X. Ample


inetnum:   193.1.2.0 - 193.1.3.255
netname:   AMPLE
descr:     AMPLE Corporation
descr:     Amsterdam, Netherlands
country:   NL
admin-c:   Anne X. Ample
tech-c:    G. E. K. Ample
aut-sys:   4711
rev-srv:   ns.ample.nl
rev-srv:   ns.elpma.ln
changed:   anne.x.ample@ample.nl 930101
source:    RIPE



Example of a block (256 C's) reverse delegation:


From: Marten Terpstra <marten@in.ter.net>
To: RIPE Hostmaster <auto-inaddr@ripe.net>
Subject: LONGACK 202.193.in-addr.arpa delegation please


Dear NCC people,

I have read and understood ripe-105++ and RFC1537.
Could you please delegate 202.193.in-addr.arpa as specified below.

Thank you!

Marten Terpstra


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@ripe.net 930319
source:  RIPE



Some notes on the automatic checking program:

You can use some keywords in the 'Subject:' line of your E-mail to
control the checking process. The use of the LONGACK keyword is very
recommended. For changing an existing delegation put the keyword CHANGE
in the 'Subject:' line of your E-mail message.

HELP    - will send you this document
CHANGE  - is needed if you want to change an existing reverse delegation
LONGACK - will give you the most verbose output as possible
TEST    - will only test your zone files without actually doing
          the request


When you want to to a request for a block delegation and you want to know
if there are already reverse zones registered within the zone of the
requested block delegation, just send in your request and you will
receive an error report that includes a copy of our zone file regarding
this zone! 

Registering an inetnum object with a status of “ALLOCATED-ASSIGNED PA” or "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status.

Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate.

In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.

The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.

8.0 LIR Audit

The RIPE community asked the RIPE NCC to audit LIR operations and ensure consistent and fair implementation of the community's policies. Details of this activity are described in the RIPE Document "RIPE NCC Audit Activity" found at: http://www.ripe.net/ripe/docs/audit Link: http://www.ripe.net/ripe/docs/audit

9.0 Closing an LIR by the RIPE NCC

The RIPE NCC may close an LIR for any of the following reasons:

• the LIR does not pay money owed to the RIPE NCC
• the LIR cannot be contacted by the RIPE NCC for a significant period of time
• the LIR consistently violates the RIPE community's policies

The RIPE NCC takes on responsibility for address space held by closing LIRs.