[rbldnsd] Re: rbldnsd 0.99 TTL issue

[Michael Tokarev]

[Cc'ing rbldnsd@ list - hope you don't mind]

Victor Duchovni wrote:
> When multiple datasets are combined into a zone, it is possible that the
> dataset TTL values are different. If two datasets with different TTLs each
> match a query, the reply might include RRsets with different TTLs within
> the same RR type. This is illegal, all the RRs in a single RRset must have
> the same TTL.

Well.. yes.  A good catch, Victor.

  5.2. TTLs of RRs in an RRSet

     Resource Records also have a time to live (TTL).  It is possible for
     the RRs in an RRSet to have different TTLs.  No uses for this have
     been found that cannot be better accomplished in other ways.  This
     can, however, cause partial replies (not marked "truncated") from a
     caching server, where the TTLs for some but not all the RRs in the
     RRSet have expired.

     Consequently the use of differing TTLs in an RRSet is hereby
     deprecated, the TTLs of all RRs in an RRSet must be the same.
     Should a client receive a response containing RRs from an RRSet with
     differing TTLs, it should treat this as an error.  If the RRSet
     concerned is from a non-authoritative source for this data, the
     client should simply ignore the RRSet, and if the values were
     required, seek to acquire them from an authoritative source.  Clients
     that are configured to send all queries to one, or more, particular
     servers should treat those servers as authoritative for this purpose.
     Should an authoritative source send such a malformed RRSet, the
     client should treat the RRs for all purposes as if all TTLs in the
     RRSet had been set to the value of the lowest TTL in the RRSet.  In
     no case may a server send an RRSet with TTLs not all equal.

And the description/clarification is way wrong IMHO too...  Ugh.

> 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.

> 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.

> I am combining list.dsbl.org and sbl.spamhaus.org into a single zone, and
> the two zones carry different TTLs. This said, perhaps I should not be
> combining the zones, but consolidating all the data into a single zone has
> various advantages...

Yes advantages, and main one is that only one query needed.

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 \
   ...

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... ;)

/mjt