Date: Thu, 19 Oct 1995 13:56:47 +1000 (EST) From: michael butler <imb@scgt.oz.au> To: fenner@parc.xerox.com (Bill Fenner) Cc: jdl@chromatic.com, freebsd-hackers@FreeBSD.ORG Subject: Re: DNS question Message-ID: <199510190356.NAA01958@asstdc.scgt.oz.au> In-Reply-To: <95Oct18.154837pdt.177478@crevenia.parc.xerox.com> from "Bill Fenner" at Oct 18, 95 03:48:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Fenner writes:
> >Is there a way to reliably claim to do DNS for anything less than
> >a full Class-C subnet?
> The best way to do this is to have the person who is primary for
> 166.1.199.in-addr.arpa insert records like:
> jdl IN NS jdl.com.
> 200 IN CNAME 200.jdl
> 201 IN CNAME 201.jdl
> 202 IN CNAME 202.jdl
> ...
> 207 IN CNAME 207.jdl
> And then you can build a database for jdl.166.1.199.in-addr.arpa and you can
> be authoritative.
> I am sure that this is documented somewhere but can't figure out where. The
> most recent time I heard it described was at the NANOG meeting a month or so
> ago, and the person describing it said that people have been doing this for
> years.
As follows ..
Network Working Group Havard Eidnes
INTERNET-DRAFT SINTEF RUNIT
draft-degroot-classless-inaddr-00.txt Geert Jan de Groot
RIPE NCC
May 1995
Classless in-addr.arpa delegation
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Should this draft end up being published as an RFC, then:
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Introduction
This document describes a way to do in-addr.arpa delegation on non-
octet boundaries. The proposed method should thus remove one of the
objections to do subnetting on non-octet boundaries but perhaps more
significantly, make it possible to assign IP address space in smaller
chunks than 24-bit prefixes without losing the ability to delegate
authority for the corresponding in-addr.arpa mappings. The proposed
method is fully compatible with the original DNS lookup mechanisms
specified in [1], i.e. there is no need to modify the lookup
algorithm used, and there should be no need to modify any software
which does DNS lookups either.
Eidnes, de Groot Expires 951124 [Page 1]
INTERNET-DRAFT Classless in-addr.arpa delegation May 1995
3. Motivation
With the proliferation of classless routing technology, it has become
feasible to assign address space on non-octet boundaries. In case of
a Very Small Organization with only a few hosts, assigning a full
24-bit prefix (what has traditionally been referred to as a ``class C
network number'') often leads to inefficient address space
utilization.
One of the problems encountered when assigning a longer prefix (less
address space) is that it seems impossible for such an organization
to maintain its own reverse (``in-addr.arpa'') zone autonomously. If
the reverse delegation problem is solved, perhaps the most important
objection to assignment of longer prefixes to unrelated organizations
can be removed.
Let us assume we have assigned the address spaces to three different
parties as follows:
192.0.2.0/25 to organization A
192.0.2.128/26 to organization B
192.0.2.192/26 to organization C
In the classical approach, this would lead to a single zone like
this:
$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
The administration of this zone is problematic. Authority for this
zone can only be delegated once, and this usually translates into
``this zone can only be administrated by one organization.'' The
other organizations with address space which corresponds to entries
in this zone would thus have to depend on another organization for
their address to name translation. With the proposed method, this
potential problem can be avoided.
Eidnes, de Groot Expires 951124 [Page 2]
INTERNET-DRAFT Classless in-addr.arpa delegation May 1995
4. Classless in-addr.arpa domain
Since a single zone can only be delegated once we need more points to
do delegation on to solve the problem above. These extra points of
delegation can be introduced by extending the in-addr.arpa tree
downwards, e.g. by using the first address in the corresponding
address space as the first component in the name for the zones. For
the problem described in the motivation section, the corresponding 4
zone files would look something like this (here shown with network
masks and network names in the form specified in [2] as well):
$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... )
;...
0 NS ns.A.domain.
0 NS some.other.name.server.
;
128 NS ns.B.domain.
128 NS some.other.name.server.too.
;
192 NS ns.C.domain
192 NS some.other.third.name.server.
;
1 CNAME 1.0.2.0.192.in-addr.arpa.
2 CNAME 2.0.2.0.192.in-addr.arpa.
3 CNAME 3.0.2.0.192.in-addr.arpa.
;
129 CNAME 129.128.2.0.192.in-addr.arpa.
130 CNAME 130.128.2.0.192.in-addr.arpa.
131 CNAME 131.128.2.0.192.in-addr.arpa.
;
193 CNAME 193.192.2.0.192.in-addr.arpa.
194 CNAME 194.192.2.0.192.in-addr.arpa.
195 CNAME 195.192.2.0.192.in-addr.arpa.
$ORIGIN 0.2.0.192.in-addr.arpa.
@ IN SOA ns.A.domain. hostmaster.A.domain. ( ... )
@ NS ns.A.domain.
@ NS some.other.name.server.
@ PTR networkname.A.domain.
@ A 255.255.255.128
;
1 PTR host1.A.domain.
2 PTR host2.A.domain.
3 PTR host3.A.domain.
Eidnes, de Groot Expires 951124 [Page 3]
INTERNET-DRAFT Classless in-addr.arpa delegation May 1995
$ORIGIN 128.2.0.192.in-addr.arpa.
@ IN SOA ns.B.domain. hostmaster.B.domain. ( ... )
@ NS ns.B.domain.
@ NS some.other.name.server.too.
@ PTR networkname.B.domain.
@ A 255.255.255.192
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
$ORIGIN 192.2.0.192.in-addr.arpa.
@ IN SOA ns.C.domain. hostmaster.C.domain. ( ... )
@ NS ns.C.domain
@ NS some.other.third.name.server.
@ PTR networkname.C.domain.
@ A 255.255.255.192
;
193 PTR host1.C.domain.
194 PTR host2.C.domain.
195 PTR host3.C.domain.
An obvious alternative to using the first address in the
corresponding address space to name the new zones is simply to use
some other (non-numeric) name. It is of course also possible to
point to an entirely different part of the DNS tree (outside of the
in-addr.arpa tree).
This approach makes it necessary to install approximately 256 CNAME
records in the parent zone more or less permanently for each size-256
chunk split up this way. Some people might view this as ugly; we
will not argue that particular point. It is however quite easy to
automatically generate the CNAME resource records in the parent zone
once and for all, if the way the address space is partitioned is
known.
The advantage of this approach over the other proposed approaches for
dealing with this problem is that there should be no need to modify
any already-deployed software. In particular, the lookup mechanism
in the DNS does not have to be modified to accommodate this splitting
of the responsibility for the IPv4 address to name translation on
``non-dot'' boundaries. This technique has been in use for several
years in at least one installation, apparently with no ill effects.
Eidnes, de Groot Expires 951124 [Page 4]
INTERNET-DRAFT Classless in-addr.arpa delegation May 1995
5. References
[1] P. Mockapetris, ``Domain Names - Concepts and Facilities'',
RFC1034, ISI, November 1987.
[2] P. Mockapetris, ``DNS Encoding of Network Names and Other
Types'', RFC1101, ISI, April 1989.
6. Security Considerations
Security considerations are not discussed in this memo.
7. Conclusion
The suggested scheme gives more flexibility in delegating authority
in the in-addr.arpa domain, thus making it possible to assign address
space more efficiently without losing the ability to delegate the DNS
authority over the corresponding address to name mappings.
8. Acknowledgments
Glen A. Herrmannsfeldt <gah@cco.caltech.edu> described this trick on
comp.protocols.tcp-ip.domains some time ago. Alan Barrett
<barrett@lucy.ee.und.ac.za>, Sam Wilson <Sam.Wilson@ed.ac.uk>, and
Paul Vixie <vixie@vix.com> provided valuable comments on the
newsgroup.
We would like to thank Eric Wassenaar of NIKHEF <e07@nikhef.nl>,
David Kessens <David.Kessens@ripe.net>, Daniel Karrenberg
<Daniel.Karrenberg@ripe.net>, Paul Vixie <paul@vix.com>, and Glen A.
Herrmannsfeldt <gah@cco.caltech.edu> for their review and
constructive comments.
Eidnes, de Groot Expires 951124 [Page 5]
INTERNET-DRAFT Classless in-addr.arpa delegation May 1995
9. Author's Addresses
Havard Eidnes
SINTEF RUNIT
N-7034 Trondheim
Norway
Phone: +73 59 44 68
Fax: +73 59 17 00
Email: Havard.Eidnes@runit.sintef.no
Geert Jan de Groot
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam, the Netherlands
Phone: +31 20 592 5065
Fax: +31 20 592 5090
Email: GeertJan.deGroot@ripe.net
Eidnes, de Groot Expires 951124 [Page 6]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510190356.NAA01958>