Calle is correct, you aren't going to get BIND to violate TTL (aside from lowering the maximum, which doesn't help here). That said, if your ISP is so bad that you can't reliably hit the forwarders, I'm not really sure what the value in using forwarders is supposed to be.
Many domains offer more authoritative nameservers than the number of forwarders that typically end up being configured (2). This in turn means more more opportunities for the query to get a response in a scenario where you're seeing packet loss. It seems to me that you get more mileage out of doing the recursion yourself than using a forwarder config.
You might also want to try a newer version of BIND that supports the prefetch feature. Combined with doing your own recursion, the server will automatically try to perform a refresh against all nameservers for the record immediately prior to the record expiring from cache. This only happens if a query arrives shortly before the record is due to expire, but it may still be of help here.
When a query is received for cached data which is to expire shortly,
named can refresh the data from the authoritative server immediately,
ensuring that the cache always has an answer available.
The prefetch specifies the "trigger" TTL value at which prefetch of
the current query will take place: when a cache record with a lower
TTL value is encountered during query processing, it will be
refreshed. Valid trigger TTL values are 1 to 10 seconds. Values larger
than 10 seconds will be silently reduced to 10. Setting a trigger TTL
to zero (0) causes prefetch to be disabled. The default trigger TTL is
An optional second argument specifies the "eligibility" TTL: the
smallest original TTL value that will be accepted for a record to be
eligible for prefetching. The eligibility TTL must be at least six
seconds longer than the trigger TTL; if it isn't, named will silently
adjust it upward. The default eligibility TTL is 9.