[rbldnsd] Associating TTL to some NXDOMAIN replies

[Andrea Riguardi]

Hi,
we're trying to complete an assessment of the various thing that are or
may be needed/useful in a massively IPv6 world and some features are
coming out (again?).


This time it's the turn of negative replies and their TTL.

The question/request is:
is there a chance to support whitelisting entries with their own TTL
(obviously different from the one in the SOA)?

It should be possible, as NXDOMAIN packets leave with their own
AUTHORITY section containing the SOA so -in theory- each packet could
actually leave with a different SOA and therefore a different TTL.
That SOA is not going to be cached AFAICT and will only be used with
regard to the TTL of NXDOMAIN for the requested RR.
So it shouldn't collide with the "real SOA" of the zone either.


But maybe I'm missing some cache/RR interactions somewhere, so opinions,
objections and RTFM are welcome...



----------------------------------------------------------------------

The reasoning behind this request is a bit pessimistic perhaps, but here
it is:

given the address space size with IPv6, cache efficiency is probably
going to drop dramatically, at least for some kind of emitters.

As a result, there may also be the need to drop the TTLs to zero, in
order to avoid blowing up resolvers' cache if some conditions arise.
We've already observed snowshoers sending from tens of millions of
*/64s* at the same time in the last few months and all the DNSBL queries
caused by lookups of those senders can easily pose a problem for
resolvers, if they're going to enter the cached.  Not that we're there
yet, but better being prepared.

In such a scenario, dropping the TTL to zero would save the situation,
at the price of a higher load on the rbldnsd instances (easily
manageable, though) and a higher average latency in DNSBL lookups.

Both could be mitigated (in part) by leaving a TTL higher than zero for
some portions of the IPv6 space, both for positive and negative replies.

For example: I know where Gmail's outbound MTAs are, I know they
generate a lot of traffic (hence a lot of queries asking for them) and I
know they're not going to be listed in any case. What I could do is
therefore to preemptively create a whitelisting entry and associate it
to a high TTL, so at least emails coming from them will take advantage
of (NXDOMAIN) caching as usual...

But even without the zero-TTL thing, providing higher TTL'd NXDOMAINs
for known good sources could be useful...


Best Regards

-- 
Andrea Riguardi
Spamhaus Technology