The requirement to run two nameservers comes from §4.1 of RFC 1034, and is indeed for redundancy.
There are numerous providers who will offer you very cheap "secondary DNS" service where they transfer the zone file from your primary server using AXFR. For example, in the UK we have a well-known provider who'll do secondary service for 50 domains for just £2.30 a month (just over 3 bucks).
This will give you the ability to manage and run the zone yourself, but still give you the resiliency you need.
Getting a copy of the existing DNS may involve "scraping" it out of a web-based management interface. You can try to perform a zone transfer of the zone using dig, nslookup, or a DNS server, but any properly-configured DNS server isn't going to serve up zone transfers to Joe AnybodyTM.
You'll find several questions on Server Fault re: orderly cutover of DNS records between an "old value" and a "new value" (Here's one: How do I smoothly migrate a web server's DNS from one IP address to another?).
The traditional method for performing such a cutover is to place the "old value" in the DNS server (e.g. the pre-cut IP address assigned to the "www" A record) and to turn down the TTL prior to the cut (some people prefer backing-off this value by half until the cut takes place-- 24 hours, 12 hours, 6 hours, etc, right up until the cut). Once you hit the cutover time, you put the new record in place and whatever TTL you'd like. Ideally the pre-cut record had such a short TTL that it quickly ages out of cache on all the recursive resolvers around the 'net that might have been caching it (assuming everybody plays along and doesn't do dumb things like overriding your TTLs).
You can augment this by using URL rewriting or a reverse proxy on the old web host to direct clients to the new host if you're really paranoid (or somebody isn't playing by the rules and ignoring your TTL). Whether you need to go to this level of paranoia or not will depend on your specific circumstance. If the site is static in nature I'd keep the web site running on the old server until you no longer see accesses hitting the logs there.
I'd think that the important records are probably the MX record for the domain, and the A records for the domain, "www", and whatever the MX record points to. I'd play it safe and replicate the entire contents of the zone such that you can, later, examine each record and figure out if they're being used and what they're being used for. (I know that my Customers typically have a record for their user-to-site VPN gateway in the public DNS, for example.)
Best Answer
Yes. Having different hosts behind different fully-qualified domain names (FQDNs) is fine, notwithstanding that the FQDNs are in the same domain. See, for example, my main web server, and my monitoring server, which are under the same domain but are on different hosts in different countries:
Edit you ask where the setting is done. In the DNS, define both A records, each pointing to the relevant IP address. In each server's service configurations (at least for hostname-aware services) tell it which FQDN it should be serving.
Edit 2: on whichever nameservers are authoritative for your domain, let's say those for
example.com, you definewww.example.comto point to the IP address of the corporate webserver, andretailbank.example.comto point to the IP address of the internet banking server. Given your comment below, where you say you got the domain from GoDaddy, you would set these in GoDaddy's control panel for that domain.You configure the corporate webserver to serve the appropriate site on
www.example.com,and you configure the internet banking server to serve the appropriate site onretailbank.example.com.Which DNS servers each of these two web servers uses for its DNS lookups is not material; each should use whichever servers are appropriate for its hosting.