> Despite the stated technical merits of a single root,
> I think one needs to reflect on the implications that
> a few of the world's largest ISPs appear to have made
> a business decision to use a superset of the ICANN/US
> Department of Commerce's root zone.
>
> Which big ones? I've never seen any official message about this.
See www.new.net/about_us_partners.tp. Earthlink and Netzero
have been listed as the US' second and third largest ISPs
(according to http://www.ispworld.com/isp/TRI_census.htm).
That's not even counting Excite@Home.
>
> It's claimed that the US had about 100 million Internet
> users in December 2000. According to New.net's numbers
> (which needs to be confirmed), about 16% of those can now
> use their alternative root.
>
> I've seen various claims by various alternative root operators. None
> have been confirmed by independent research as far as I know.
New.net claims that 16 million users can resolve their TLDs based
on their partnerships with ISPs (like I said, this needs to be
confirmed independently).
16 million of 100 million is 16%.
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
Despite the stated technical merits of a single root,
I think one needs to reflect on the implications that
a few of the world's largest ISPs appear to have made
a business decision to use a superset of the ICANN/US
Department of Commerce's root zone.
It's claimed that the US had about 100 million Internet
users in December 2000. According to New.net's numbers
(which needs to be confirmed), about 16% of those can now
use their alternative root.
If this percentage continues to grow, ICANN's ability to
control what goes into the DNS would seem to be constrained.
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
>X-Recipient: <exp-nanog(a)ripe.net>
>Delivered-To: nanog-outgoing(a)merit.edu
>X-Sender: hank(a)max.ibm.net.il
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Tue, 13 Mar 2001 10:03:14 +0200
>To: nanog(a)merit.edu
>From: Hank Nussbacher <hank(a)att.net.il>
>Subject: Statements against new.net?
>Sender: owner-nanog(a)merit.edu
>X-Loop: nanog
>
>
>Do any ISPs or web hosting companies have publically available statements on their web sites stating that they will not support the new new.net domains and why they won't? I am getting more requests from users to change our DNS root servers to support this and wanted to see what others tell their users. Any IETF/ICANN statement available?
>
>Thanks,
>Hank
>
>
Dear fellow WG members,
I have just submitted a new version of the "very long" document (the last in
our trilogy) to the Internet Drafts archive.
The name will be draft-koch-ripe-dns-setup-guide-01.txt. Please note that
the version currrently available with that name is only the expiration
notice for the "00" version submitted last February.
Until the document will have shown up at the ID-archive and its mirrors you'll
find a copy with this URL:
http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-koch-ripe-dns-setup-guide…
Changes are mostly editorial and filling some gaps (those marked TBD earlier).
I have now put in some words about IPv6, DNSSEC and IDN. The first three
sections should be complete now, some text is still missing for the
reverse mapping and 'popular mistakes' sections.
What I'd like to discuss next week (if there's a time slot available):
o Status of and further roadmap for the document
Especially in the light of DNSSEC and, even more, IDN, it seems a bit
difficult to prepare a single, fixed document to inform the target
audience. A living document, i.e. a ``web site'' would be better and
more up to date - if there's someone/somegroup periodically taking care.
I think the IETF's experience with the "weird" wg teach some lesson here.
On the other hand, just pointing everyone to the DNS resources directory
and the IETF to find ``everything'' is not a helpful advice IMHO.
o How to perform the "Grandma test"?
Should we decide to go on with this document it should be exposed to some
target audience people and *feedback* be collected and reported.
Volunteers?
Here are two further suggestions for the agenda:
o Review of RIPE 203
Has anyone successfully referred customers to this document?
Are their any changes suggested/needed?
o DNS traffic and ~ distribution
Does anyone have recent data on what percentage of backbone traffic is
DNS traffic and how this DNS share is split between e.g. RR types?
-Peter
We took it offline because IANA now has a more complete and
up-to-date data at http://www.iana.org/cctld/cctld-whois.htm.
We did the survey because so much stuff was out of date at
that time and in some cases, you couldn't even track down
who was running a ccTLD.
We gave all the survey data to IANA and it looks like they're
doing a good job at keeping it fresh.
Bob
--
Robert Shaw <robert.shaw(a)itu.int>
ITU Internet Strategy and Policy Advisor
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
> -----Original Message-----
> From: Robert F. Connelly [mailto:rconnell@psi-japan.com]
> Sent: Tuesday, November 07, 2000 7:18 AM
> To: Robert Shaw
> Cc: dns(a)iia.net.au; dns-wg(a)ripe.net; Barbara t.H. Farrell
> Subject: Re: PAB ISO 3166-based Top Level Domain Survey
>
>
> At 05:55 PM 6/19/98 +0200, Robert Shaw wrote:
> >At http://www.itu.int/net/cctlds/nics.htm is a preliminary survey
> >conducted by ITU of Internet ISO 3166-based top level domains.
>
> Dear Bob: Where has this file been moved? Regards, BobC
>
> .nt is not on this list but I know it exists.
If it does, it shouldn't. It's not part of the ISO 3166
standard. NT (Neutral Zone) is on the ISO 3166 transitional
reserved phase-out list which means don't use it.
Bob
Hi,
At http://www.itu.int/net/cctlds/nics.htm is a preliminary survey
conducted by ITU of Internet ISO 3166-based top level domains. The
material is in in draft form and is made available in order to solicit
public comment. Information includes all known URLs for registration.
While every attempt has been made to ensure accuracy, the information
cannot be considered authoritative as the Internet Assigned Numbers
Authority (IANA) is the authoritative source for ISO 3166-based
top level domain delegation information. All raw data gathered has
been and will continue to be provided to IANA.
Comments and/or corrections on these pages should be sent to
Ms. Asa Johansson at <asa.johansson(a)itu.int>.
Denominations and classifications employed in this publication do not
imply any opinion on the part of the ITU concerning the legal or
other status of any territory or any endorsement or acceptance of
any boundary.
Thanks,
Robert
--
Robert Shaw <robert.shaw(a)itu.int>
Advisor, Global Information Infrastructure
International Telecommunication Union <http://www.itu.int>
Place des Nations, 1211 Geneva, Switzerland
Dear working group members,
I apologize for sitting a bit too long on Vesna's draft minutes for the
Budapest session. Vesna did a really good job; please find the draft
below.
I'll wait for comments until Sept. 30th. So the draft is expected to become
final on October 1st.
I'm sorry that some problems in my day job escalated yesterday evening in
ways so that today in the early morning it turned out that there would be
no way to make the planned trip to Amsterdam safely and in time.
(There is a down side to having the conference locally - or "within short
driving distance":-(
I hope those attending the current meeting do have a good time;
looking forward to see you again at future meetings.
Regards,
Ruediger
Ruediger Volk
Deutsche Telekom AG -- Internet Backbone Engineering
E-Mail: rv(a)NIC.DTAG.DE
Phone: +49 251 7985 200 fax: +49 251 7985 109
DNS Working Group
RIPE #36, Budapest
18 May 2000
Chair: Rudiger Volk
Scribe: Vesna Manojlovic
Agenda:
0. Agenda bashing
1. David Conrad, ISC: BIND 9
2. Bill Manning: Preparing for DNS evolution
-=-
coffee break
-=-
3. Report from CENTR DNSSEC workshop
4. IETF - Randy Bush
5. AOB
5.1. Fernando - Document about re-delegation
5.2. RIPE documents published since the previous meeting
1. David Conrad gave quick update of current status of BIND
BIND9
* complete rewrite of code
* includes support for everything
- full IPv6 support
- DNSSEC support
- not supporting EDNS1
- multi-lingual support
- MS interoperablity
* RFC compliant (first time, cheers from the audience :)
- first time it has lots of documentation :)
* 1.2 mil $ to develop
* release - 30.6.
* availability now - beta
David was asking the audience for help :
- to support INN (BIND and DHCP are supported by Nominum)
- from people with NT experience to debug NT port of BIND 8.2.3
- to test BIND9
- performance
- IPv6 support in BIND 9
- DNSSEC
2. Bill Manning -- Wither DNS?
PPT presentation available on
http://www.ripe.net/ripe/meetings/archive/ripe-36/presentations/
Current assumptions:
- constant MTU
- ASCII
- BIND (UNIX based)
- single authority (server)
- hierarchy
- zone management
- static behaviour (client)
- merged server and resolver
- reachability: reliable network (up, end-to-end)
On the horizon:
DNSsec
IPv6
dynamic DNS
integration with other applications - database back-end
(LDAP,Oracle,mail) I18N (internationalisation)
DNS version diffusion survey Q&A session:
Q: how is this taken?
A: exhaustive search of inaddr tree.
Q: is it biased?
A (audience): it is security biased! they are not responding if
they are security conscious => shows higher % of vulnerable
Q: how big is the percentage of the servers that are blocked by
firewall and therefore not included?
A: few years ago - 20%. recently - 25%
Conclusion: people are moving into new code but not (as) fast (as ... )
Discussion about IPv6 inverse tree
Randy Bush: Is IPv6 inaddr tree going to be set-up separately?
(rfc 2826)
Bill: That is the suggestion (to use separate set of root nameservers)
Randy: That would cause technical and other problems. Other
possibility is to take one of existing root servers.
-= coffee break =-
3. Report from DNSSEC workshop
Workshop was initiated by CENTR, held in NLnet labs in Amsterdam.
One report was already done by Jaap Akkerhuis in CENTR DNR-wg;
technical report - here.
The goal was to check resources needed for introducing DNSSEC on the
level of TLD zones.
Result of the previous previous attempts was: it is still hard
work, not feasible at this time. This new workshop gave different
results.
In Europe, .de tld zone is chosen as the worst case. Experiment
was done with off-the-shelf PC, with extra large memory.
"Signer" software was provided by Nominum.
Two test runs were done:
1. on original data
signing -- ~ 14 hours CPU time
expansion factor of 4.4 (of adding all the dnssec data)
2. modified zone
(taken out mx & A records; left just ns)
runtime -- 3.2 hours of CPU time
117 mb -> 380 mb, so expansion factor a bit lower (3.2) for
smaller base data
Conclusion: you need some resources, but it's within the reach of
current hw and sw.
the few people with much larger zones will have more work -
but it can be assumed they'll have more revenues.
Q: Does it mean a recommendation to DEnic to get rid of mx only
domains?
A: yes
Q: Compared with Swedish workshops?
Liman: different, smaller results. Bigger times & data. Used
signer from bind8.
Q: What do you consider normal zones?
A: Less then a million records. (.de = 3,000,000 RR)
Liman: Does it make a difference if you have to include ns or mx/a
records?
David: Not significant.
David: Wildcards in the sign zone makes signing 2 orders of
magnitude more difficult. We don't support them!
Liman: Only in DNSSEC?
David: Yes, only if you try to sign them; we either ignore them or
generate an error.
4. Randy Bush: DNS from IETF perspective
What features are important?
For a log time, specifications were stable, code was fairly
unstable. Now we are in period when specifications are fairly
stable, and the code is little unstable.
The increased features that are being specified will cause code
instability that will last forever (you can't have all this sugar
and not be unhealthy).
Main new features: security / DNSSEC & multi-lingual support / IPv6
Security problem:
For example: the size of the root zone sign becomes larger then
bits in the MTU of the standard UDP packet and therefore all the
sessions will fall back to TCP and cause 6 times bigger amount of
traffic.
Multi-lingual problem:
It's not really the DNS problem, but application problem - what is
my web browser going to be able to read. i like to call it not
internationalisation but localisation, which can cause that our
customers not able to do e-commerce with Japanese customers
David: stability of the code: bind9 _designed_ and not _evolved_ ;
therefore more stable. architectured much better.
Bill: operational community has to find the way to provide the
feedback to engineering community. this forum might be a right
place for it.
Randy: yes - we need operators back in ietf. protocols became
designed without taking a consideration operational issues.
David(?): ietf is quite large cumbersome. having smaller groups of
operational people come to some consensus, and then having
spokesperson is probably a better solution.
Chair: in communities like this there is opportunity to keep
information flow in both directions.
The survey was conducted by Bill to check who is using which
version of BIND.
Results: [ ]
5.1. Document about re-delegation
Draft paper on how to help re-delegation was presented in RIPE #33
in Vienna by Fernando [ ].
Paper was describing the case of DNS transfer of customers from
one ISP to another - how that can be done without losing the
service, how to minimise problems, including variations of cases
of (non)cooperating ISPs.
Help is needed about transfer procedures in ccTLD zones other then
.es .
Question from the audience: Wouldn't CENTR think they should take
part in it? Since large amount of these re-delegations problems
are from ccTLD registrars.
Chair: Indication of involvement should come from CENTR. However,
administrative procedures in many registrars are much worse then
they should be; we should push CENTR in the right direction.
Liman: There should be one document describing technical issues
(in which order what.. ), which are the same all over the world;
then, what are the implications of administrative models; and in
the different part of the same document, point to possible
pitfalls.
ACTION on Fernando to sent index/draft to the DNS-WG mailing list;
make appendix about procedures in the registries/registrars that
we know about.
5.2. RIPE documents published since the previous meeting
- Recommendations for DNS SOA Values (RIPE-203)
- Simple DNS Configuration Example (RIPE-192)
There is work in progress on more detailed documentation. Peter
Koch was encouraged to work more on it.
Chair invited everyone to express their need for new documents.
Q: There is confusion about old and new minimum value in bind4
and bind8.
Liman: Dummy guide is meant for "the newest version of BIND".
Comments about other versions are welcome, but should be published
as separate document.
--==_Exmh_9077542070--
Hello all
In the last RIPE meeting I made a proposal for a document that would help
hostmasters to change domains between ISPs, carriers, etc.
Included in this message is a draft version of that document. Is not
perfect, but I think is a good starting point that can be completed by all
the members of the WG.
Regards, Fernando Garcia.
--------------------------------------------------------------------
Fernando Garcia | Email: fgarcia(a)eurocomercial.es
EuroIDT - Eurocomercial | Tel: +34 91 435 96 87
Internet Development Team | http://www.eurocomercial.es/
--------------------------------------------------------------------
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(a)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(a)eurocomercial.es
EuroIDT - Eurocomercial | Tel: +34 91 435 96 87
Internet Development Team | http://www.eurocomercial.es/
--------------------------------------------------------------------
