Victor Duchovni:
> On Fri, May 06, 2005 at 04:00:43PM -0400, Wietse Venema wrote:
> 
> > Noel Jones:
> > > At 01:50 PM 5/6/2005, Victor Duchovni wrote:
> > > >On Fri, May 06, 2005 at 02:20:42PM -0400, Wietse Venema wrote:
> > > > > This would be an argument to keep the name check_ptr_access
> > > > > and to make clear that it is the dumbest possible lookup
> > > > > routine that doesn't even follow CNAMEs.
> > > >
> > > >Yes. The requirement is I think to handle unmodified PTR data from DNS
> > > >essentially as-is (modulo syntax issues below).
> > > 
> > > seems to me most userland tools will follow the CNAME unless you explicitly 
> > > tell them not to.
> > > I think CNAMEs should be resolved, if that fails, then "unknown".
> > 
> > Good point. The Postfix DNS client follows CNAMEs too, and will
> > report failure when the target of the CNAME is not found.  Turning
> > off CNAME expansion would involve a new option.
> 
> It follows CNAMEs in *keys*, I am not aware of any CNAME following
> when returning *data* (RHS values from DNS lookups).

The Postfix dns_lookup() routine looks up the specified resource
record type for the specified name. When the lookup result is a
CNAME record, it looks up the specified resource record type for
the name specified in the CNAME record. This process repeats for
a limited number of iterations, to avoid looping.

> > If we are to follow CNAMEs and sanitize the result, then we
> > might just as well use getnameinfo(), for consistency with
> > the hostname as used in logging and access control.
> 
> This has no good semantics when the PTR CNAME lookup fails.
> 
> Noel, we are not talking about computing the client name for logs or
> Received headers, we are (or is it I alone am???) talking about blocking
> strings found PTR records.

That could be. Blacklisting is very narrow. If possible, the
mechanism should also have reasonable semantics for whitelisting.

	Wietse