7. Domain Service considerations
One aspect of Internet services which will be notably affected by a
move to either "supernetted" class-C network numbers or subdivided
class-A's will be the mechanism used for address-to-name translation:
the IN-ADDR.ARPA zone of the domain system. Because this zone is
delegated on octet boundaries only, any address allocation plan which
uses bitmask-oriented addressing will cause some degree of difficulty
for those which maintain parts of the IN-ADDR.ARPA zone.
7.1 Procedural changes for class-C "supernets"
At the present time, parts of the IN-ADDR.ARPA zone are delegated
only on network boundaries which happen to fall on octet boundaries.
To aid in the use of blocks of class-C networks, it is recommended
that this policy be relaxed and allow the delegation of arbitrary,
octet-oriented pieces of the IN-ADDR.ARPA zone.
As an example of this policy change, consider a hypothetical large
network provider named "BigNet" which has been allocated the 1024
class-C networks 199.0.0 through 199.3.255. Under current policies,
the root domain servers would need to have 1024 entries of the form:
0.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
....
255.3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
By revising the policy as described above, this is reduced only four
delegation records:
0.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
1.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
2.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
3.199.IN-ADDR.ARPA. IN NS NS1.BIG.NET.
Fuller, Li, Yu & Varadhan [Page 20]
RFC 1519 CIDR Address Strategy September 1993
The provider would then maintain further delegations of naming
authority for each individual class-C network which it assigns,
rather than having each registered separately. Note that due to the
way the DNS is designed, it is still possible for the root
nameservers to maintain the delegation information for individual
networks for which the provider is unwilling or unable to do so. This
should greatly reduce the load on the domain servers for the "top"
levels of the IN-ADDR.ARPA domain. The example above illustrates
only the records for a single nameserver. In the normal case, there
are usually several nameservers for each domain, thus the size of the
examples will double or triple in the common cases.
7.2 Procedural changes for class-A subnetting
Should it be the case the class-A network numbers are subdivided into
blocks allocated to transit network providers, it will be similarly
necessary to relax the restriction on how IN-ADDR.ARPA naming works
for them. As an example, take a provider is allocated the 19-bit
portion of address space which matches 10.8.0.0 with mask
255.248.0.0. This represents all addresses which begin with the
prefixes 10.8, 10.9, 10.10, 10.11, 10.12, 10.13, 10.14, an 10.15 and
requires the following IN-ADDR.ARPA delegations:
8.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
9.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
....
15.10.IN-ADDR.ARPA. IN NS NS1.MOBY.NET.
To further illustrate how IN-ADDR.ARPA sub-delegation will work,
consider a company named "FOO" connected to this provider which has
been allocated the 14-bit piece of address space which matches
10.10.64.0 with mask 255.255.192.0. This represents all addresses in
the range 10.10.64.0 through 10.10.127.255 and will require that the
provider implement the following IN-ADDR.ARPA delegations:
64.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
65.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
....
127.10.10.IN-ADDR.ARPA. IN NS NS1.FOO.COM.
with the servers for "FOO.COM" containing the individual PTR records
for all of the addresses on each of these subnets.
Fuller, Li, Yu & Varadhan [Page 21]