Re: lame delegations

[woods () weird com (Greg A. Woods)]

[ On Friday, August 18, 2000 at 15:55:42 (-0400), Alex Kamantauskas wrote: ]
> Subject: Re: lame delegations 
>
>
> On Fri, 18 Aug 2000, Gary E. Miller wrote:
>
> > RFC 1912, Sec 2.1:
> >
> > " Make sure your PTR and A records match.  For every IP address, there
> >    should be a matching PTR record in the in-addr.arpa domain.  If a
> >    host is multi-homed, (more than one IP address) make sure that all IP
> >    addresses have a corresponding PTR record (not just the first one).
> >    Failure to have matching PTR and A records can cause loss of Internet
> >    services similar to not being registered in the DNS at all.  Also,
> >    PTR records must point back to a valid A record, not a alias defined
> >    by a CNAME.  It is highly recommended that you use some software
> >    which automates this checking, or generate your DNS data from a
> >    database which automatically creates consistent data."
> >
> > I have yet to hear a convincing argument why this RFC should be
> > ignored.  I have seen many problems when this is ignored.
>
>  This raises a question that I've had for some time. This says that a "PTR
>  record must point to a valid A record, not an alias defined by a CNAME".
>  RFC 1035, Sec. 3.3.12 says that the PTRDNAME is a "<domain-name> which
>  points to some location in the domain name space" and that "PTR records
>  cause no additional section processing".  Since RFC 1035, Sec. 3.3 states
>  that a <domain-name> is just a label, and says nothing that the label has
>  to have a corresponding A record.  Since RFC 1912 is informational and
>  does not update RFC 1035, it would seem that a PTR record does *not* have
>  to point to a host that resolves.  
>
>  No?  Am I getting lost in the fine print?  Am I missing a later RFC that
>  clarifies this?

I think all you're missing is the connection between second sentence and
the fifth in the quoted paragraph -- i.e. all PTRs in the "in-addr.arpa"
domain must point back directly to valid A RRs.  PTRs in other domains
may point elsewhere, and indeed I use them myself:

        $ host -t ptr -l weird.com
        weird.com.              PTR     0.254.92.204.IN-ADDR.ARPA.
        weird.com.              PTR     160.161.29.204.IN-ADDR.ARPA.
        inverse-weird-bcast.weird.com.  PTR     255.254.92.204.IN-ADDR.ARPA.
        inverse-loopback.weird.com.     PTR     0.0.0.127.IN-ADDR.ARPA.
        inverse-weird-net.weird.com.    PTR     0.254.92.204.IN-ADDR.ARPA.

This kind of usage is defined and documented in RFC 1101, and is very
useful to do if you want tools like netstat to report useful names
instead of boring old network numbers.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>