From this range, the Network administrator of Company X have set on nic.bar.
www.foo.bar. 192.168.10.10 10.3 Modify primary "IN NS" in the NIC Send form to the NIC asking for the change of primary (and secondaries, if needed) name server for that domain to the new one. This is mainly an administrative task and the time it takes to process the change is greatly dependent of the NIC itself and the workload in each moment. Usually the NIC informs the customer as soon the change is made, but is a good rule of thumb to check it by yourself. Two aspects should be checked. In first place the NIC_s database should be verified -usually through a web
set type=ns foo.bar. foo.bar nameserver = primary.foo.bar foo.bar nameserver = dns.otherserver.com
set type=NS mydomain.tld answer should be the new "IN NS" 10.7 Hosts changes Now you have a new DNS server with reduced expire and refresh times, but the new DNS server contains the same host information that the old one. i.e. the "IN A" records point to the servers with the old IP addresses. Now it is required to modify these "IN A" records to point to IP addresses existing in the new IP range, but previously you must install the servers in
Hello It was supposed that the original document was text. In any case, here it is inserted as text... Recomendations to migrate a domain between networks Fernando Garc°a FernÝndez <fgarcia@eurocomercial.es> September, 2000 1 Abstract This document gives a set of recommended steps to migrate a domain name and their related services (mail server, web server, etc.) from one IP address range to another to avoid loss of visibility on the net. 2 Table of Contents 1 ABSTRACT 1 2 TABLE OF CONTENTS 1 3 INTRODUCTION 1 3.1 SITUATIONS 2 3.2 MIGRATING A DOMAIN FROM ONE ISP TO ANOTHER 2 3.3 CHANGING THE IP NUMBERING OF THE ISP 2 3.4 CHANGING PROVIDER 2 4 REQUIREMENTS 2 4.1 COMMON SENSE 2 4.2 MINIMUM DNS COMPREHENSION 2 5 TARGETS 2 5.1 PROVIDE NO BLACKOUT IN THE DOMAIN ANSWERS 2 5.2 AVOID LONG TERM POLLUTION OF THE DNS SPACE WITH INCORRECT OLD DNS RECORDS 3 5.3 AVOID SHORT TERM BLACKOUT ON HOSTS ANSWERS (A AND PTR RECORDS) DUE TO CACHING 3 6 REQUIREMENTS 3 3 Introduction Due to the dynamic nature of Internet and to the several economical and political elements involved, it is common that a domain name and related services (mail server, web server, etc.) needs to change from one IP range to another. The most frequent case is when the ISP or company that maintains the domain nameservers moves from one carrier to another, but there are more circumstances that can lead to this situation. If an incorrect procedure is followed during this migration, an "outage" can happen on the domain and its services would be unrecheable during a long period of time (even days). To avoid this, it is recommended to follow the set of steps suggested along this document, that would eliminate, or at least would reduce to the minimum, this "outage". 3.1 Situations There is a variety of situations which could lead to the necessity for this change of network, among others, the following ones: 3.2 Migrating a domain from one ISP to another When the company that owns a domain, changes its Internet services from one provider to another motivated by economical and/or other sort of factors. The new ISP will have a different IP address range and the nameserver for the domain name will be one belonging to the new ISP. 3.3 Changing the IP numbering of the ISP Even if a company does not change of ISP, this provider can change itself its IP address range, just because it changes of carrier, or becomes LIR with its own IP address range; or rare but can happen, because the carrier reorganizes its IP space. 3.4 Changing of provider This case provokes a similar situation for the ISP itself, that needs to keep running their own services without disruptions. Usually an ISP handles hundreds of domains and a 'change without disruption' should be compulsory. 4 Requirements To be able to perform the change without dramatic consequences, the requirements below are recommended to be followed: 4.1 Common sense As usually occurs in Internet as well as in any other technically related area, even with a good cookbook, unexpected things may happen and in these situations, 'common sense' is a must to solve the problem. 4.2 Minimum DNS knowledge Read 4.1 and replace "common sense" with "DNS understanding" 5 Targets The final intention of the procedure described below is to keep active (and visible) all services in a domain during the most part -if not always- of the time. This goal can be achieved through the following independent targets: 5.1 Avoid the 'outage' of the domain The intention is to have always a DNS server answering queries for the domain, and hopefully it will answer correctly most of the time. Probably the worst thing that can happen is losing the DNS servers. In this case recovering the servers and all the information can be a time consuming process involving a lot of contacts to solve it. 5.2 Avoid pollution of the DNS caches with incorrect information Another problem that must be avoided is that the IP address of the DNS servers should be changed as soon as possible in the root servers so the domain authoritative information is updated with enough time to be distributed worldwide before the change of address of the servers happens. In case the IPs of these DNS servers are not changed with the sufficient advance, many servers worldwide will cache the previous information and the incorrect data will be kept until its expiration. In case that DNS servers that exist in the previous IP address don't answer anymore, we would be in the situation stated previously in 5.1. But if they answer with incorrect data (i.e. the former ISP is non collaborative and denies any change), the clients would get the former IP address for the services and this IP wouldn't change or would return outdated information. 5.3 Avoid short term blackout on hosts answers due to caching This is similar to the previous one. If the DNS servers information is not updated and propagated in a timely manner, when the servers are moved from one IP address space to another, many DNS servers worldwide will keep the previous IPs cached and they will return this information to their clients. 6 Requirements 6.1 Planning in advance, two weeks minimum To avoid problems with timeouts and caching stated in the previous section, the changes detailed below must be done with the sufficient advance. Two weeks are usually enough time to accomplish this with standard DNS SOA times following the RIPE and/or the local NICs. In some specific cases this two weeks won't be enough and the recommended time must be calculated according to the settings in the SOA record. 6.2 Co-ordination between ISPs is strongly recommended Though it is possible to make this migration without the cooperation of the former DNS administrator (usually the ISP that is losing the customer that owns the domain) and in some cases this is the only way to go, it is recommended that both DNS administrators work together (collaborate??). There are no written rules or laws to force the former DNS administrator to help in the migration, but denying his collaboration would neither help him and could create a bad reputation for him. 6.3 NIC contacts A preliminary task to do is to check the authoritative NIC of the domain to see the contact(s), who is authorised to make changes to the domain record. At least one of these persons (usually the administrative contact) must belong to the company_s staff that owns the domain and wants to make the changes. In some NIC registries this relation between the administrative contact and the company is compulsory. But in others (specifically in Network Solutions, formerly InterNIC) the contacts can be any person without any relation with the company. Specifically these contacts can be members of the former ISP, and if this is not collaborative this can lead to the impossibility of changing the domain unless some legal measures were taken, but this goes beyond the scope of this document. 7 Scenary The scenary designed to draw the situation is probably one of the more complex, and in some cases few steps can be ommited. All the examples shown along the document make use of private IP addresses (RFC 1918) to avoid using the legitimate rights of some IP owner space. Of course this address must be changed for the legal ones assigned to this companies. As well as the domains and subdomains used in this example are purelly fictional and any coincidence with real domain or subdomain names is purely accidental. 7.1 Starting situation Company X owns the domain "foo.bar.", with the registry of the "newer" country, that can be contacted in http://www.nic.bar/. This company has Internet connectivity through carrier A, which has delegated to them the IP range 192.168.10.0/24. the following information: Primary domain server for foo.bar.: 192.168.10.2 Secondary domain server for foo.bar.: 192.168.10.240 Later, this administrator have set up the information of this domain to resolve that: www.foo.bar. is a "IN PTR" to 192.168.10.10 mail.foo.bar. is a "IN PTR" fo 192.168.10.15 The MX for foo.bar. is mail.foo.bar. with a preference of 10, there isn_t any other MX. Of course, our administrator (is responsible)<-(yo lo quitar°a) and also has setup de inverse-resolution (in our) nameservers after being delegated from RIPE-NCC. 7.2 Ending situation After the migration, company X would be connected through carrier B. This carrier would have agreed to delegate to company X a range of IP addresses, specifically the group 10.40.5.0/24. The new servers would be: Primary domain server for foo.bar.: 10.40.5.2 Secondary domain server for foo.bar.: 10.40.5.240 www.foo.bar. as a "IN PTR" to 10.40.5.10 mail.foo.bar. as a "IN PTR" to 10.40.5.15 The "IN MX" for foo.bar. would continue being mail.foo.bar. with a preference of 10, without any other "IN PTR" . The inverse-resolution for the new IP address range would be delegated and correctly configured. 7.3 Restrictions There are some of the mechanics involving the transfering that are NIC specific. Mainly the administrative tasks explained step by step and forms to be filled. Especific forms for particular NICs may be found in the appendix below. The following ones, are generic instructions. 8 Mechanics (how to proceed) The underlying idea of this procedure is to carry out the transition in two steps: The first one will change the DNS servers to the new IP address range but keeping the hosts in the previous range. This includes updating the database of the authoritative NIC for that domain. Once the information for the DNS servers have been changed (updated) all over Internet, the IP addresses of the hosts will be changed in this new DNS servers, but previously the refresh and expiration times should be lowered to allow for the change to be updated across Internet in a quick way. This is the main point in the process, to have expiration times low enough that when you change some value, the new information is distributed enough fast that the machines that try accesing the old information are reduced to a minimum. When this changes are finished, the this DNS values should return to their normal values to avoid unnecesary traffic in the network. 9 Shopping list If you have lot of experience with your DNS server and your NIC, this is probably the only list you need. In a brief list, this is what needs to be done: * Create (Install/Setup) a new DNS server in the new IP address range * Configure this DNS server with the host information for the existing IP addresses. i.e. Do not modify 'IN A' records, 'IN MX' records, etc. * Modify the primary name server (NS record) to itself. * Change secondaries name servers if they are in the old network (192.168.10.0/24), do not change them in case they're in a different network * Reduce SOA times for the domain. * Start the server * With a client application (nslookup, dig) check all the information * Send a form to the NIC asking for the change of primary name server (and secondary if needed) * Wait for the changes to propagate * Install duplicate servers (web, mail) in new IP address range * Change "IN A" records in new DNS server to point to duplicate servers * Wait for the changes to propagate * Deactivate old servers 10 Commented steps Next, all the above described steps are explained in depth: 10.1 Setup a DNS server in the new IP address space This is a technical task. Besides installing a new server and the DNS Server software (Bind, dnscache or similar), or using one that already exists, the information on this machine must be updated correctly. This information must be setup with the following data 10.1.1 Duplicate the current domain information in the new server The information to setup is mainly the existing in the former DNS. So the easiest way to work is making a full transfer of the domain and modifying the relevant items (RECORDS). The domain transfer can be achieved with #dig @192.168.10.2 foo.bar. axfr in > /etc/notarealdomain.conf after this you must add this domain to the list of domains handled by this server editing /etc/named.conf and inserting the following lines: zone "foo.bar." { type master; file foo.db; }; The main point here is to preserve the actual addresing of the hosts, so www.foo.bar. is still a "IN PTR" to 192.168.10.10 and mail.foo.bar. is a PTR to 10.40.5.15 10.1.2 Modify primary "IN NS" to itself With any text editor open the file "foo.db" and change the NS resource record to itself. The secondaries must be changed only if the former ones are in the old network (192.168.10.0/24) and you're setting up new servers in the new network. If this secondaries are hosted in another network (carrier, NIC, friendly ISP, etc.) do not change them and do not tell the hostmaster of the remote network to change them. Specifically DO NOT change the primary name server. This will be done later. 10.1.3 Reduce SOA times At the top of the "foo.db" file are the following lines (numbers may be diferent): Write the real values in paper and change the numbers -no matter what the previous values are- to: Refresh: .............................. Retry: .................... Expire: ....................... Minimum: ........................ 10.2 Test the new server Start the DNS server as indicated by the manual or if the server is actually running, tell him to reload the configuration file. This command depends of the server application and the operating system. With Unix and the BIND server, you get the process ID of the server application with $ ps -ax | grep named or $ ps -ef | grep named And then: $ kill -1 PID Or easily: $ ndc reload Replacing PID with the id number for the named process returned in the previous command. After that, check the messages log of the system for the presence of error messages. Usually a "tail -f /var/log/messages" will show you if the server was correctly reloaded of if an error happened. Use a client configured with this server as primary DNS server and check that it resolves the hosts (the existing ones) correctly: nslookup - 10.40.5.2 page- and also, you must check with the name server itself of the NIC. This can be made with DNS client configured to use the name server of the NIC in the same way that was used to check the new DNS server in section 10.2. 10.4 Change secondaries Once the NIC has updated the information is time to update the secondaries that reside in outer networks. Usually these machines are placed and maintained in third party networks, therefore the change is done asking the hostmaster of each site to change the information about the primary name server and reloading his name server in order the change take effect inmediatly. 10.5 Verify secondaries When the hostmasters inform you that the changes are made, you must check this again with dig or nslookup. $ nslookup - dns.otherserver.com primary.foo.bar internet address = 10.50.5.2 dns.otherserver.com internet address = 192.168.13.13 In the information returned, the element to be checked is the information about primary name server, there should appear the new one that you installed in the new IP address range. If this does not happen, It can be because the name server has not been reloaded or the information is incorrectly configured in this secondary. 10.6 Wait until changes get propagated When all the changes are made, it is necesary to wait until the new information gets propagated. The maximum time for this to happen -at least in theory- is the content of the 'expire value' in the former SOA record, but you should check some name servers all over the world in the same way that you test the secondaries. Only when all of them (or, at least all you checked) redistribute the new information is the moment to proceed with the next step. The method to check this, is the one described in previous sections: $ nslookup - the-other-dns-server-name this new addresses because if you don't, you will find that your DNS servers have entries pointing to non existing machines. 10.7.1 Install new hosts The best solution is to install a new set of servers with the new IP addresses and duplicate the information of the original servers. Usually this approach can be applied with the web server and the FTP server, but is not a real solution for the mail server (POP3 server) since the contents of this are dinamic and the mailbox of a user can be modified in the interval from the start to the end of the replication. The best solution for the mail server involves some outages, but the point is to reduce them to a minimum. This solution include this steps: * Create a new email server * Duplicate the configuration, incluing the user accounts (user id and passwords) * Stop the POP3 and SMTP servers of the original mail server * Transfer all the mailbox contents from the old mail server to the new one * Configure the old mail server as a forwarder to the new one * Start the POP3 and SMTP servers in the new machine * Start the POP3 and SMTP servers in the old machine If you cant duplicate the servers, you must transfer them as fast as posible. But an important thing to remember is that the outage is not limited only to the time that you transfer the machines. The DNS servers all over the world will have the information for the old machines cached and though you modify it inmediatly, the old one will remain valid until it expires. This is the reason to reduce the SOA times as described in 10.1.3, to limit this outage to a minimum. 10.7.2 Modify "IN A" and "IN PTR" After installing the alternate set of servers in the new address or moving them, you must change the A and PTR records in the DNS servers to point to the new machines. Also you can restore the original SOA times. This are the new and, hopefully, definitive servers so their IP address can be cached. 10.8 Wait until the changes get propagated Use the usual method described previously with nslookup or dig. Of course you can't check all DNS servers all over the world, but a representative subset is more feasible. 10.9 Deactivate old servers in former ISP Everything is going to the servers in the new address space, so you can deactivate all servers in the old address space, including DNS server, web server, etc. 11 Special situations The previously section describes the more typical situation, but the're some variants that should be explained. 11.1.1 traumatic change of provider The best thing is to maintain both providers or, if your company has it own Internet access and want to change carrier, both carriers. But if you can't, these are some tips: 11.1.1.1 headache assured You will have an outage in any case, and this will create problems with your customers os the boss. 11.1.1.2 You need help from a third party At least you need to maintain always the DNS server reachable. The only way to do it in this situation is through a third party that will keep this server up and running in another network. There are two diferents methods in this situations, the fast and the slow, or the one with long outages and the one with minimum outages 11.1.1.3 Fast method (with blackouts) In this method the outages can be long and the main purpose is to avoid a lost of control in the domain. A fast description is: * Reduce SOA times in the existing DNS server and wait for the information to propagate * Install a DNS server for the domain in the third party server * Change information in the NIC to point to this DNS server * Deinstall servers from older lines, ISP, etc. * Install servers in new lines, ISP, etc. * Install DNS server in new ISP * Change information in the NIC to point to the new DNS server * Restore SOA times to the standard ones During the migration period (days, weeks) you'll have blackout of services because the only server that can be reached in all times is the DNS server. 11.1.1.4 Slow method (minimum blackout) This method reduces the outages to a minimum but require to maintain both conections (former and new ISP or carrier) during some time. * Reduce SOA times in the existing DNS server and wait for the information to propagate * Install a DNS server for the domain in the third party server * Change information in the NIC to point to this DNS server * When the new line arrives, install hosts in the new IPS * Change hosts address in the DNS server to point to the new ones * Change information in the NIC to point to the DNS server in the new network 12 Related information Other documents that can be hepfull are: * ripe-192 - Simple DNS Configuration Example * ripe-203 - Recommendations for DNS SOA Values * ripe-114 - Taking Care of Your Domain * "DNS & BIND 3rd Edition" by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc. -------------------------------------------------------------------- Fernando Garcia | Email: fgarcia@eurocomercial.es EuroIDT - Eurocomercial | Tel: +34 91 435 96 87 Internet Development Team | http://www.eurocomercial.es/ --------------------------------------------------------------------