[rbldnsd] Re: rbldnsd 0.99 TTL issue

[rbldnsd@corpit.ru]

On Mon, 6 Oct 2003, Michael Tokarev wrote:

> > It is not clear where the problem needs to be fixed. Either the TTL for
> > all A or TXT responses should be the least of any of the dataset TTLs,
> > computed as the packet is built (difficult), or perhaps instead the TTL
> > should be propagated out of the datasets and into the zone, with the zone
> > storing the lowest TTL from the various datasets. The packet can then use
> > the zone ttl instead of the dataset TTL.
>
> It is quite clear where to fix the problem - at the time when the
> reply packet gets constructed (it is easy, in contrary with your
> statement above - since rbldnsd already checks RRs in reply for
> uniqueness - rbldnsd_packet.c:aexists()).  But the real question
> is not WHERE, but HOW the problem may be fixed.  At the first
> throught, it seems that reply should contain smallest TTL of all
> RRs.  But at second, suppose you're combining e.g. dul and a list
> or proxies/relays - obviously, DUL may have larger TTL.
>

There is never any harm (other than increased query rate) in supplying a
smaller TTL for all RRs, but there is easily harm in supplying a larger
TTL. Supplying different TTLs is not an option, it is not OK to age half
of an RRset out of the cache, the nameserver must always return the full
RRset, so the TTL is *morally* the smallest TTL in the set. The spec could
require the client to make the response TTLs uniform (be liberal,
be conservative, ...), but it is still the case that the server MUST not
send non-uniform TTLs.

> > Thoughts? Patches? :-)  I am not familiar with this code yet, so I hope
> > that you are willing to provide a fix.
>
> Ok.  I'll think about this more, perhaps the right way to go is to
> use smallest TTL in case the result comes from different datasets.
> *Right* fix may require quite some changes - in particular, to
> change internal representation of TTL values (stored in network
> byte order currently) for easy comparisions.
>

When returning multiple records in an RRset the TTL should be the smallest
TTL of any matching dataset. If the comparisons will come out of the
dataset store in host byte order, if out of the packet, store in network
byte order and convert for comparison. The packet data will naturally be
in network byte order.

> There's another interesting issue with all the "metadata": it isn't
> easy to overwrite metadata (SOA, TTL, esp. NS records) that may be
> present in 3rd party data with local values.  For now, there's an
> easy workaround to force rbldnsd to use the TTL you want it to use.
> Set up additional file for every dataset you're combining with only
> one $TTL line in it, and add it as LAST file into every dataset:
>
> rbldnsd ... \
>    bl.example.com:ip4set:list.dsbl.org,ttl \
>    bl.example.com:ip4set:sbl.spamhaus.org,ttl \
>    ...
>

Thanks that is a reasonable work-around for now. I guess what I am asking
for is something more automatic, that reflects the minimum volatility of
datasets rsynced from third party sources.

> Note that TTL is a propery of a dataset, and *last* value will be
> used.  (For $SOA, *first* value will be used, and for $NS, *all*
> values will be used, so here's quite some inconsistency).  Again,
> throughts/suggestions for this problem are welcome... ;)
>

This makes sense, I don't recall running into this in the docs (which I
have read only in part thus far), but it is the only sensible default
behaviour. It might be nice to be able to suppress metadata explicitly
from a dataset, so it supplies data records only.

-- 
	Viktor.