Just like Aerospike checks TTL in the PI and does not return the record if server clock is ahead of the TTL timestamp (record is there but expired), Aerospike should not allow a record update that reduces the TTL below the current remaining life.
This will eliminate the 50% probability of zombie records coming back to life on coldstart due to this operation - currently there is no handle to prevent this situation except asking clients not to do it. If for some reason, there is a compelling need to do it, there can be a config item - allow-ttl-reduction which should be set false by default. (This can be specific only for disk storage since its a non-issue with pure in-memory storage.)