RR for subnet
Kevin Darcy
kcd at daimlerchrysler.com
Tue Jul 25 15:57:42 UTC 2000
The RFC that this draft became, of course, was RFC 2317, also known as BC=
P (Best
Current Practice) 20.
- Kevin
dnsadmin at ttd.net wrote:
> Hi.
>
> Here is the draft for clasless delegation.
>
> Bye.
>
> Adolfo Ranero Serrano
>
> On Tue, 25 Jul 2000, [iso-8859-2] Hrbek Lud=ECk wrote:
>
> > Date: Tue, 25 Jul 2000 11:34:30 +0200
> > From: "[iso-8859-2] Hrbek Lud=ECk" <Hrbek at metrostav.cz>
> > To: "'bind-users at isc.org'" <bind-users at isc.org>
> > Subject: RR for subnet
> >
> > Hi,
> >
> > I've problem with RR for one subnet. What have to be in /etc/named.co=
nf
> > (zone name) and in /var/named/zone.rev ($ORIGIN,NS,PTR) on delegated =
DNS for
> > subnet 192.168.0.0/27. Could give anyone some sample named.conf and z=
one
> > file (with comments ;).
> >
> > Thank's
> >
> > Ludek
> >
> >
> >
> >
>
> -(dnsadmin at ttd.net)----------------------------------------------------=
------
> | Tlf: +34 91 456 66 66 Telefonica Data Espan~a. =
|
> | Fax: +34 91 456 63 59 Beatriz de Bobadilla 18, 1 planta, 28040-M=
ADRID|
> -----------------------------------------------------------------------=
------
>
> -- Attached file included as plaintext by Listar --
> -- File: draft_classless_delegation
>
> >From root at unspecified-domain Mon May 11 16:01:49 1998
> Date: Mon, 11 May 1998 10:43:22 +0200 (MET DST)
> From: root at unspecified-domain
>
> Network Working Group Havard Eidnes
> INTERNET-DRAFT SINTEF RUNIT
> draft-ietf-cidrd-classless-inaddr-01.txt Geert Jan de Groot
> RIPE NCC
>
> May 1996
>
> 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 month=
s
> 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 Shado=
w
> 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).
>
> 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 subnet on non-octet boundaries but perhaps more
> significantly, make it possible to assign IP address space in smalle=
r
> 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.
>
> The document also discusses some operational considerations to
> provide some guidance in implementing this method.
>
> Eidnes, de Groot Expires 961115 [Page 1=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> 3. Motivation
>
> With the proliferation of classless routing technology, it has becom=
e
> feasible to assign address space on non-octet boundaries. In case o=
f
> 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. B=
y
> use of the reverse delegation method described below, 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 administered 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 961115 [Page 2=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> 4. Classless in-addr.arpa delegation
>
> Since a single zone can only be delegated once we need more points t=
o
> 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 961115 [Page 3=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> $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.
>
> Note that the use of network masks and network names as specified in
> [2] is optional, and that it is just shown here as an illustration.
>
> This approach to splitting up the responsibility for maintaining the
> in-addr.arpa mappings makes it necessary to install approximately 25=
6
> 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 fo=
r
> 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 splittin=
g
> of the responsibility for the IPv4 address to name translation on
> ``non-dot'' boundaries. Furthermore, this technique has been in use
> for several years in at least one installation, apparently with no
> ill effects.
>
> Eidnes, de Groot Expires 961115 [Page 4=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> 5. Operational considerations
>
> As a result of this method, the location of the zone containing the
> actual PTR records is no longer predefined. This gives flexibility
> and some examples will be presented here.
>
> 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 (e.g. outside of
> the in-addr.arpa tree). It would be necessary to use one of these
> alternate methods if two organizations somehow shared the same
> physical subnet (and corresponding IP address space) but still wante=
d
> to administrate their own in-addr.arpa mappings.
>
> The following short example shows how you can point out of the in-
> addr.arpa tree:
>
> $ORIGIN 2.0.192.in-addr.arpa.
> @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... )
> ; ...
> 1 CNAME 1.A.domain.
> 2 CNAME 2.A.domain.
> ; ...
> 129 CNAME 129.B.domain.
> 130 CNAME 130.B.domain.
> ;
>
> $ORIGIN A.domain.
> @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... )
> ; ...
> ;
> host1 A 192.0.2.1
> 1 PTR host1
> ;
> host2 A 192.0.2.2
> 2 PTR host2
> ;
>
> etc.
>
> Done this way you can actually end up with the name->address and the
> (pointed-to) address->name mapping data in the same zone file -- som=
e
> may view this as an added bonus as no separate set of secondaries fo=
r
> the reverse zone is required. Do however note that the traversal vi=
a
> the in-addr.arpa tree will still be done, so the CNAME records
> inserted there need to point in the right direction for this to work.
>
> Eidnes, de Groot Expires 961115 [Page 5=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> An approach as sketched below is an alternative approach using the
> same solution:
>
> $ORIGIN 2.0.192.in-addr.arpa.
> @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... )
> ; ...
> 1 CNAME 1.2.0.192.in-addr.A.domain.
> 2 CNAME 2.2.0.192.in-addr.A.domain.
>
> $ORIGIN A.domain.
> @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... )
> ; ...
> ;
> host1 A 192.0.2.1
> 1.2.0.192.in-addr PTR host1
> host2 A 192.0.2.2
> 2.2.0.192.in-addr PTR host2
>
> It is clear that many possibilities exist which can be adapted to th=
e
> specific requirements of the situation at hand.
>
> Note that one cannot provide CNAME referrals twice for the same
> address space, i.e. an ISP can't allocate a /25 prefix to one
> organisation, and run in-addr.arpa this way, and then have the
> organisation subnet the /25 into longer prefixes, and attempt to
> employ the same technique to give each subnet control of its own
> number space. This would result in a CNAME record pointing to a CNAM=
E
> record, which is generally considered bad practice.
>
> Unfortunately, some old beta releases of the popular DNS name server
> implementation BIND 4.9.3 had a bug which caused problems if a CNAME
> record was encountered when a reverse lookup was made. The beta
> releases involved have since been obsoleted, and this issue is
> resolved in the released code. Some software manufacturers have
> included the defective beta code in their product. In the few cases
> we know of, patches from the manufacturers are available or planned
> to replace the obsolete beta code involved.
>
> 6. 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.
>
> Eidnes, de Groot Expires 961115 [Page 6=
]
>
> INTERNET-DRAFT Classless in-addr.arpa delegation May 199=
6
>
> 7. Security Considerations
>
> Security considerations are not discussed in this memo.
>
> 8. Conclusion
>
> The suggested scheme gives more flexibility in delegating authority
> in the in-addr.arpa domain, thus making it possible to assign addres=
s
> space more efficiently without losing the ability to delegate the DN=
S
> authority over the corresponding address to name mappings.
>
> 9. Acknowledgments
>
> Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
> ip.domains some time ago. Alan Barrett, Sam Wilson, and Paul Vixie
> provided valuable comments on the newsgroup.
>
> We would like to thank Rob Austein, Randy Bush, Matt Crawford, Glen
> A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul
> Mockapetris, Paul Vixie, Eric Wassenaar, Michael Patton, and Peter
> Koch for their review and constructive comments.
>
> 10. Author's Addresses
>
> Havard Eidnes
> SINTEF RUNIT
> N-7034 Trondheim
> Norway
>
> Phone: +47 73 59 44 68
> Fax: +47 73 59 17 00
>
> Email: Havard.Eidnes at 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 at ripe.net
>
> Eidnes, de Groot Expires 961115 [Page 7=
]
More information about the bind-users
mailing list