[dns-wg] DNS migration draft

Hello all

As promised, here is the draft of the DNS migration recomendation document
that I will present in RIPE 49.

Remember, is a first draft, with errors, spaces to fill, etc. I welcome any
commentaries about it.

----------------------------------------------------------------------------

Planning the migration of a server's network and associated DNS from an IP
range to other
Fernando García Fernández
Eurocomercial Informatca y Comunicaciones

Date: September, 2004


1 Index


1    Index    
2    Abstract    
3    Unordered migration
3.1    Resolving whithout data in thecache
3.2    Resolbing wiht out of date NIC information
3.3    Request with the DNS server in the cache
3.4    Request with the solicited server in the cache
3.5    Request to the secondary server
4    Situations wich involve IP migration
4.1    Moving a domain name from a given ISP to other
4.2    The upstream ISP changes IP addresses
5    Prerequisites 
5.1    Control over the new DNS Servers
5.2    Authorized contact in the NIC
5.3    Minimal DNS knowledge
5.4    Plan in advance
5.5    Independent and duplicated DNS servers
5.6    If possible, duplicate the other servers
5.7    Coordination between ISP
6    Scenario    
6.1    Starting situacion
6.2    Ending situation
6.3    Limitations 
7    Migration procedure
7.1    Create a new DNS server
7.1.1    Duplicate the existing information of this domain
7.1.2    Modify the server own address
7.1.3    Reduce the SOA times
7.2    Check the new server
7.3    Create the reverse resolution of the new address
7.4    Delegate the reverse resolution of the new address range
7.5    Change glue records in the parent DNS server
7.6    Modify the external secondaries
7.7    Verify the secondaries
7.8    Wait until changes are propagated
7.9    Change servers IP addresses
7.9.1    Modify "IN A" fields
7.10    Modify SOA Values
7.11    Wait the propagation
7.12    Deactivate services in the old address range
10    Resumed procedure
11    Traumatically change of provider
11.1    Help from a third party
11.1.1    Steps    
APÉNDICE A.    Glossary
APÉNDICE B.    SOA Values
APÉNDICE C.    ES-NIC form example
APÉNDICE D.    References

2 Abstract

DNS administration is considered to be typically an easy task by network and
system administrators. Indeed, the daily administration of the DNS service
in a generic organisation with a basic configuration should not imply  major
difficulties in its operation, but when a given organisation has more
requirements than the basics or there´s an issue involving the DNS service,
the complexity of the problem could jeopardize even administrators with
years of experience in the field.

One of the most complex and problematic situations which may be found
operating a DNS server -even more complex than its initial installation- is
to perform all tasks involved in an IP space migration. (i.e. Move all the
information services in use in an organisation which is using the IP space
assigned by its original provider to a new IP space assigned by a  new
provider).  This migration basically implies an ordered sequence of changes
in the information services under the organisation´s domain name (i.e. web,
e-mail, ftp, ...).  This changes basically means updating the IP address of
these services/servers in the primary DNS server for that domain.

Given this is not a situation network or systems administrators need to face
off, it is common to make mistakes when undertaking the migration process,
mistakes which could be fatal for the services depending  on the DNS
service.

This situations and scenaries have been observed live by the author as he
has been involved in these issues more often than desired.

An additional problem to this migration process is the given fact that not
every factor involved in the provider change can be controlled by the
administrator. Even in the best case, the IP address or addresses of the
authoritative DNS servers for that domain need to be updated in the upper
domain DNS service (typically a top level domain ".com", ".es",
".de",".nl",...). These domains are operated by registries (country
registries or companies like Verisign) where the update requests can be
submitted by filling up either web-forms or sending a FAX. The
update/changes could take place within a given period of time (either days
or even weeks), being it almost impossible to know the exact moment when the
changes will occur.

Besides the fuzzyness this external dependency involves, any mistake during
the migration procedure may provoke the lost of visibility of the domain
during a long period of time. Having to chase the registrar, sending FAXes
and even letters (proving authenticity somehow) in order to update the IP
addresses with the right values for the authoritative DNS servers IPs.

The main goal of this document is to define the required procedures to
migrate a set of servers under a given Internet domain name from its
original IP address space to another, avoiding or at least reducing to the
minimum the possible invisibility of the domain name (and all services
associated) from any other end of Internet.

These procedures will be defined in the most generic way possible, following
the RFC style, in order to make a useful tool out of this for
administrators.

The information which makes a domain name visible on the Internet  (i.e
Resource Records "RRs" associated to our domain) is firstly configured in
the parent DNS server of  that domain name. As these servers are queried by
other DNS servers (typically configured as cache-resolvers) this
information, these RRs are stored (i.e. cached) by them, so it gets spread
all across the Internet. These RRs are stored by all cache resolver DNS
servers with an expiration time, so the authoritative DNS servers for that
domain are not queried again for that information.

IP space migrations will usually involve either the change of IP address of
the authoritative  DNS servers as well as the servers providing typical
internet services (i.e. http, ftp, smtp...).

In case the IP addresses of all servers (DNS and other services) are
simultaneously changed to the new IP addresses (according to the new IP
addressing scheme) an immediate "blackout" would happen until the former DNS
information related to our domain name expires. This information (i.e.
Resource Records associated to our domain)  are stored in the parent DNS
servers, usually TLD servers as explained in the first paragraph of this
section.

To avoid the "blackout" and keep all internet services visible from Internet
or reduce this time to the minimum, all tasks involved must be correctly and
thoroughly scheduled.

3. Unordered migration

If there is no ordered migration of the services, but all of them are
changed simultaneously, and even considering that the related NIC change the
DNS information instantly, there will be a blackout.

This time depends on the computer that tries to access the services and is
very variable. The following sections show all the cases that can happen
with the estimated blackout time so the reader can understand the need of a
coordinated migration. In all of this cases the changes of the servers are
made in a time "t".

3.1 Resolving without data in the cache

If the request is originated in a computer that never have accessed to the
services of the migrated domain and the DNS server used has never accessed
to this domain, it will not have any data in its cache with this information
and when he tries to access any service in a time "t+x", the computer ask to
his resolver, this one check in his cache and when he sees that he don't
have the needed information, will check against the server of the TLD, that
in this theorical discussion has the information up to date, will get the IP
address of the new DNS server and will check with this one the IP address of
the service that he want to use, getting the new one because the server
checked is up to date.

In this case the blackout time is zero

3.2 Resolving with out of date NIC information

The second scenario happens when the NIC or equivalent organisation doesn't
update his DNS server simultaneously with the domain change but in a time
"t+n" and the computer that wants to make the request is in the same
situation of the previous section. In this case a request made between the
times "t" and "t+n" to the upper level domain server will return the old IP
address of the DNS server. As this server has change it's IP address, the
request of one of its services, i.e. www.foo.bar, wont work, because the DNS
of foo.bar isn't in the IP address. But the resolver will maintain in his
cache this address until the expire time "e" finish, time that the TLD
server distributes together with the incorrect IP address of the domain
server. This IP address will be returned during this time each time that the
resolver receives the same request.

Once this time "e" arrives, the resolver from the customer will discard the
information stored in the cache y will do the request again, getting the
correct IP address of the DNS server.

The worst case in this situation is unpredictable because the time "n" is
based in the upgrade of the TLD server and this upgrade in many cases is
human based and can have a window of days.

3.3 Request with the DNS server in the cache

The third situation happens if the resolver of the customer doesn't have the
IP address of the associated service, i.e. www.foo.bar, but have the one of
its DNS server.

In the worst case the resolver stores the IP address of the DNS server in
the time t-1 and will keep stored this address, as valid, during the time e.
So during the time "e-1" this address will stay in the cache thought its
invalid.

For the domains of the Spain ccTLD (.es) the lifetime "e" is 172.800 seconds
-two days- and the blackout period will be of 172.799 seconds, practically
two days.

For domains .com, .net and .org, handled actually by Network Solutions
incorporated, this time "e" is 86.400 seconds and the maximum blackout can
be of 86.399 seconds, practically one day.

TLD of the domain to be migrated

Maximum blackout time
.es                172.799 seconds
.com, .net, .org    86.399 seconds

3.4 Request with the solicited server in the cache

If the resolver of the customer has the IP address of the server, it will
maintain this address during a time "l", even though the real IP address
change in the original DNS server, and this old address will be returned to
the customer.

In the worst case if the resolver stored the IP address one second before
the change; the blackout time will be of "l-1" seconds.

The value "l" is the field "TTL" or "Time To Live" of the SOA register of
the domain. For the ".es" domains associated to the Spanish NIC, the
standard recommendation for this field is[1] 172.800 seconds, i.e. two days
and the blackout will be of 172.799 seconds or two days less one second.

In the same document the recommendation for domains with frequent changes is
to reduce this TTL to 28.800, i.e. 8 hours and the blackout of the server
will be reduced to 28.799 seconds or 8 hours less one second.

Even this last value can be high for services with intensive use and in this
document besides the procedures for change we suggest alternate values for
this field.

The RIPE recommendations for the SOA field[2] suggest the same value for the
TTL field in standard situations, that is 172.800 seconds, and consequently
the same considerations are to be taken into account.

TTL recommendations
Maximum blackout
ES-NIC, normal situation     172.799 seconds
ES-NIC, frequent changes      28.799 seconds
RIPE                         172.799 seconds

3.5 Request to the secondary server

In the previous cases we have supposed that the request was made always to
the primary server but the situation can worsen if the request is made to
the secondary server.

The address update of the primary server must be coordinated with the
secondary server, but the change of address pointing to the primary server
in the configuration of the secondary server must be made manually and until
the administrator of this equipment -that can depend of another
organisation, typically many companies use the secondary DNS service provide
by his carrier, ISP or NIC- doesn't update the IP address of the primary
server and reload the configuration, this authoritative server wont contain
the new values and will return incorrect information.

This update time "a" of the secondary server must be added to the values
stated previously but cant be predicted accurately because usually depends
of human actions.

If this change is not made, the secondary server will keep the old IP
address and after the refresh time will try to renew the information from
the primary server in the known address but it wont find it, or at least
wont find the server with the new information and the update wont happen or
will be made with incorrect data because will get it from the old machine.

4 Situations wich involve IP migration

There are several situations that can drive to these changes in the DNS,
including the following:

4.1 Moving a domain name from a given ISP to other

When a given organisation with a domain name, changes from one ISP to
another, either by economical or any other reasons, the new ISP will have
different IP addresses and the namserver serving the DNS information for
this organisation will be have an IP from this ISP.

It could happen that it is the ISP who owns and manages the DNS server an
service for the organisation, or the organisation itself who does it.

In any case, collaboration from the previous ISP with the new one is always
very recommendable in order to avoid a blackout in the internet for the
organisation´s  services.

4.2 The upstream ISP changes IP addresses

Even if the organisation does not change of ISP, it could occur that the ISP
could change its IP range, either because it moves to a different
telecommunications operator or it could also be due to the ISP becomes LIR
(Local Internet Registry) itself and renumbering is required. It´s also
possible, although not likely to happen, that the ISP´s upstream carrier
reorganises its IP addressing scheme and changes the IP range assigned to
this ISP.

This is essentially the same case as the simply moving from one ISP to
another, but with the advantage that means not having to move the servers
physically and the collaboration of the ISP is guaranteed as it is the same
one.

5 Prerequisites

To be able to do the migration process, it is necessary to meet a set of
requirements that should be checked in advance to avoid problems during the
migration.

5.1 Control over the new DNS servers

It is compulsory that the person in charge of the domain migration or any
other person under his/her supervision must have control over the contents
and operation of the DNS server that will contain the domain information at
the end of the migration.

This control doesn't mean necesarily physical property of the machine, not
even administration rights over it, but it's necesary to have control over
the DNS software and it's configuration files. The best approach is that
this control is managed directly by the person in charge of the technical
issues of the migration.

If the DNS server is managed by other company, i.e. the ISP that handles the
Internet access for the company, and this company don't want to transfer the
control of the DNS, perhaps that server host more domains, it's compulsory
to have a perfect coordination between the person in charge of the migration
and the person in charge of the server. This coordination must allow the
timed edition of the DNS files related to the domain and, more important,
the reload of the server information just when needed, and this operation
can only be made by the administrator of the server.

5.2 Authorized contact in the NIC

This person responsible for the migration must be registered in the NIC and
must be the administrative or technical contact with permission to make
changes in the domain information, specially the host name and IP of domain
servers.

It can happen that the existing contacts in the NIC for the domain wont be
in the company anymore, that their email address doesn't exist (this email
address doesn't need to belong to the domain) or that this contacts doesn't
want to help in the migration as individuals or as a company.

If this happen, this problem must be solved before any other step is made,
specially you can't establish a calendar because recovering the control can
be a time consuming task that is outside the scope of this document and that
usually involves some administrivia including sending faxes and/or letters
with the company letterhead to the NIC.

5.3 Minimal DNS knowledge

Though is not compulsory a in depth knowledge of the DNS protocol and its
implementations, it is necessary a minimal understanding of it's
fundamentals and the working of the implementation used.

If you don't own this understanding and a minimal experience on the subject
the best you can do is get help from some technician with this knowledge.
The second best thing that you can do is to install a DNS server in a spare
computer and try all the operations that should be made latter but without
having any delegation on this server neither using it as a resolver, so the
problems that could arise and even the same test won't affect other users.

5.4 Plan in advance

To avoid problems with time expiration and with incorrect data in the cache
as explained previously, the changes must be started with enough time.

Two weeks is usually a window enough wide if we follow the standard values
recommended by RIPE and/or the local NIC for the SOA fields. Sometimes two
weeks won't be enough and the time frame must be recalculated based on the
SOA values.

You should calculate the time spend in each step, add all and obtain the
total time spend in the transition. You should take into account that some
steps are not technical, but physical with the transportation of machines or
administrative steps that can employ a large segment of the overall time.

Very important is not to be optimistic (better pessimistic) in the forecast
that the carrier gives you and if the migration implies changing carriers,
you must maintain connectivity with the former one you shouldn't ask the
termination of the service based on the forecast of installation of the new
carrier. This forecast is usually very volatile and depends of municipality
permissions, poor quality in the cabling, overbooking in the switching
equipment of the carrier, etc. Any of these elements can lead of delays of
days, weeks or even more (The author of this document suffered a delay of
three months in the installation of a line due to the lack of license to
install a cable by the carrier).

If you have asked for the termination of the contract with the previous
carrier and suffer one of these problems, you will find yourself in the
nasty situation of not having Internet connectivity and, even worse, loosing
the DNS servers as explained previously.

So, even if this involves a bigger cost, you must keep the former carrier
connectivity until the migration is finished.

5.5 Independent and duplicated DNS servers

This migration plan forces that the hardware used by the DNS servers to be
independent of the hardware used by the other servers, so the change of
network configuration of this servers can be made without impact in the
other services.

Also, to ensure the stability of the services, these DNS servers must be
duplicated during some time, so you will need duplicate machines. Once the
migration is finished the machines used for the old IP address can be
unplugged and its hardware reused.

If the migration is between two ISP and these are the ones that provide the
DNS service, the duplicated DNS server is implied and you don't need to
install additional hardware.

5.6 If possible, duplicate the other servers

Though is not so critical as the previous requirement, try to duplicate all
servers accessible from Internet.

This will allow not only the domain to be visible all the time, but also the
services to keep running all the time.

If you don't use duplicate servers, during the migration of the servers from
one IP range to other -even if there is no physical movement- you get a
blackout. This blackout is not limited to the shutdown time of the server
but you must add the propagation time of the new IP address. Though you
should reduce the TTL of this address, the IP address are stored in the
cache of other DNS server with this limited TTL and will be returned until
its expiration.

5.7 Coordination between ISP

Though it's possible to make the migration without the cooperation of the
administrator of the old DNS service (in many cases is an ISP that is losing
a customer) and sometimes is the only way to go, we recommend looking for
the help of both DNS administrators.

There are no enforceable rules or laws for the former DNS administrator to
help in the migration, and the only motivation is the good old Internet
courtesy.

6 Scenario

The scenario designed is probably one of the more complex but it's also one
of the more generic and can be tailored to other situations removing the
extra procedures.

All the examples of in this document use the IP address ranges defined in
the RFC 1918 [1] to avoid damaging the rights and network of the owner of an
IP space in case of missconfiguration. Of course you must change this
address for the ones assigned to you by the RIR/LIR in charge.

In the same fashion the domains and subdomains used in this examples are
fictitious and use the informal standard "foo.bar"[2]. Any coincidence with
real domain names is purely accidental.

6.1 Starting situation

Company X owns the domain "foo.bar" and the domain registry organisation of
the top level is http://www.nic.bar/. This company X has Internet
connectivity through the Internet carrier A, that has delegated to the X
company the IP range 192.168.10.0/24 of his PA addressing block.

Using this range, the network administrator of the company X has inserted
the following information in the servers of the registry:

* Primary server of the domain "foo.bar": 192.168.10.2
* Secondary server of the domain "foo.bar": 192.168.10.240

He also has installed the domain servers in these addresses and has
configured them to translate the following names to its IP address:

* www.foo.bar translates to 192.168.10.10
* mail.foo.bar translates to 192.168.10.15

He also configured the mail server information for the domain:

* The mail server for the domain foo.bar is mail.foo.bar with a preference
of 10 

The administrator of the network has too configured the inverse resolution
of the network in the name servers after getting this inverse resolution in
the RIR/LIR.

So, the configuration files for the BIND 9 DNS server should be as follows
if you have follow the RIPE published recommendations for the SOA values.

$ORIGIN foo.bar.
;
@       IN SOA primary.foo.bar. hostmaster.foo.bar. (
        2001070401      ; serial based on "date+number"
        86400           ; refresh, seconds
        7200            ; retry, seconds
        3600000         ; expire, seconds
        172800 )        ; Minimum TT, seconds
; name servers
        IN NS primary.foo.bar.
        IN NS secondary.foo.bar.
; mail servers
IN MX 10 mail.foo.bar.
localhost               IN A 127.0.0.1
www           IN A 192.168.10.10
mail           IN A 192.168.10.15
primary          IN A 192.168.10.2
secondary          IN A 192.168.10.240

The inverse resolution from IP to names -this resolution must be delegated
from RIPE or the LIR- is as follows:

$ORIGIN 10.168.192.IN-ADDR.ARPA.
@    IN SOA primary.foo.bar. hostmaster.foo.bar. (
;
        2001070401      ; serial based on "date+number"
        86400           ; refresh
        7200            ; retry
        3600000         ; expire
        172800  )       ; minimum TTL
; name servers
        NS primary.foo.bar.
        NS secondary.foo.bar.
; host lists
2     PTR primary.foo.bar.
10     PTR www.foo.bar.
15     PTR mail.foo.bar.
240     PTR secondary.foo.bar.

6.2 Ending situation

After the migration, company X will be connected through carrier B and both
companies have agreed carrier B to delegate to company X a range of IP
address, specifically 10.40.5.0/24.

The new servers will have the following information:

* Primary server for the domain "foo.bar": 10.40.5.2
* Secondary server for the domain "foo.bar": 10.40.5.240

The address for the associated servers should be set as follows:

* www.foo.bar translates to 10.40.5.10
* mail.foo.bar translates to a 10.40.5.15

The mail server will be configured for the domain as follows:

* The mail server for the domain foo.bar is mail.foo.bar with a preference
of 10 and no secondary mail server

The inverse resolution for the new IP range will be delegated and configured
correctly.

The archive for the zone must finish in this configuration:

$ORIGIN foo.bar.
;
@       IN SOA primary.foo.bar. hostmaster.foo.bar. (
        2001072001      ; serial based on "date+number"
        86400           ; refresh, seconds
        7200            ; retry, seconds
        3600000         ; expire, seconds
        172800 )        ; minimum TTL, seconds
; name servers
        IN NS primary.foo.bar.
        IN NS secondary.foo.bar.
; mail servers
IN MX 10 mail.foo.bar.
localhost               IN A 127.0.0.1
www           IN A 10.40.5.10
mail           IN A 10.40.5.15
primary          IN A 10.40.5.2
secondary          IN A 10.40.5.240

And the DNS configuration for the new inverse resolution, that you should
delegate, will be:

$ORIGIN 5.40.10.IN-ADDR.ARPA.
@    IN SOA primary.foo.bar. hostmaster.foo.bar. (
;
        2001072001      ; serial based on "date+number"
        86400           ; refresh
        7200            ; retry
        2592000         ; expire
        172800  )       ; minimum TTL
; name servers
        NS primary.foo.bar.
        NS secondary.foo.bar.
; hosts list
2     PTR primary.foo.bar.
10     PTR www.foo.bar.
15     PTR mail.foo.bar.
240     PTR secondary.foo.bar.

6.3 Limitations

Some of the procedures described in this work are specific of each NIC,
mainly the administrative tasks and the forms to be completed.

In the following description the steps associated with the NIC are explained
generically using the common subset.

7 Migration procedure

The underlying idea is to achieve the transition in a few steps, having to
complete each of them considering the times required for the changes to get
propagated, before starting the next one.

7.1 Create a new DNS server

As explained before, it is recommended to install new DNS servers (i.e. a
new primary DNS server) with the new ISP´s IP addresses, with the same
information as the old DNS primary server.

The DNS servers in the previous ISP are maintained to reply to queries from
clients who don´t have yet the new DNS server´s IP address.

The steps to introduce new data in this machine are:

7.1.1 Duplicate the information for the domain

Once there´s a new primary nameserver in the new ISP (i.e. running BIND,
dnscache, djbdns, nsd, Š) the configuration and zone files need to be the
same as the existing before in the nameservers hosted by the previous ISP
(still up&running), with minor changes.

This can be achieved with a zone transfer (AXFR) from the old primary server
to the new server. In a Unix server running DNS Bind 8.0 or later, the
transfer of the domain can be made with:

#dig @192.168.10.2 foo.bar. axfr  in > /etc/foo.db

Once the zone is transferred, the domain name has to be added to the
configuration file, usually called named.conf in BIND installations. It
should look like this:

zone "foo.bar." {
type master;
file foo.db;
};

The most important to preserve is the current addresses for the internet
servers, so www.foo.bar still point to 192.168.10.10 and mail.foo.bar point
to 192.168.10.15.

7.1.2 Modify the server own address

It¹s also necessary to edit the zone file (foo.db) to modify the ³IN NS²
resource record to the new DNS server¹s name.

The secondary servers only need to be modified if they are in the IP space
of the previous ISP and the new ones will be in the new ISP IP space.

There¹s no need to do this if all secondary servers are outside our network,
there¹s no need to change their IP address.  The administrators of the
secondary servers will only have to modify their configurations files to
point to the new IP address of the primary nameserver in case they
configured their ³named.conf² file using the IP address instead of the
server¹s name.

So far no changes happen in the parent servers hosted by the corresponding
NIC or registrar. This will happen after some more steps.

7.1.3 Reduce the SOA times

Once the described changes are done in the new nameserver, it is necessary
or recommendable to reduce the times expressed in the SOA header of the zone
file ³foo.db². 

Originally in the top of the file "foo.db" you will find the following lines
(the values stored in each field can be different depending if you follow
the recommendations of RIPE or the ones of your local NIC or if you have
follow you own instincts):

@       IN SOA primary.foo.bar. hostmaster.foo.bar. (
;
        2001072001      ; serial based on "date+number"
        86400           ; refresh, seconds
        7200            ; retry, seconds
        2592000         ; expire, seconds
        172800 )        ; TTL minimum, seconds

It is recommended to note these values to restore this configuration after
the migration process is completed. New values are recommendable before
switching from the previous nameservers to the new nameservers.

Suggested values for this field depend of the load of the servers, how
critical is the service and if they can be duplicated. If some they can be
duplicated and/or are not critical, the values can be relaxed.

Field         Old value  New value without duplication  New value with
duplication
Serial number         X                            X+1
X+1
Refresh           86400                            300
14400
Retry              7200                            150
(=)7200
Expire          2592000                     (=)2592000
(=)2592000
TTL              172800                            300
14400

* Field marked with (=) doesn't need to be modified and can preserve their
original values.

* The field "serial" must be incremented respect the previous value of the
same field. This is the only technical requirement of this field, but most
organisations related to the domain handling suggest that the serial number
follows the format: YYYYMMDDNN, with YYYY being the year with four digits,
MM the month with two digits, DD the day of the month with two digits and NN
the change number inside that day and starting by one each day. So the first
change made on July, 2, 2004 will have the serial 2004070201. If the same
day you make other change, the new serial will be 2004070202, but if you
make another change the next day, its serial will be 2004070301.

* The refresh field can have two values depending if the services can be
duplicated in another server.

o If you can duplicate them, the value can be greater because if some client
access the old IP address after the change the old server will still be in
place and will answer the query. A value of 14400 seconds -four hours- as
suggested by some NIC allows you to reduce the number of queries that the
secondary server make without danger of blackout.

o If you can't duplicate the servers, a value of 300 in the refresh field
will force the secondary server to check every 300 seconds -5 minutes- that
the information of the primary server hasn't been modified. This check
doesn't imply a transfer of all the domain information, only the SOA record
to check the serial number. If this values have been incremented then all
domain information will be transferred. This value has been selected because
a blackout of five minutes is usually acceptable even in high load servers
during low traffic times (night, weekends).

* The retry field must be lower that then refresh time. The recommendation
for this field is to be an integer fraction of the last one. If the servers
are duplicated you can keep the existing one if its lower than the refresh
time. If the servers aren't duplicated, we suggest a value half the refresh
time, that is, 150 seconds. This small value is not excessive because the
secondary servers use the retry time only if there are connectivity problems
and they can't check the information from the primary when the refresh time
expires.

* The TTL field has similar considerations to the ones made with the refresh 
time, but in this case the considerations apply to customers not to the 
secondary servers. Also the transfers made when this lifetime expires -14400 
seconds if the servers are duplicated and 300 if they aren't- are only for 
the A register of the requested service.

After all this changes the file "foo.db" will have the following data. Take 
into account that the only A registers that have new values are the ones of 
the DNS servers itself:

@       IN SOA primary.foo.bar. hostmaster.foo.bar. (
;
        2001072002      ; serial based on "date+number"
        300           ; refresh, seconds
        7200            ; retry, seconds
        2592000         ; expire, seconds
        300 )        ; minimum TTL, seconds
; name servers
        IN NS primary.foo.bar.
        IN NS secondary.foo.bar.
; mail servers
IN MX 10 mail.foo.bar.
localhost               IN A 127.0.0.1
www           IN A 192.168.10.10
mail           IN A 192.168.10.15
primary          IN A 10.40.5.2
secondary          IN A 10.40.5.240

7.2 Check the new server

Once the values in the SOA header have been updated, it is necessary to 
reload the zone and check the server is operating as expected.

In case BIND is in use, these commands can be used:

To reload the server:
# ndc reload

To check the server is running appropriately
# ndc status

If logging has been appropriately configured it is advisable to have a look 
at it to check the zone modified has been correctly loaded. If using NOTIFY 
feature, we could also see whether the server has ³notified² to the 
secondaries about it.

Finally, querying the server by using ³dig² or ³nslookup² tools is 
recommendable:

$ nslookup - 10.40.5.2
> www.foo.bar.
192.168.10.10

7.3 Create the reverse resolution of the new address

This step can be made even before installing any machine in the new range. 
You need to create a new domain configuration file, lets call iit 
10.40.5.db:

$ORIGIN 5.40.10.IN-ADDR.ARPA.
@    IN SOA primary.foo.bar. hostmaster.foo.bar. (
;
        2004072001      ; serial based on "date+number"
        86400           ; refresh
        7200            ; retry
        2592000         ; expire
        172800  )       ; minimum TTL
; name servers
        NS primary.foo.bar.
        NS secondary.foo.bar.
; hosts list
2     PTR primary.foo.bar.
10     PTR www.foo.bar.
15     PTR mail.foo.bar.
240     PTR secondary.foo.bar.

To let the DNS server know about this file you will need to edit the file 
/etc/named.conf and add:

zone "5.40.10.in-addr.arpa." {
type master;
file 10.40.5.db;
};

Reload the file DNS server configuration after this configuration.

In the secondary server simply add the following lines to /etc/named.conf:

Zone "5.40.10.in-addr.arpa." in {
Type slave;
File "db.10.40.5";
Masters { 10.40.5.2; };
};

Reload the file DNS server configuration after this configuration.

7.4 Delegate the reverse resolution of the new address range

Request to your RIR/LIR the delegation of the reverse resolution of the new 
address range.

This delegation must be made pointing to the address of the new DNS server 
s(10.40.5.2 and 10.40.5.240)

7.5 Change glue records in the parent DNS server 

This is now possible. Requesting the change of the glue records for the zone 
we are migrating is a critical administrative process consisting in 
submitting the corresponding form. In this form it will be requested the 
change of IP address for the primary server of the zone and the secondaries 
in case these would be in the network of the previous ISP and will stay 
present in the new ISP network.

Typically, ccTLD NICs have their own form, most of the times just in their 
local languages and sometimes in English as well. Using a local registrar 
entity could solve the possible language issue. The same applies basically 
for organisational TLDs (.com, .org, .net,Š).
  
The duration of this process absolutely depends on the NIC responsible for 
that domain and the period of time to wait until changes are alive, go from 
hours to even weeks.

Always consider this waiting times pessimistically when planning the 
migration.

It is fundamental that both nameservers (in case duplication was possible) 
are alive and running during this time as otherwise if the NIC checks for 
this servers and they are not alive the change would be postponed.

Once the change at the parent server occurs, the new queries will be sent to 
the new primary nameserver. Clients with the previous primary nameserver¹s 
IP address cached will not query the new server until the TTL time is 
reached. During that period of time these clients with old information 
cached will keep on querying the old primary nameserver. So the old primary 
nameserver will have to keep alive and running for some more time. This TTL 
is not controlled by us, but by the NIC. It is the TTL associated with the 
glue records for our domain in the parent¹s zone. 

The expire times obtained at the moment of the writing of this document are:

TLD             Expire time in seconds
.es                            172.800
.com, .org .net                 86.400

So until this time has elapsed since the change its unsure that the changes 
its propagated.

NICs have normally a mechanism to notify the changes have been done to the 
responsibles for the domain but it is recommended to verify this by doing 
this:

Checking the information in the whois database:  

[localhost:~] fernando% whois foo.bar
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
   Domain Name: FOO.BAR
   Registrar: NETWORK SOLUTIONS, INC.
   Whois Server: whois.networksolutions.com
   Referral URL: http://www.networksolutions.com
   Name Server: PRIMARY.FOO.BAR
   Name Server: SECONDARY.FOO.BAR
   Updated Date: 03-may-2001

7.6 Modify the external secondaries

Once the NIC has performed the requested changes in the whois database and 
the DNS parent servers and the changes have propagated it is time to update 
the secondary servers. These servers will be typically in outer networks and 
will be the corresponding administrator to whom the change request will be 
sent. The secondary nameserver administrators will have to change all 
possible reference to the primary server IP address to the new IP address 
and reload their servers if possible so changes are made alive immediately.

This change is made modifying the following fields:

In servers with version 4.x of BIND the file to be modified is 
/etc/named.boot and the change to do is substitute:

Secondary     foo.bar    192.168.10.2  db.foo

By

Secondary     foo.bar    10.40.5.2  db.foo

For servers with versions 8.x or 9.x of BIND the file to be modified is 
/etc/named.conf and the change to be made is:

Zone "foo.bar" in {
Type slave;
File "db.foo";
Masters { 192.168.10.2; };
};

By

Zone "foo.bar" in {
Type slave;
File "db.foo";
Masters { 10.40.5.2; };
};

7.7 Verify the secondaries

Once this changes are made, you must check the change using dig or nslookup 
like in the following example. In this one we suppose there is a third DNS 
server in an external network in addition to the two stated in the initial 
configuration:

$ nslookup - dns.otroservidor.com
> set type=ns
> foo.bar.
foo.bar        nameserver = primary.foo.bar
foo.bar        nameserver = secondary.foo.bar
foo.bar        nameserver = dns.otherserver.com
primary.foo.bar internet address = 10.40.5.2
secondary.foo.bar internet address = 10.40.5.240
dns.otherserver.com  internet address = 192.168.13.13

In this information you must check the information of the primary server. 
The IP address associated to this must be the new one you have just set. If 
the address is the old one the change hasn't happen because the secondary 
server didn't reload the data or is incorrectly configured.

7.8 Wait until changes are propagated

Once all changes are done, it is necessary to wait until the new information 
is propagated. The minimum time for this to happen would be the ³Expiration² 
time expressed in the SOA header. It is recommended to check the changes 
have propagated by querying other nameservers randomly chosen. When all 
these servers return (reply) the new information, it is possible to proceed 
with next steps.

This verification can be made as follows:

$ nslookup - external-name-server
> set type=NS
> foo.bar
foo.bar        nameserver = primary.foo.bar
foo.bar        nameserver = secondary.foo.bar
foo.bar        nameserver = dns.otherserver.com
primary.foo.bar internet address = 10.40.5.2
secondary.foo.bar internet address = 10.40.5.240

The answer must be the IP address of the new DNS server

7.9 Change servers IP addresses

At this stage, a new DNS server known all across the internet is available. 
The times expressed in the SOA header are still the ³reduced¹ ones, but the 
information this server about the internet servers in the organisation is 
the previous one (i.e. the old IP addresses hopefully still routed by the 
previous ISP for this organisation). It is, the ³IN A² resource records are 
still pointing to the previous IP addresses.

Next it is necessary to change the internet servers IP addresses. 

To migrate all the network it is necessary to modify all these ³IN A² 
resource records so they make reference to the new IP addresses assigned by 
the new ISP to the organisation. This has to be coordinated with the 
installation of the new systems with the new IP addresses, otherwise the DNS 
service will be pointing to unexisting internet servers. This situation is 
not problematic for workstations but for servers providing public services 
to the rest of the Internet. Specially critical would be services like 
electronic mail or web service.

Again, as it occurred with the DNS service migration, all this process will 
be much easier if duplication of servers is possible.

7.9.1 Modify "IN A" fields

After the installation of the servers in the new address range, you must 
modify the records in the new DNS servers of the domain, to point to the new 
address of the equipment. It's not compulsory to made the change in the old 
DNS servers, in theory this servers are not used anymore but, it's not a bad 
idea to change them also.

If the secondary doesn't have the updated information,  the two servers can 
distribute incongruent information, and worse, inconsistent information can 
be obtained if two servers are accessed (i.e. reading the mail from two 
different POP3 servers). 

The conclusion is that it is recommended to speed up the update of the 
secondaries. One method of instant update is using the NOTIFY[10] message, 
sent by the primary server when the information its modified. This message 
tells the secondaries that the information of that domain has been modified 
and they need to reload.

However not all the DNS servers support this message -the primary must 
support it to send the NOTIFY and the secondaries must act upon it when 
received. If a secondary doesn't support the message, try to push it doing a 
manual reload of the configuration.

The servers must be changed in the foo.db from:

www           IN A 192.168.10.10
mail           IN A 192.168.10.15

to:

www           IN A 10.40.5.10
mail           IN A 10.40.5.15

7.10 Modify SOA values

The same way we did for the DNS server changes, we will wait until the 
contents of the zone file get propagated, checking a list of nameservers to 
verify this. See section 7.7 and appendix A.

SOA times have to remain lower until all changes are done and the new 
information is propagated. Afterwards, the recommended values (v.g. RIPE 
recommended values) can be restored.

7.11 Wait the propagation

Use the method described previously with the nslookup or dig commands to 
verify the redistribution of the changes. Use a selected group of servers as 
a statistical measure of the change.

7.12 Deactivate services in the old address range

With the changes made, all request are directed to the new servers and you 
can disable all servers in the old range, including the DNS server and the 
resolution of the reverse DNS.

8 Resumed procedure

If you have experience managing DNS servers, this abbreviated list will be 
enough for you:

* Create (install and configure) a DNS server in the new address space

* Configure this server with the information related to the current servers 
and their IP. That is, copy the existing "A", "MX" records, etc.

* In this configuration, modify the primary name server record (NS) to point 
to this new server himself.

* Modify the address of the secondary name servers only if they are also in 
the address range to migrate. Don't change them if thy are located in other 
networks (ISP, carrier, NIC)

* Reduce the SOA times of the domain as indicated in appendix B

* Start the server

* Use a DNS client program (nslookup, dig) to check all the information

* Configure the inverse resolution of the new address range in the new 
server, inserting "PTR" records for all servers to be migrated

* Request the inverse resolution delegation of the new address range to the 
LIR or RIR

* Fill and send the form asking the NIC the change of primary server (and 
secondary if its located in the same network)

* Wait for the changes to take effect and to propagate

* Verify the propagation of changes with some DNS tools and checking in some 
DN servers distributed around the world

* If possible, install duplicate servers (mail, http, etc.) In the new 
address range.

* Modify the "A" records of the new DNS server to point to the new servers

* Wait to the changes to be propagated (verify again with several external 
servers)

* Restore the SOA values to their original value

* Deactivate the old DNS servers
 
9 Traumatically change of provider

The best method to migrate the services from one provider to other is to 
keep both providers and their IP address during all the change.

But if you can't have both connections simultaneously, the migration is more 
complex, critical and the blackout can be very long.

The main problem is that you can't  have both address range simultaneously 
and so you can't keep servers in both ranges at the same time.

9.1 Help from a third party

The minimum requirements are to have a DNS server visible all the time. This 
is a difficult task, because you don't know in advance when the information 
will change and some NIC ask for the new server to be configured (and they 
check it) before making the change.

The only way to meet this requirement in this scenery is through a third 
party that provides a DNS server for the domain across the migration.

In this case the only service that is keep active is the DNS. The blackout 
of all the other services depends of the time between the unplug from the 
old provider and the connection with the new one.

9.2 Steps

A quick description of the process is:

* Reduce the SOA values of the existing DNS and wait for the information to 
propagate

* Install a new DNS server in a third party network and configure that DNS 
server as a primary server

* Change the information of the NIC to point to this DNS server

* Wait the information to propagate

* Remove the servers (web, mail, etc) from the old ISP of unplug your 
network from the old ISP, depending of the situation

* Install the servers in the new ISP or connect your network to the new 
carrier. This jump from the old to the new carrier must be made ASAP to 
reduce the blackout, though usually this time depends of the providers

* In the server installed in the third party network, change the IP address 
for the new ones

* Install a DNS server in the new network and configure it as a primary of 
the domain with the address of the new servers and the NS record pointing to 
itself. Return the SOA values of this server to the original ones

* Send the request to the NIC to change the IP address of the server to 
point to this new one

* When the information is updated and propagated, disable the DNS server 
installed in the third party

During the time lapse between the unplug from one provider and the plug of 
the new one (hours, days, even weeks) there is a blackout of the services 
because the only server that answer request is the DNS server.

Apéndice A. Glossary

To Be Filled

Apéndice B. SOA values

Beside the recommendations that RIPE and the local NIC made regarding the 
SOA values to be filled in the domain files for the second level domains, to 
know the expire time of the IP address assigned to that domain you must know 
the SOA values of the TLD associated so you can check the TTL field and know 
how long will stay the old DNS server address in the cache of the client 
resolvers.

To discover this values, that sometimes are not published, do the following:

 [localhost:~] fernando% nslookup
Default Server:  dns.foo.bar
Address:  192.168.10.2
> set type=ns
> es.
Server:  dns.foo.bar
Address:  192.168.10.2

Non-authoritative answer:
es      nameserver = NS3.NIC.FR
es      nameserver = MUNNARI.OZ.AU
es      nameserver = NS.EU.NET
es      nameserver = NS.EUNET.es
es      nameserver = PRADES.CESCA.es
es      nameserver = SUN.REDIRIS.es
es      nameserver = SUNIC.SUNET.SE
es      nameserver = NS.UU.NET
es      nameserver = NS1.nic.es
es      nameserver = ineco.nic.es

Authoritative answers can be found from:
NS3.NIC.FR      internet address = 192.134.0.49
MUNNARI.OZ.AU   internet address = 128.250.1.21
NS.EU.NET       internet address = 192.16.202.11
NS.EUNET.es     internet address = 193.127.1.11
PRADES.CESCA.es internet address = 192.94.163.152
SUN.REDIRIS.es  internet address = 130.206.1.2
SUNIC.SUNET.SE  internet address = 192.36.125.2
NS.UU.NET       internet address = 137.39.1.3
NS1.nic.es      internet address = 194.69.254.1
ineco.nic.es    internet address = 194.69.254.2
> server ns1.nic.es
Default Server:  ns1.nic.es
Address:  194.69.254.1

> set type=soa
> es.
Server:  ns1.nic.es
Address:  194.69.254.1

es
        origin = ns1.nic.es
        mail addr = hostmaster.nic.es
        serial = 2001070200
        refresh = 86400 (1D)
        retry   = 7200 (2H)
        expire  = 2592000 (4w2d)
        minimum ttl = 172800 (2D)
es      nameserver = ns1.nic.es
es      nameserver = ineco.nic.es
es      nameserver = sun.rediris.es
es      nameserver = ns.eunet.es
es      nameserver = prades.cesca.es
es      nameserver = ns.eu.net
es      nameserver = sunic.sunet.se
es      nameserver = ns.uu.net
es      nameserver = munnari.oz.au
es      nameserver = ns3.nic.fr
ns1.nic.es      internet address = 194.69.254.1
ineco.nic.es    internet address = 194.69.254.2
sun.rediris.es  internet address = 130.206.1.2
ns.eunet.es     internet address = 193.127.1.11
prades.cesca.es internet address = 192.94.163.152
ns.eu.net       internet address = 192.16.202.11
sunic.sunet.se  internet address = 192.36.125.2
ns.uu.net       internet address = 137.39.1.3
munnari.oz.au   internet address = 128.250.22.2
munnari.oz.au   internet address = 128.250.1.21
ns3.nic.fr      internet address = 192.134.0.49
> 


Doing this operation for the first level domain associated to the one you're 
migrating, you can get the expire and renewal times.


For the .es domain this values are (in seconds):
Refresh       86400
Retry          7200
Expire      2592000
Minimum TTL  172800

For the .com, .net and .org domain this values are:


Refresh        1800
Retry           900
Expire       604800
Minimum TTL   86400

Apéndice C. ES-NIC form example

This is an example of the filled form that you must send to the Spanish NIC 
(ES-NIC) to address domreg at nic.es to ask for a change of address of the 
domain servers. This form has been filled with the example data used along 
this document and must be send as a ASCII text.

Note: We keep using the domain "foo.bar"  in this example, though the 
Spanish NIC only have authority to register, delegate and modify information 
of the domain under the ".es" ccTLD, so this examples is not valid -it could 
be valid if we use foo.es.

Information about how to fill this document can be obtained from the own 
ES-NIC pages [12]

FSE Version: 1.0

SECCION 0 - Tipo Solicitud
 
0a. Accion a efectuar
    (N|CR|B|CD)..................:CR
0b. Estado Dominio (para N, CR o CD)
    (R|D|MX).....................:D
0c. Dominio a expirar (para CD)..:foo.bar

SECCION 1 - Dominio Objeto de Registro

1.  Nombre Dominio...............:foo.bar

SECCION 2 - Organizacion Usuaria del Nombre de Dominio

2a. Nombre Organizacion Completo.:Foo Limitada
2b. Forma Juridica...............:S.L.
2c. N.I.F........................:B-99887766
2d. Fecha de Constitucion........:19610718
2e. Domicilio (Calle,No...)......:Fantasia, 555
2f. Domicilio (Municipio)........:Madrid
2g. Domicilio (Cod. Postal)......:E-28066
2h. Domicilio (Provincia)........:Madrid
2i. Domicilio (Pais).............:SPAIN

SECCION 3 - Para Nombre de Dominio Asociado a Marca Registrada 
en lugar de al Nombre Oficial de la Organizacion

3a. Marca Registrada en OEPM.....:
3b. Numero Inscripcion en OEPM...:
3c. Fecha de Concesion...........:

SECCION 4 - Persona de Contacto Administrativo

4a. NIC Handle...................:FGF2-NIC
4b. Nombre y Apellidos...........:
4c. Nombre Organizacion Completo.:
4d. Nombre Departamento..........:
4e. Cargo........................:
4f. Direccion (Calle,No...)......:
4g. Direccion (Municipio)........:
4h. Direccion (Cod. Postal)......:
4i. Direccion (Provincia)........:
4j. Direccion (Pais).............:
4k. E-mail.......................:
4l. Numero Fax...................:
4m. Numero Telefono..............:

SECCION 5 - Persona(s) de Contacto Tecnico

5a. NIC Handle...................:FGF2-NIC
5b. Nombre y Apellidos...........:
5c. Nombre Organizacion Completo.:
5d. Nombre Departamento..........:
5e. Cargo........................:
5f. Direccion (Calle,No...)......:
5g. Direccion (Municipio)........:
5h. Direccion (Cod. Postal)......:
5i. Direccion (Provincia)........:
5j. Direccion (Pais).............:
5k. E-mail.......................:
5l. Numero Fax...................:
5m. Numero Telefono..............:

SECCION 6 - Persona de Contacto Facturacion

6a. NIC Handle...................:FGF2-NIC
6b. Nombre y Apellidos...........:
6c. Nombre Organizacion Completo.:
6d. Nombre Departamento..........:
6e. Cargo........................:
6f. Direccion (Calle,No...)......:
6g. Direccion (Municipio)........:
6h. Direccion (Cod. Postal)......:
6i. Direccion (Provincia)........:
6j. Direccion (Pais).............:
6k. E-mail.......................:
6l. Numero Fax...................:
6m. Numero Telefono..............:
6n. N.I.F. (Organizacion en 6c)..:

SECCIONES 7 Y 8 - Para Delegacion de Zona Asociada al Dominio

7a. Nombre Servidor Primario.....:primario.foo.bar
7b. Direccion IP S. Primario.....:10.40.5.2

8a. Nombre Servidor Secundario...:secundario.foo.bar
8b. Direccion IP S. Secundario...:10.40.5.240

SECCION 9 - Para Registro(s) MX asociado(s) al Dominio

9a. Nombre Estafeta E-mail SMTP..:

SECCION 10 - Proveedor(es) de Servicio de Acceso a Internet

10. Acronimo de Proveedor........:CARRIERB


La parte solicitante de esta operacion de registro de nombre
de dominio (persona solicitante y organizacion usuaria en cuya
representacion se actua) declara que:

- Esta al corriente de las normas y procedimientos vigentes, terminos y
  condiciones, tarifas y forma de pago, requisitos tecnicos, etc. 
  establecidos para el registro de nombres de dominio bajo "es" en el DNS 
  de Internet y los acepta en su totalidad (la informacion mencionada es 
  publica y puede obtenerse en http://www.nic.es). En particular, la 
  organizacion usuaria acepta someterse a las normas, procedimientos, 
  terminos y condiciones recogidos en el documento <<Normas y Procedimientos 
  para el Registro de un Nombre de Dominio de DNS bajo "es">> (disponible en 
  ftp://ftp.nic.es/docs/es-dom-normas.txt) y a hacerlo por escrito firmado 
  en el momento en que le sea requerido.

- Conoce y acepta que las normas y procedimientos vigentes en la actualidad
  pueden sufrir en el futuro las modificaciones que el ES-NIC, la IANA
  (Internet Assigned Number Authority) o la ICANN (Internet Corporation for
  Assigned Names and Numbers) estimen oportunas.

- Los datos facilitados en la presente solicitud son ciertos, salvo error u
  omision de buena fe.

- Es consciente y acepta que cualquier falsedad en los datos consignados en 
  la presente solicitud podra ser causa de rechazo de la misma o de baja del
  nombre de dominio en cualquier momento si el registro ya se hubiera 
  producido y que, en este caso, el nombre de dominio es reutilizable para 
su 
  posterior registro por parte de otra organizacion de acuerdo con las 
normas 
  y procedimientos establecidos.

- Se compromete, una vez le sea comunicado el resultado favorable del
  procesamiento de su solicitud, al pago, en los plazos establecidos, de las 
  cuotas de alta y mantenimiento presentes y futuras que le correspondan.

- Es consciente y acepta que, en caso de impago o pago insuficiente tras los
  plazos y prorrogas establecidos, el nombre de dominio registrado sera dado 
  de baja y reutilizable desde ese mismo momento para su registro por parte 
  de otra organizacion de acuerdo con las normas y procedimientos 
establecidos.

- Es consciente y acepta que, en caso de no enviar al ES-NIC el 
correspondiente
  FSF ("Formulario de Solicitud Firmado") firmado por la persona de contacto
  administrativo de la organizacion usuaria (en los casos y plazos en que 
sea
  requerido) el nombre de dominio registrado sera dado de baja y 
reutilizable 
  desde ese mismo momento para su registro por parte de otra organizacion de
  acuerdo con las normas y procedimientos establecidos.
  
- Es consciente y acepta que, en caso de incompetencia o negligencia 
tecnica, 
  un nombre de dominio registrado puede ser dado de baja de forma temporal o
  definitiva.

- De acuerdo con su conocimiento, el uso del dominio propuesto no viola los
  derechos de ninguna tercera parte.

- Es consciente y acepta de que el registro por parte del ES-NIC del nombre 
  de dominio propuesto no le confiere ningun derecho legal sobre el mismo y 
  de que cualquier disputa sobre los derechos de uso de un determinado 
nombre 
  de dominio habra de ser resuelta entre las partes contendientes utilizando 
  los cauces legales normales, tal y como establece el documento de Internet 
  RFC 1591. Asimismo acepta que, en caso de disputa, el ES-NIC no tendra 
otro
  papel ni responsabilidad que el de facilitar a las partes en conflicto la
  informacion de contacto necesaria para que puedan resolver sus diferencias 
  de la forma que crean oportuna (acuerdo bilateral, Juzgados y Tribunales 
  competentes, etc.).

- La persona de contacto administrativo de la organizacion usuaria 
facilitada 
  en la presente solicitud es el responsable a todos los efectos de 
cualquier
  problema relacionado con los derechos de uso del nombre, lo cual es 
conocido 
  y aceptado por el.

- Todas las entidades y personas relacionadas en la presente solicitud son
  conscientes de ello y se cuenta con su consentimiento, de acuerdo con lo
  establecido por la Ley Organica 15/1999 de 13 de diciembre de Proteccion 
de
  Datos de Caracter Personal, para que sus datos aparezcan en las bases de 
datos 
  internas y publicas mantenidas por el ES-NIC.

- Se compromete a mantener siempre actualizada la informacion facilitada
  en esta solicitud, mediante el envio al ES-NIC de solicitudes de cambio 
  de los datos de un registro previo siempre que haya modificaciones en
  cualquiera de los datos consignados. El no hacerlo asi puede dar lugar a 
  que el dominio sea dado de baja (por ejemplo, por imposibilidad de 
  comunicar con las personas que figuran como responsables de facturacion,
  administrativo o tecnico del dominio al no haber notificado cambios de 
  sus datos de contacto o cambios de responsables).

  

Apéndice D. References

[1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, RFC 
1918 - Address Allocation for Private Internets, February, 1996

[2] ripe-192 - Simple DNS Configuration Example 

[3] ripe-203 - Recommendations for DNS SOA Values 

[4] ripe-114 - Taking Care of Your Domain

[5] "DNS & BIND 3rd Edition" by Paul Albitz & Cricket Liu, O'Reilly & 
Associates Inc.

[6] http://www.apache.org/

[7] D. Eastlake 3rd, C. Manros, E. Raymond, RFC 3092 - Etymology of "Foo", 
April,1 2001

[8] Alan O. Freier, Philip Karlton, Paul C. Kocher, Internet Draft - The SSL 
Protocol Version 3.0  <draft-freier-ssl-version3-02.txt>, November, 18 1996

[9] D. Barr, RFC 1912, Common DNS Operational and Configuration Errors, 
February, 1996

[10] P. Vixie, RFC 1996, A Mechanism for Prompt Notification of Zone Changes 
(DNS NOTIFY), August, 1996

[11] http://www.nic.es/FSE/index.html

[12] ftp://ftp.nic.es/docs/es-dom-dnsconfig.txt

-- 
----------------------------------------------------------------------------
--
Fernando Garcia - fgarcia at eurocomercial.es
Eurocomercial Informática y Comunicaciones
91 435 96 87
----------------------------------------------------------------------------
--