-1

I have a non HTTP server I run for supporting a popular VOIP/WebRtc protocol.

Server "A" is the old server. Server "B" is the new server. Both can run independently, but do the same thing. Server "B" is fully ready to go as the replacement for "A". Two days ago, the DNS entries were switched to point to "B" instead of "A".

The trouble is, I still see a lot of traffic going to "A" instead of "B". The TTL on the DNS entry (Route 53) was just a day (86400 seconds). So it seems like there are still clients out there either not re-querying DNS or some other issue with DNS caching.

I haven't ruled out misbehaving clients. But is there a general behavior for DNS caching downstream that I'm not accounting for that could delay the change from propagating longer than the TTL I have for the record on Route 53?

Improve this question
3
  • 1
    This is 'normal', and can last for months if not years. Could be caching routers, routers with bugs, etc.
    – Halfgaar
    Feb 27 at 19:08
  • 1
    I still see a lot of traffic going to "A" instead of "B" - How did you confirm and validate that this traffic was a result of DNS name resolution?
    – joeqwerty
    Feb 27 at 21:37
  • You would get far better help if you disclose the real names involved.
    – Patrick Mevzek
    Feb 28 at 0:05

1 Answer 1

Reset to default
2

This is standard behavior and you should wait for some time (as mentioned in comment can be few or more days). The good practice is to change TTL to 3600 (or even less) days before the change, in day zero make the the change in DNS and then return the TTL to standard value (86400 for example).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .