The Domain change document draft

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 at 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.
>From this range, the Network administrator of Company X have set on nic.bar.
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
> 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
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
> set type=ns
> foo.bar.
foo.bar        nameserver = primary.foo.bar
foo.bar        nameserver = 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
> 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
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 at eurocomercial.es
EuroIDT - Eurocomercial       |  Tel:   +34 91 435 96 87
Internet Development Team     |  http://www.eurocomercial.es/
--------------------------------------------------------------------