On Fri, Nov 05, 2010 at 12:27:06PM -0400, Wietse Venema wrote:
> > Should we mention that these should only be used to reduce FPs from
> > blacklists that follow, and that are expected to not list legitimate
> > clients. Thus any temporary DNS lookup error would likely result an an
> > additional lookup that incurrs a low risk or rejection, but does *imply*
^^^
Missed a: not
> > rejection. DNS-based positive access rules are fragile with respect
> > to the semantics of temporary lookup failures, and must not be used to
> > permit some while denying all.
>
> I agree that whitelisting on client names is fragile (whether one
> uses a static whitelist map or DNS lookups), because the client
> name lookup will sometimes fail due to some temporary error. The
> DEFER_IF_REJECT result cited above handles only whitelist lookup
> problems; it is easy enough to hard-code the same in permit_*wl_client
> for temporary client name lookup problems, but I see no easy way
> to automatically fall back to DEFER_IF_REJECT for all name-based
> mechanisms.
This strategy upgrades all temporary name lookup problems to
DEFER_IF_REJECT when a "permit_rhswl_client" is encountered before a
reject action. This has the unfortunate effect of making all invalid
traffic from systems with broken DNS retry. I think this is not viable,
that the better option is to have a fragile whitelist, which sometimes
fails to whitelist, but that's OK, because one expects the blacklists
to not list the good guys. We are changing the FP rate, not promising
zero FPs.
In any case, this needs a bit of care in documentation and perhaps
design.
--
Viktor.
