Dynadot

Zone File MX records changes propagation issue

Spaceship Spaceship
Watch
Impact
1
Hi,

I am facing a strange issue with zone file changes propagation on the Internet.

On the zone file all is correctly configured and a quick look at, for example, on network-tools.com gives the correct new setup.
However, a few other online tools, such as mxtoolbox.com still show the old setup.

Note that the changes were on the MX records and I duly updated the serial number of the zone file. Most importantly, these changes were carried out on Friday last week, so almost full 4 days and still not fully propagated...

Does anyone have any idea why major online tools would still not pick up the changes? I understand that it's not my problem, well almost , but again, 4 days seems to be too much...

Many thanks
Federico
 
0
•••
The views expressed on this page by users and staff are their own, not those of NamePros.
Just make sure that everything is properly configured and it should be okay. Some of the tools out there aren't always the best, and cache information for a bit. I always try and have a few friends check from their location (or servers) and that usually does the trick for me. If a few are showing up wrong, then it's probably just those few.
 
0
•••
I suggest carefully checking your DNS server configurations. Do you have more than 1 DNS server? If so check that there are returning the same results.

Another possibility is large TTL values (possibly the old settings had large values). These can cause problems with caches not being flushed.

Try the DNS Test Report at DNSsy (see my sig). It will tell you whether there are problems with your current nameserver settings. One of the tests checks that all nameservers return the same MX records.
 
0
•••
Frederico I assume that your web hosting provider aware of this and they know how to fix it. So just ask them help you
 
0
•••
Hi all,

Thank you for your replies. Very helpful.

Microvps, I work externally with the ISP having this problem with one of their customers.

I and a colleague of mine noticed that the problem originates from the secondary DNS not being able to automatically update its own zone file from the primary. Therefore, some online servers pick up the changes on the primary but get contrasting results from the secondary.

In principle, the servers setup uses the updatedns plugin to force propagation to the secondary once changes to the primary are made.

If I query the primary, all is fine. If I query the secondary, it reports back with the old records. Note that its serial number still shows the date previous to these last changes.

To make things work, at least temporarily, we then decided to remove the zone file from the secondary so that any query to it has to be retrieved directly from the primary. However, as you can see, the problem isn't fully resolved.

There must be something we don't see. We checked any syntax or file problem but all looks fine. Maybe you can suggest something else we are not able to spot...:|

Thanks

to qbert220

Thanks for you suggestion. I used your tool to check the records.

It is now retrieving the right information.

There are 2 DNS and TTL is set to 86400, that is 1 day...

All seems to work as I mentioned above with the temporary solution...

Thanks
 
0
•••
Good that you have everything sorted out. Good luck
 
0
•••
Before you cleared the cache of the secondary sever did you check the TTL it was returning? That would tell you how long the secondary thought it could cache the result. The TTL reported from a secondary counts down. When it reaches zero the record is considered expired and requested from the primary next time a query is made.

Using dig this is the value after the domain name in the ANSWER section.

e.g.:

dig namepros.com

[snip]
;; ANSWER SECTION:
namepros.com. 3587 IN A 208.101.31.234
[snip]

The secondary server will cache for another 3587 seconds. If the TTL reaches zero and is still returned this could indicate that the secondary was unable to contact the primary (unlikely since it seems it can do so now).
 
0
•••
Back