I don't fully understand the problem nor the proposed solution to it. If you can explain in more detail what the goal is, I could better respond.
If it's just about the mentioned "webmail" A record, changing it after you changed the IP on that system will work. And of course the MX record(s) need to point to vaild mail servers.
However, keep caching in mind. I recommend you examine the current TTL and lower it to e.g. 5 minutes / 300 seconds before the change. Otherwise the old IP address continues to be used if cached and you have no way to control this if it's your external DNS.
Moving from one DSL package to another. New package gives us 5 statics. we now have our own managed router, not just a pass-tru provided by ISP.
We have two circuits installed, I am trying to configure the 871 router we purchased to work so that on migration day, swap out the old and move in the new.
I currently have outbound communication working. I can VPN etc inbound - just don't have mail working inbound. I also can't get https://webmail.domainname.com to work with just the IP's. This may be more an issue with how OWA is setup (might recognize host headers only - not sure).
I wanted to modify our current DNS so that it will allow me to swap after hours to do some testing. Especially when it comes to mail.
I thought by adding the extra MX record to point to the new IP with a different priority number - that when I swapped it would not get a response on MX 10 and go to MX 15.
It is external DNS, so I do not have access to Time to Live values. So caching will be an issue?
I have another post for telnet (see Exchange and OWA recent post) - I was trying to troubleshoot and make sure exchange would still work inbound using the ip address.
Just to get you right: You are running a DNS server already and have the domain you hold delegated to it?
Usually at least two DNS servers are required, so you either have two on your site or you specified one at your ISP or any other location. Make sure you update the IP address information there, too.
The TTL values are specified in the SOA record, just on top of your configration:
@ IN SOA nameserver.place.dom. postmaster.place.dom. (
1 ; serial number
3600 ; refresh [1h]
600 ; retry [10m]
86400 ; expire [1d]
3600 ) ; min TTL [1h]
So lowering the value there will do the job. If just some entries would change, you could even change the TTL for just them. But in your case it makes sense to me to lower it for the whole zone. If it's an hour, you could live with it, if it's several days, then rather not I suppose.
If your DNS is managed externally altogether, ask them to lower the TTL for your zone or ask at least how long the TTL is. If it cannot be changed - for what reason ever - you might loose (inbound-) connectivity, in worst case as long as the TTL currently set.
You can add the extra MX record, that will work. However, make sure to remove the obsolete one as soon as you have done the change.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...