Add a zone for the specific name (_avatars._tcp.company.com.) to your internal DNS server, containing the single record you wish to override.
A SRV record is not special - it is just a DNS record, and it behaves like any other DNS record.
The override zone should look similar to what's below
$TTL 3600
@ IN SOA dev.company.com. root.company.com. (
2009071505 ; serial
10800 ; refresh
3600 ; retry
3600000 ; expire
86400 ) ; minimum
@ IN NS inside-ns.company.com.
_foo.dev.company.com. IN SRV 0 0 80 google.co.uk.
Firstly, it's important to recognise that the DNS records cached on the client or their DNS resolver which are both out of your control (note that I'm referring to the DNS records not your authoritative name server). Therefore it's up the client and their DNS resolver to honour your TTL.
In the case of a new visitor who has never visited your site before and whose DNS resolver has not cached your records (or visited long enough ago that the cache has expired) they will see the new records immediately.
Shouldn't this be under 60 seconds?
It should, but that's only if your client honours the TTL. Some clients have minimum TTL's and some networks also have a DNS resolver which may be caching results.
Is it possible to reduce this time?
You have to remember that the majority of your visitors (assuming this is a public site) won't have been sitting there loading your site every few seconds like you have. Most of your visitors probably won't have visited the site recently and and their DNS resolver may not have the records in their cache. Most DNS resolvers should respect your TTL but you can't guarantee this.
What is a safe time to delete the old stack?
You're better off judging this by what traffic is still being served by the old stack rather than DNS TTL. If you're using ELB you should be able to view how many requests per second are being served by the old ELB in cloudwatch. Wait until this drops below an acceptable level then delete it.
For the sake of viewing the new stack immediately after the switch I recommend just manually flushing your local DNS cache. Leaving your own client to expire records naturally for the sake of seeing how long it takes probably won't be indicative of how long it takes for other clients.
Edit, I noticed Google's Public DNS has a tool to let you flush the cache:
https://developers.google.com/speed/public-dns/cache
This may speed things up as a significant proportion of clients are likely to be using this.
Best Answer
IMHO unreliability of the server is not a problem for the clients to solve! DNS has sufficient built-in provisions for redundancy, back-up name servers etc.
The hostmaster sets the TTL, which is an instruction that you may cache this record at most TTL seconds.
If you're allowed to do a zone transfer you may run as slave of that faulty zone, which may have a longer expiry then the TTL of the records in that zone.
Caching records longer then their TTL is generally considered a bad idea. Caching records shorter then their TTL allows is according to standards, therefore bind has a max-cache-ttl option and not the reverse.
Unbound does though:
cache-min-ttl: