Comment 6 for bug 2060024

I've done some more diagnosis and I think this is our issue, but I'll describe what I've found anyway as we may not be the only ones to encounter it. I'm not certain if a change in Designate's behaviour made this more visible or if it's a change in behaviour elsewhere which I've only picked up on at upgrade time, but either way the latter clearly causes a problem.

Our Designate pool config uses different addresses for the 'nameservers' and the 'targets'. It appears we have ended up with some unexpected caching between the two of these, so whilst the 'targets' always receive updates correctly, if a recent query has been made to the 'nameservers' then we have to wait for the SOA's TTL to expire before the non-cached record becomes available and Designate knows that the change was successful.

Thanks for your time looking into it.