Should we decrease the TTL on the rbldnsd version of multi.surbl.org?
For some background on the issue, rbldnsd does not support setting individual TTLs per record for dnset type zones, so we could not set individual TTLs on the rbldnsd records in multi.surbl.org, so the TTL for all records in the rbldnsd version of multi are the default for the entire file which is currently 28800 (8 hours).
Obviously that's quite a bit longer than the 90 minutes now used on ws or the 10 minutes for sc, so some multi/rbldnsd records may be longer-lived than their BIND versions. This is in conflict with the fact that we can and do set individual TTLs per record in the *BIND* version of multi. So a particular record in BIND multi versus rbldnsd multi may very likely have different TTLs, which is an asymmetry and somewhat inelegant. In other words a server that uses BIND may not give the same TTL for a given entry that an rbldnsd one would.
One solution to this would be to drop the default rbldnsd TTL for multi to something short like 10 minutes to force them all to expire quickly. Does anyone have any thoughts about this? Would this result in a lot more DNS traffic in general?
I could probably read the RFCs or source code, but does anyone know if DNS implementations cache negative hits to the default TTL. In other words if a new record gets added to a list, do caching name servers (that negatively cached it before, i.e., got queried and said "I don't have that") get the new record immediately or only after some TTL expires.
Jeff C.