|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: lame delegations
[ 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 <[email protected]> <robohack!woods> Planix, Inc. <[email protected]>; Secrets of the Weird <[email protected]>
|