John Rudd wrote:
RFC 1912, section 2.1, 2nd paragraph:
PTR records must point back to a valid A record, not a alias defined
by a CNAME.
This suggestion has been superceded, or perhaps better elucidated, by
later RFC's, particularly RFC 2181, section 10.2.
Nowadays many of us have reverse-DNS delegation in place since as an
end-user we have no control over the in-addr.arpa records for our
particular IP subnet. For instance, mail.cyways.com resolves to
12.148.244.151, but a reverse query for that address yields:
# host -t ptr 151.244.148.12.in-addr.arpa
151.244.148.12.in-addr.arpa is an alias for
151.128/27.244.148.12.in-addr.arpa.
151.128/27.244.148.12.in-addr.arpa domain name pointer mail.cyways.com.
That's because the 244.148.12.in-addr.arpa zone belongs to our provider
(AT&T), but they have delegated our /27 subnet's zone to us via this
aliasing process. RFC 2181 makes clear that aliasing is fine in the PTR
resolution process as long as the aliasing eventually points to a
canonical name like mail.cyways.com.
This is a much better solution than requiring us to go to the provider to
update their PTR records every time we change the names of the hosts in
our subnet. RFC's like 1912 reflect a time when most people had control
over both forward and reverse name service for a class-A, B, or C IP
block. That came to an end when "classless," or "CIDR," addressing
became the norm.
Peter
