Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!nikhefh!e07
From: e07@nikhefh.nikhef.nl (Eric Wassenaar)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Domain names in resource records (was: PTR records ...)
Message-ID: <1120@nikhefh.nikhef.nl>
Date: 16 Jan 91 09:56:37 GMT
Sender: e07@nikhef.nl (Eric Wassenaar)
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 38


RFC1034, 3.6.2 Aliases and canonical names, page 15, states:
"Domain names in RRs which point to another name should always
point at the primary name and not the alias."

This means that in records like
$ORIGIN your.domain.
foo	IN	NS	bar.your.domain.
foo	IN	MX	10 bar.your.domain.
'bar.your.domain' must NOT be a CNAME, but must have an A record.

An exception may be the CNAME record itself. In
foo	IN	CNAME	bar.your.domain.
'bar.your.domain' MAY be a CNAME. Queries for 'foo.your.domain'
must be restarted using 'bar.your.domain' (with robustness to
avoid loops) as stated in the same paragraph.

Conforming the abovementioned restriction, in
$ORIGIN x.y.z.in-addr.arpa.
n	IN	PTR	bar.your.domain.
'bar.your.domain' must NOT be a CNAME (see the example in the
same paragraph). But since PTR records are not followed, it can
do no real harm to specify anything you like (which is actually
done in practice already).

In fact, PTR records may point at other PTR records, as suggested
in RFC1101 to define network names, such as in constructions like
$ORIGIN x.y.z.in-addr.arpa.
0	IN	PTR	netname.your.domain.
$ORIGIN your.domain.
netname	IN	PTR	0.x.y.z.in-addr.arpa.

Eric Wassenaar
-- 
Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155
Internet: e07@nikhef.nl