[ 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>