DNS change still propagating (1 Viewer)
- Thread starter Jon
- Start date
- Local time
- Today, 10:54
- Joined
- Sep 28, 1999
- Messages
- 7,383
You can test for propagation using this link: https://dnschecker.org/#A/access-programmers.co.uk
158.106.133.182 is the right address.
158.106.133.182 is the right address.
Noting to do with being GoDaddy or not per se.
The propagation of a change is governed by the TTL (Time To Live) setting on the cannonical record. Downstream DNS servers will only update when that time is exceeded.
When preparing for a DNS change, the administrator should reduce the TTL to a relative short period so that downstream servers look frequently for the update. This should be done far enough ahead so that it has already reached DNS servers far downstream before the update to the record is made.
Understanding TTL Values In DNS Records
Time To Live, or TTL for short, is the sort of expiration date that is put on a DNS record. The TTL serves to tell the recursive server or local resolver how long it should keep said record in its cache.
ns1.com
- Local time
- Today, 04:54
- Joined
- Feb 28, 2001
- Messages
- 27,156
Moke123 (and anyone else seeing that kind of message):
My background with U.S. Navy network security allows me to understand what is going on. Since some of you might not have similar backgrounds, I will provide an explanation as a service to the members who are curious and not familiar with network security issues. If you feel you already understand what is happening, don't bother to read this. But if you are curious, well.... that's why I wrote it.
Moke's message is actually a speicifc browser's error code from other than Firefox. This is what I got from Firefox:
Here is how it works and how it is related to a DNS change.
DNS records help you to find the right place when you use a standard browser, because the brower entry or your web icon NAMES the site. It does that precisely because the site's numeric address can change. Jon has re-hosted his site and made other adjustments, all of which are related to the DNS "name and properties" record for AWF. So this means that updated DNS information must be made available.
However, standard browsers have an "opimization" that gets in the way sometimes. They retain name caches that help make response faster. You don't have to look up the address for that name a second time if it is still in the cache from the first time you did the lookup. Time To Live (as noted by Galaxiom) is a parameter that defines how long those cached entries remain valid. The preferred method for fixing a misdirected cache entry is to flush your browser's DNS cache. I don't think you need to flush login cookies and I wouldn't bet on browser history needing to be flushed either.
When a DNS entry expires, your browser sees it and merely does another DNS search on the name, replacing the (now obsolete) cache entry. But while that cache entry is still "alive" it can point you to the wrong site. When Jon mentions DNS "propagation" he is referring to the time it takes for all cached entries to expire and be replaced by a new DNS lookup. This is where the mischief steps in.
When the site information changes, the previous information in your cache now points to an inactive site. If the site isn't dead but rather just has stopped accepting that connection, then during the session handshake, the condition is detected. The question might come up: Why doesn't it help for me to flush my cache? But the network is a DISTRIBUTED environment. There are such things as "secondary name caches" when your browser does the new name lookup operation. So if you ask for updated DNS entries, you might get them from secondary servers that have themselves not yet updated their entries because THEIR "Time to Live" hasn't expired yet. In essence, the secondary DNS that supports your lookup has old data, too. Jon can make a change to the "authoritative" server entries but that has to ripple out through all secondary servers before it finally takes effect. THIS is what is meant by "propagation."
The specifics of the condition are this: Since this site is set up for HTTPS (emphasis on the "S"), we use secure communications. Therefore, the browser and site must undergo a "handshake" to establish a session. So... the browser, being the one to initiate the process, offers a list of encryption methods that it supports. The site, being the responder, offers a list of methods it supports. The browser picks one that they have in common. The actual method of picking when more than one choice is available is a matter of how the browser was programmed.
The message we are seeing simply says that when the browser and site compare notes, they have no encryption methods in common and therefore cannot establish a secure session. And that is probably due to the old site, which is no longer active, from having NO encryption methods at all. When we were still on vBulletin, it was possible to use HTTP, and in that case, this error would not happen unless the browser was configured to only allow secure sessions. For instance, if you log in from commercial or government or (worse yet) military sites, you might NEVER be allowed to visit a non-secure site.
My background with U.S. Navy network security allows me to understand what is going on. Since some of you might not have similar backgrounds, I will provide an explanation as a service to the members who are curious and not familiar with network security issues. If you feel you already understand what is happening, don't bother to read this. But if you are curious, well.... that's why I wrote it.
Moke's message is actually a speicifc browser's error code from other than Firefox. This is what I got from Firefox:
Here is how it works and how it is related to a DNS change.
DNS records help you to find the right place when you use a standard browser, because the brower entry or your web icon NAMES the site. It does that precisely because the site's numeric address can change. Jon has re-hosted his site and made other adjustments, all of which are related to the DNS "name and properties" record for AWF. So this means that updated DNS information must be made available.
However, standard browsers have an "opimization" that gets in the way sometimes. They retain name caches that help make response faster. You don't have to look up the address for that name a second time if it is still in the cache from the first time you did the lookup. Time To Live (as noted by Galaxiom) is a parameter that defines how long those cached entries remain valid. The preferred method for fixing a misdirected cache entry is to flush your browser's DNS cache. I don't think you need to flush login cookies and I wouldn't bet on browser history needing to be flushed either.
When a DNS entry expires, your browser sees it and merely does another DNS search on the name, replacing the (now obsolete) cache entry. But while that cache entry is still "alive" it can point you to the wrong site. When Jon mentions DNS "propagation" he is referring to the time it takes for all cached entries to expire and be replaced by a new DNS lookup. This is where the mischief steps in.
When the site information changes, the previous information in your cache now points to an inactive site. If the site isn't dead but rather just has stopped accepting that connection, then during the session handshake, the condition is detected. The question might come up: Why doesn't it help for me to flush my cache? But the network is a DISTRIBUTED environment. There are such things as "secondary name caches" when your browser does the new name lookup operation. So if you ask for updated DNS entries, you might get them from secondary servers that have themselves not yet updated their entries because THEIR "Time to Live" hasn't expired yet. In essence, the secondary DNS that supports your lookup has old data, too. Jon can make a change to the "authoritative" server entries but that has to ripple out through all secondary servers before it finally takes effect. THIS is what is meant by "propagation."
The specifics of the condition are this: Since this site is set up for HTTPS (emphasis on the "S"), we use secure communications. Therefore, the browser and site must undergo a "handshake" to establish a session. So... the browser, being the one to initiate the process, offers a list of encryption methods that it supports. The site, being the responder, offers a list of methods it supports. The browser picks one that they have in common. The actual method of picking when more than one choice is available is a matter of how the browser was programmed.
The message we are seeing simply says that when the browser and site compare notes, they have no encryption methods in common and therefore cannot establish a secure session. And that is probably due to the old site, which is no longer active, from having NO encryption methods at all. When we were still on vBulletin, it was possible to use HTTP, and in that case, this error would not happen unless the browser was configured to only allow secure sessions. For instance, if you log in from commercial or government or (worse yet) military sites, you might NEVER be allowed to visit a non-secure site.
