We're in the process of moving service providers for our main internet connection. We will be running the 2 circuits in parallel as we start migrating web facing servers on to the new IP range we have been assigned.Can we ask our net names provider to register the new IP addresses with the current FQDNs to make the transfer process more seamless? For example:Old IP 1.2.3.4 ftp.ourdomain.comAND 4.3.2.1 ftp.ourdomain.comSomeone said we can't have multiple A-records for the same FQDN but I'm not so sure if this is true. Could cause problems if the DNS acts in a round robin fashion before we get the NAT'ing ported to the new addresses.Is there another way to do this?
Jump to Pointer and MX Records - There is a special domain set aside for reverse lookups:in-addr.arpa. PTR records reference addresses with respect to.
My concern is that sometimes these changes can take 24-hours to become usable. If the new IP and DNS was ready to use in conjunction with the original IP, that would make the changeover a lot smoother. Yes you can have multiple IP's for the same A record.There's a few problems with this if used for redundancy purposes. DNS servers and DNS resolvers randomly choose the order of the list of IPs - even though you might configure it a certain way on your DNS Server hosting the zone, resolvers will flip it. So you can't force all connections to go through a certain link and use the 2nd link for failover. It will however work if you simply wish to distribute clients randomly across both IPs.Clients/browsers typically use the first IP in the list. If that times out after about 30secs, they will try to connect to the 2nd IP.
There's no way to hurry up this process because it's hardcoded in the browsers (IE, chrome etc).If you plan to have both links active and are using a firewall that supports load balancing so that connections are returned on the same link they are initiated on, this solution should work well for you.Note: DNS round robin is different to having the same A record configured twice with two IP addresses - that normally results in the client receiving a single IP address (decided by the server) not two (as would be the case here). Thanks everyone. I was hoping we could have a sort of weighted preference like MX records but I guess that's not possible. We don't really want clients randomly resolving the new addresses until we've got them NAT'd to our internal servers. I guess the only way we can do it is get all the firewall rules changed to have matching entries for the new addresses, then request the A-record is changed to the new IP and switch the NAT'ting over one weekend. It would have been nice to be able to do them all one at a time and test without worrying about end users seeing a problem.It's never a simple fix!:-).
RowanBarker wrote:Thanks everyone. I was hoping we could have a sort of weighted preference like MX records but I guess that's not possible.
We don't really want clients randomly resolving the new addresses until we've got them NAT'd to our internal servers. I guess the only way we can do it is get all the firewall rules changed to have matching entries for the new addresses, then request the A-record is changed to the new IP and switch the NAT'ting over one weekend. It would have been nice to be able to do them all one at a time and test without worrying about end users seeing a problem.It's never a simple fix!:-)It's not possible to have a weighted preference with A records. What you could do is use a load balance style appliance and give it the IP addresses then configure it for a weighted preference but that's going to mean some messing around and testing. What Nitroz said: any time I've moved servers in the past, I've handled it by setting the TTL really low, like 5 minutes. As said, some DNS servers will cache for longer than they should, and you can't control that, but I've never had problems with a low TTL and changing the record in off-peak hours. I set the TTLs to 5 minutes.
I'm not sure where I heard it, but my understanding was that your lookup request might go through 4 DNS server hops before it gets resolved, so your total time to change over should be 4 times your TTL, not factoring for servers that cache excessively. But like I said, I have no idea where I heard that:P.
I'm inheriting a mess and I need your help to straighten it out.The two primary objectives are to alter the DNS records for 'Example.com' so that the 'internally hosted' email server (Domain registrar and email server host are the same) continue to function, while the domain itself points to an 'externally hosted' web site.Here's the information:1. 'Example.com' DNS is managed at Company A.2.
![Propery Propery](/uploads/1/2/5/5/125530013/338045434.png)
'Example.com' A Record points to OLD site hosted by Company Z.3. 'Example.com' NEW site exists as a user (exampledotcom) on an account with Company B.4. Frankly, you have so much pretend data here that this is probablygoing to be unnecessarily confusing. I'll try to keep everythingstraight.If I understand your question correctly, you currently have thefollowing DNS records: example.com. A 1.2.3.4example.com. MX 10 example.com.www.example.com. A 4.5.6.7.and a bunch of unspecified CNAME records.
Also, there exists: some.other.host. A 2.3.4.5.hosting your new website.You want example.com (and presumably www.example.com) to point toyour new site without disrupting email.Try this:.Register mx.example.com as a new A record pointing to 1.2.3.4.Update the MX record for example.com to point tomx.example.com. At this point, you'll have: example.com. A 1.2.3.4mx.example.com A 1.2.3.4example.com. MX 10 mx.example.com.www.example.com.
A 4.5.6.7.Now wait at least twice the TTL for your records to make sure theold MX record has time to expire from DNS caches.Next, update the A record for example.com and www.example.comto point to your new site. You'll end up with something along thelines of: example.com. A 2.3.4.5example.com. MX 10 mx.example.com.mx.example.com. A 1.2.3.4www.example.com. A 2.3.4.5At this point, I think you have what you want.
Email continues to behandled by your existing mail server, but your web presence has beenmoved onto your new host. On separate domain/DNS, web, and e-mail providers:It is not necessarily a bad thing to have your DNS, web hosting, and e-mail hosted by three different entities. TL;DRCreate an A record that points mail.example.com to the IP address of your internally hosted email server. Change your MX record to point to the A record of the mail server.Change the A record for @.example.com to point to the IP of the server with the new website.
Create a CNAME for www.example.com that points to @.example.com. Or you can create another A record that points www.example.com to the new web server. A little bit deeperSome things that might be of interest to you:. 'Example.com' NEW site exists as a user (exampledotcom) on an account with Company B.FYI, I hope you have good redirection rules to either mask that the website is in a user directory. There's no technical problem with this, but. It seems a bit off.If I'm understanding the current setup correctly, 'they' are pointing'example.com' to the email server address JUST so they can set the MXRecord as 'example.com'. Couldn't you simply change the MX Record tothe IP Address of the email server?They aren't setting example.com's A record to the same address as the email server for any other reason than it is probably an all-in-one service that runs a web server, email server, ftp server and whatever else they use to manage the site.
Yes, the A record and MX record are independent and can point to different hosts.How do I need to arrange my name servers? Does the NEW site hostedwith Company B need to be on a dedicated IP so that I can setExample.com's A Record to that?You don't need a dedicated IP. Most web servers are set up to perform virtual host differentiation so that requests for your website are sent to the proper directory regardless of if you're sharing an IP address with dozens or hundreds of other sites.Your NS records need to point at whoever holds your DNS entries, which in your scenario is Company A.
Your registrar will hold the glue records (the record of what your name server's names are and what IP address their names resolve to), and in your case the registrar is also the DNS host.All in all, it doesn't sound like too much of a mess. I've seen worse.