[dns-wg] Final version of the DNS Migration document
- Next message (by thread): [dns-wg] Action Item 48.1: Lame Delegations -- first draft
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
fgarcia at eurocomercial.es
fgarcia at eurocomercial.es
Mon May 2 14:58:27 CEST 2005
In RIPE 49 I introduced a draft version of a document oriented to provide
guidelines to operators in the migration of their communications
infrastructure, specially DNS servers, from one network to other.
We agreed to create a small workgroup to improve the document and this
group has worked to create this new version.
Now I post to this list so everybody can read it before the WG on
thursday. If there's no oposition we think this document can be approved
as a official RIPE document and simultaneously I will start working in a
second version with some improvements (IPv6 support and others provided by
the audience).
And now, the document:
-----------------------------------------------------------------------------
F.Garcia, Eurocomercial Informatica y Comunicaciones October 2004
Version: 1.0
DNS recommendations and procedures during IP migration
INDEX
-----
1 - Abstract
2 - Prerequisites
2.1 - Minimal DNS understanding
2.2 - Control over the new DNS servers
2.3 - Simultaneous addressing
2.4 – Authorized contact at the related NIC
2.5 - Schedule on time
2.6 - Duplicate DNS HW vs double IP configuration
2.7 - Internet Services dedicated HW
2.8 - Coordination and cooperation between ISPs
3 - Scenario
3.1 - Starting situation
3.2 - Final situation
3.3 - Limitations
4 - Migration procedure
4.1 - Install a new DNS server
4.1.1 - Duplicate the information for the domain
4.1.2 - Modify the server’s own address
4.1.3 - Reduce the SOA times
4.2 - Check the new DNS server
4.3 - Create the new reverse resolution zone file
4.4 - Delegate the reverse resolution
4.5 - Change glue records in the parent DNS server
4.6 - Modify the secondary servers list
4.7 - Verify the secondaries
4.8 - Wait until changes are propagated
4.9 - Change servers’ IP addresses
4.9.1 - Modify "IN A" resource records
4.10 - Wait for propagation
4.11 - Restore SOA Values
4.12 - Shutdown servers in the old IP range
APPENDIX A - SOA Values
APPENDIX B - Bibliography
--
1 - Abstract
One of the most complex and problem prone situations which might happen
when 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 implies an orderly sequence of
changes in the information services under the organisation’s domain name
(i.e. web, e-mail, ftp, ...). These changes basically involve updating the
IP addresses of these services/servers in the primary DNS server for that
domain.
Since this is not a situation which network or systems administrators need
to handle very often, it is common to make mistakes when undertaking the
migration process, mistakes which might be fatal for the services
depending on the DNS service.
This document is intended to be a step by step guide to system and network
administrators, so they can have a problem free migration with full
continuity of all services.
Procedures will be defined in the most generic way possible, so that this
will be a useful tool for all administrators.
2 - Prerequisites
To be able to do the migration process and avoid problems, the
administrator must check in advance that all requirements needed for the
migration are met.
2.1 - Minimal DNS understanding
Although this procedure does not require in-depth knowledge of the DNS
protocol and its implementations, it is necessary to have a minimal
understanding of DNS fundamentals and the implementation used. (i.e. BIND,
NSD, ADNS, dnscache, etc). The bibliography listed in appendix B should be
useful for this purpose.
2.2 - Control over the new DNS servers
The person in charge of the domain migration, or an operator 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.
2.3 - Simultaneous addressing
The procedure described in this document, requires that both ranges of IP
addresses be simultaneously active during the migration. Therefore, the
organisation must stay connected to both ISPs until the migration is
complete.
2.4 - Authorised contact at the related NIC
The person responsible for the migration must be registered with the NIC
as the administrative and/or technical contact, with permission to make
changes in the domain information, specifically the host name and IP
address of the domain name servers.
2.5 - Schedule on time
In order to avoid problems with time expiration and with incorrect cached
data all the migration procedure must be scheduled with plenty of time.
Two weeks should be safe if following the standard SOA values recommended
by RIPE and/or the local NIC.
2.6 - Duplicate DNS HW vs double IP configuration
This migration plan requires that the hardware used by the DNS servers is
independent of the hardware used by the other servers and services to be
transitioned, so that the change of network configuration on these servers
can be made without impact on the other services.
Also, to ensure the stability of the services, these DNS servers must be
duplicated during the transition, so you need duplicate machines. It might
also be possible in some situations to migrate from one IP space to a new
one configuring the same server with different IP addresses so that the
DNS server can listen on both of them.
If using BIND 9 and you’re familiar with it, you can use the views
mechanism to have different replies going out (the old and the new address
ranges) depending on the interface and use only one server with dual IP.
This is not always possible: If the network is migrated from one physical
location to other while the addressing change takes place, you can't keep
the server running with both IP addresses. Also, some NICs check
thoroughly the DNS zone file before making the migration, and some
inconsistencies, like having the IP address of the DNS server incorrectly
stated in the zone file, can trigger alarms and abort the change.
2.7 - Duplicate Internet Services HW
Duplicating the other Internet Services equipment will not only allow the
domain to be visible at all times throughout the transition, but also to
keep the services running during the entire process.
The discussion about duplicate hardware vs double IP configuration also
applies here.
If you do not use duplicate servers or dual IP addressing in the machines,
you will have to accept temporary lack of availability of services during
the transition.
2.7 - Coordination and cooperation between ISPs
This kind of transition frequently occurs because you are moving from one
service provider to another. In these cases, you may not be able to get
much assistance from the provider you are leaving, but this process is
likely to be much more difficult without the help of both providers, so
you must try all reasonable methods to get support from both providers.
3 - Scenario
The proposed scenario is probably one of the most complex possible, but
it's also one of the most generic, and can be tailored to other situations
removing the extra procedures.
All examples across the document use the RFC 1918 IP address ranges [1].
Obviously the addresses to use during a real migration should be the ones
assigned to the organisation by the corresponding RIR/LIR.
REMEMBER: The addresses used in this document are not valid addresses and
you should replace them with your own addresses, so do not simply copy and
paste these examples, and double check the information for correctness.
Likewise, the domains and subdomains used in the examples are fictitious
and use the standard "example.com"[2]. You should replace this fictitious
domain with your assigned domain name.
All examples in this document assume that your DNS servers use BIND 9.x
running over some kind of Unix/Linux server. You should adapt these
examples to your own DNS SW implementation.
3.1 - Starting situation
Organisation X has registered the domain "example.com". This organisation
X has Internet connectivity through Internet carrier A, which has assigned
to organisation X the IP range 192.168.10.0/24 of its PA (provider
aggregatable) addressing block.
Organisation X also has a secondary DNS server hosted in an external
network for purposes of DNS redundancy. The IP address of this server is
172.16.5.2
Using this range, the network administrator of the organisation X has
inserted the following information in the glue records of the delegating
zone:
* Primary server of the domain "example.com": 192.168.10.2
* Secondary server of the domain "example.com": 172.16.5.2
The domain servers are configured consequently with these address and
their DNS servers to translate their names to its IP address:
* www.example.com translates to 192.168.10.10
* mail.example.com translates to 192.168.10.15
He also configured the mail server information for the domain:
* The mail server for the domain example.com is mail.example.com with a
preference of 10
The administrator of the network has configured the inverse resolution of
the network in the name servers after delegating this inverse resolution
in the RIR/LIR.
The network administrator has configured the inverse resolution of the
network in the name servers after getting the corresponding in-addr.arpa.
domain delegated from the RIR/LIR.
The zone configuration files should be as follows:
(ripe-203 SOA values have been used)
$ORIGIN example.com.
;
@ IN SOA primary.example.com. hostmaster.example.com. (
2001070401 ; serial based on "date+number"
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
172800 ) ; Minimum TT, seconds
; name servers
IN NS primary.example.com.
IN NS secondary.example.com.
; mail servers
IN MX 10 mail.example.com.
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 172.16.5.2
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.example.com. hostmaster.example.com. (
;
2001070401 ; serial based on "date+number"
86400 ; refresh
7200 ; retry
3600000 ; expire
172800 ) ; minimum TTL
; name servers
IN NS primary.example.com.
IN NS secondary.example.com.
; host lists
2 IN PTR primary.example.com.
10 IN PTR www.example.com.
15 IN PTR mail.example.com.
3.2 Final situation
After the migration is complete, the organisation "X" will be connected
through carrier "B" and both organisations have agreed carrier "B" to
assign to organisation "X" a new IP range, specifically 10.40.5.0/24.
The new servers will have the following information:
* Primary server for the domain "example.com": 10.40.5.2
* Secondary server for the domain "example.com" (it doesn't change):
172.16.5.2
The address for the associated servers should be set as follows:
* www.example.com translates to 10.40.5.10
* mail.example.com translates to a 10.40.5.15
The mail server will be configured for the domain as follows:
* The mail server for the domain example.com is mail.example.com with a
* preference of 10 and no secondary mail server
The reverse resolution for the new IP range will be delegated and
configured correctly.
The archive for the zone must eventually have this configuration:
$ORIGIN example.com.
;
@ IN SOA primary.example.com. hostmaster.example.com. (
2001072001 ; serial based on "date+number"
86400 ; refresh, seconds
7200 ; retry, seconds
3600000 ; expire, seconds
172800 ) ; minimum TTL, seconds
; name servers
IN NS primary.example.com.
IN NS secondary.example.com.
; mail servers
IN MX 10 mail.example.com.
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 172.16.5.2
And the DNS configuration for the new inverse resolution, that you should
be delegated from the RIR/LIR, will be:
$ORIGIN 5.40.10.IN-ADDR.ARPA.
@ IN SOA primary.example.com. hostmaster.example.com. (
;
2001072001 ; serial based on "date+number"
86400 ; refresh
7200 ; retry
2592000 ; expire
172800 ) ; minimum TTL
; name servers
IN NS primary.example.com.
IN NS secondary.example.com.
; hosts list
2 IN PTR primary.example.com.
10 IN PTR www.example.com.
15 IN PTR mail.example.com.
3.3 - Limitations
Some of the procedures described in this work are specific of each NIC,
mainly the administrative tasks and the forms to be submitted.
In the following description the steps associated with the NIC are
explained generically using the common subset.
4 - Migration procedure
The underlying idea is to achieve the transition in a limited number of
steps, and to complete each one of them, including the times required for
the changes to get propagated, before starting the next step.
4.1 - Install a new DNS server
As explained before, it is advisable to install a new primary DNS server
with the new ISP's IP addresses, and otherwise the same information as the
old DNS primary server.
The steps to introduce new data in this machine are:
4.1.1 - Duplicate the information for the domain
Once there is a new primary nameserver in the new ISP (i.e. either running
BIND, dnscache, djbdns, nsd, etc) the configuration and zone files need to
be the same as those in the nameservers hosted by the previous ISP (which
are still up & running), except for minor changes.
This can be achieved with a zone transfer (AXFR) from the old primary
server to the new server. If running BIND, this can be achieved by running
the following command:
#dig @192.168.10.2 example.com. axfr in > /etc/example.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 "example.com." {
type master;
file example.db;
};
It is essential to preserve the current addresses for the internet
servers, so for instance our web server www.example.com must continue to
have a "IN A" record with its original IP address:
$ORIGIN
<...>
www IN A 192.168.10.10
4.1.2 Modify the primary DNS server's IP address
It is also necessary to edit the zone file (example.db) to modify the "IN
A" resource record of the DNS server to point to itself.
From: primary IN A 192.168.10.2
To: primary IN A 10.40.5.2
The secondary servers only need to be modified if they are in the IP space
of the previous ISP. However, remember that having all your name servers
in the same subnetwork is not recommended. See section 3.1 of RFC 2182 [5]
for an explanation.
So far no changes have been made in the parent servers hosted by the
corresponding NIC or registrar. This will be done after a few additional
steps.
4.1.3 Reduce SOA times
Once the described changes are done in the zone file, it is necessary to
reduce the times expressed in the SOA header of the zone file
"example.db".
Originally, if RIPE recommendations are adopted, the SOA header will look
like this:
@ IN SOA primary.example.com. hostmaster.example.com. (
;
2001072001 ; serial based on "date+number"
86400 ; refresh, seconds
7200 ; retry, seconds
2592000 ; expire, seconds
172800 ) ; TTL minimum, seconds
It is recommended to take note of these values, in order to restore this
configuration after the migration process is completed. Suggested values
for this field depend of the load of the servers, how critical the
services are, and if they can be duplicated. If some of them can be
duplicated and/or are not critical, the values can be relaxed.
Field Old value New value without dupl. New value with dupl.
Serial number X X+1 X+1
Refresh 86400 300 14400
Retry 7200 150 (=)7200
Expire 2592000 (=)2592000 (=)2592000
TTL 172800 300 14400
- Fields marked with (=) do not need to be modified and can preserve their
original values.
- The field "serial" must be incremented with respect to the previous
value of the same field. This is the only technical requirement of this
field, but most organisations related to 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.
- Refresh: as in the case where duplication of nameservers was possible,
reducing this time to a lower value, makes the secondary servers transfer
and update the zone file more often, so the duration of a possible
blackout is reduced to that time (i.e. five minutes).
Query rate will raise in the servers, as the information cached will last
for only five minutes (i.e. due to the TTL value) and it will be queried
much more frequently than usual, but still this is considered to be a safe
value. In case most of the DNS traffic received by this organization comes
from the same time zone, it is advisable to perform all these changes
during the period of lower load on the services, usually by night (or
during the weekend).
After all these changes the file "example.db" will have the following
data. Take into account that the only A resource records that have new
values are the ones of the DNS servers themselves:
@ IN SOA primary.example.com. hostmaster.example.com. (
;
2001072002 ; serial based on "date+number"
300 ; refresh, seconds
150 ; retry, seconds
2592000 ; expire, seconds
300 ) ; minimum TTL, seconds
; name servers
IN NS primary.example.com.
IN NS secondary.example.com.
; mail servers
IN MX 10 mail.example.com.
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 172.16.5.2
4.2 - Reload the DNS server
Once the values in the SOA header have been updated and reduced, it is
necessary to reload the zone and check that the server is operating as
expected. In case BIND is in use, these commands can be used:
To reload the server if using BIND 8:
# ndc reload
To reload the server if using BIND 9:
# rndc reload
To check that the server is running appropriately:
# ndc status
or with BIND 9:
# rndc status
If logging has been appropriately configured, it is advisable to check the
logs and verify that the zone modified has loaded correctly. If using the
NOTIFY feature, we could also see whether the server has "notified" the
secondary servers about the changes.
Finally, querying the server by using the "dig" tool is recommendable:
$ dig @10.40.5.2 www.example.com
; <<>> DiG 9.2.2 <<>> @10.40.5.2 www.example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26413
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 192.168.10.10
;; AUTHORITY SECTION:
example.com. 300 IN NS primary.example.com.
;; ADDITIONAL SECTION:
primary.example.com. 300 IN A 10.40.5.2
;; Query time: 4 msec
;; SERVER: 10.40.5.2#53(10.40.5.2)
;; WHEN: Sun Mar 27 21:47:15 2005
;; MSG SIZE rcvd: 81
4.3 - Create the new reverse resolution zone file
The reverse mapping does not suffer from any race condition. You can
safely set it up in advance for the new address space and take down the
old addresses after the migration. There are also no glue records problems
so this step can be taken even before installing any machine in the new
range.
You need to create a new domain configuration file for the reverse zones
and add it to your DNS server configuration file.
Reload the DNS server configuration after these changes so the new
information is served.
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 DNS server configuration file after this configuration.
4.4 - Delegate the reverse resolution
Request to your RIR/LIR the delegation of the "in-addr.arpa." zone
corresponding to the new IP range.
This delegation must be made pointing to the address of the new DNS
servers (10.40.5.2 and 10.40.5.240)
4.5 - Modify 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 wich involves
submitting the corresponding form. In this form, you need to request the
change of IP address for the primary server of the zone, and also for the
secondaries in case these were in the network of the previous ISP and will
move to the new ISP network.
Typically, ccTLD NICs have their own form, usually 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
generic TLDs (.com, .org, .net, etc).
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, may go
from hours to even weeks.
NICs will normally have a mechanism to notify the domain owners that the
changes have been applied, but it is recommended to verify this by
following this procedure.
Checking the information in the whois database:
[localhost:~] fernando% whois example.com
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: example.com
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: PRIMARY.example.com
Name Server: SECONDARY.example.com
Updated Date: 03-may-2001
4.6 - Modify the secondary servers list
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 should be in different
networks and hence change requests will be sent to the corresponding
administrators. The secondary nameserver administrators will have to
change all possible references to the primary server IP address to the new
IP address and reload their servers if possible so that changes become
effective immediately.
This change is made by modifying the following fields:
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 "example.com" in {
Type slave;
File "db.example";
Masters { 10.40.5.2; };
};
Where 10.40.5.2 is the IP address for the new primary nameserver of the
domain.
4.7 - Verify the secondaries
Once these changes are made, you must check the change using dig as in the
following example:
$ dig @ secondary.example.com example.com
; <<>> DiG 9.2.2 <<>> @secondary.example.com example.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22267
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 300 IN NS primary.example.com.
example.com. 300 IN NS secondary.example.com.
;; ADDITIONAL SECTION:
primary.example.com. 300 IN A 10.40.5.2
secondary.example.com. 300 IN A 172.16.5.2
;; Query time: 71 msec
;; SERVER: 172.16.5.2#53(secondary.example.com)
;; WHEN: Sun Mar 27 21:58:41 2005
;; MSG SIZE rcvd: 61
You must check the information of the primary server shown in the reply.
The IP address associated to this must be the new one you have just set.
If the address is the old one, then the change has not taken effect
because the secondary server did not reload the data or it is incorrectly
configured.
4.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 as in the previous step. When all these servers return (reply) the
new information, it is possible to proceed with the next steps.
4.9 - Change servers 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
to the organisation by the new ISP. This has to be coordinated with the
configuration of the new systems with the new IP addresses, otherwise the
DNS service will be pointing to non existing internet servers. Again, as
it occurred with the DNS service migration, all this process will be much
easier if duplication of servers is possible.
4.9.1 - Modify "IN A" RRs
Once the servers are installed in the new IP range it is necessary to
modify the "IN A" resource records so they point to the new servers. This
means editing and modifying the zone file content. The servers must be
changed in the example.db zone file 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
4.10 - Wait for propagation
Use the method described previously with the dig command to verify the
redistribution of the changes. Use a randomly selected group of servers as
a statistical measure of the change.
4.11 - Restore SOA values
Just like we did for the DNS server changes, we will wait until the
contents of the zone file get propagated, checking a list of random
nameservers to verify this.
SOA times have to remain low until all changes are done and the new
information is propagated. Afterwards, the recommended values (v.g. RIPE
recommended values) should be restored.
4.12 - Shutdown services in the old IP range
Once the changes are done, all request are directed to the new servers and
you can then shutdown all servers in the old IP range, both DNS and
Internet services servers.
--
APPENDIXES
APPENDIX A. 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,
in order to know the expiration time of the IP addresses assigned to that
domain, you must also know the SOA values of the TLD associated. You can
then check the TTL field and know how long the old DNS server address will
stay in the cache of the client resolvers.
To discover these (sometimes unpublished) values, do the following:
[localhost:~] fernando% dig es. ns
; <<>> DiG 9.2.2 <<>> es. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56403
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;es. IN NS
;; ANSWER SECTION:
es. 3571 IN NS munnari.oz.au.
es. 3571 IN NS ns.uu.net.
es. 3571 IN NS ns1.nic.es.
es. 3571 IN NS ns1.cesca.es.
es. 3571 IN NS ns2.nic.es.
es. 3571 IN NS ns3.nic.fr.
es. 3571 IN NS sun.rediris.es.
es. 3571 IN NS ineco.nic.es.
es. 3571 IN NS sunic.sunet.se.
;; ADDITIONAL SECTION:
ineco.nic.es. 3571 IN A 194.69.254.2
;; Query time: 5 msec
;; SERVER: 192.168.56.2#53(192.168.56.2)
;; WHEN: Sun Mar 27 22:51:01 2005
;; MSG SIZE rcvd: 248
[localhost:~] fernando% dig @ns1.nic.es es. soa
; <<>> DiG 9.2.2 <<>> @ns1.nic.es es. soa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13899
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 9, ADDITIONAL: 8
;; QUESTION SECTION:
;es. IN SOA
;; ANSWER SECTION:
es. 3600 IN SOA ns1.nic.es.
hostmaster.nic.es. 2005032701 86400 7200 2592000 3600
;; AUTHORITY SECTION:
es. 3600 IN NS sunic.sunet.se.
es. 3600 IN NS munnari.oz.au.
es. 3600 IN NS ns.uu.net.
es. 3600 IN NS ns1.nic.es.
es. 3600 IN NS ns1.cesca.es.
es. 3600 IN NS ns2.nic.es.
es. 3600 IN NS ns3.nic.fr.
es. 3600 IN NS sun.rediris.es.
es. 3600 IN NS ineco.nic.es.
;; ADDITIONAL SECTION:
ns1.nic.es. 3600 IN A 194.69.254.1
ns1.cesca.es. 4142 IN A 84.88.0.3
ns2.nic.es. 3600 IN A 194.69.254.38
ns3.nic.fr. 176944 IN AAAA 2001:660:3006:1::1:1
sun.rediris.es. 551 IN A 130.206.1.2
ineco.nic.es. 3600 IN A 194.69.254.2
munnari.oz.au. 115754 IN A 128.250.22.2
munnari.oz.au. 115754 IN A 128.250.1.21
;; Query time: 69 msec
;; SERVER: 194.69.254.1#53(ns1.nic.es)
;; WHEN: Sun Mar 27 22:52:25 2005
;; MSG SIZE rcvd: 419
Doing this operation for the parent zone associated to the domain one you
are migrating, you can get the expiration and renewal times. i.e. If you
are migrating the domain example.com.es you should discover the values for
the zone com.es
For the .es domain this values are (in seconds):
Refresh 86400
Retry 7200
Expire 2592000
Minimum TTL 3600
For the .com, .net domain this values are:
Refresh 1800
Retry 900
Expire 604800
Minimum TTL 900
For the .org domain this values are:
Refresh 1800
Retry 900
Expire 604800
Minimum TTL 86400
APPENDIX B. References
[1] RFC-1918 - Address Allocation for Private Internets, February, 1996
[2] RFC-2606 - Reserved Top Level DNS Names
[3] ripe-203 - Recommendations for DNS SOA Values
[4] ripe-114 - Taking Care of Your Domain
[5] RFC-2182 - Selection and Operation of Secondary DNS Servers
[6] "DNS & BIND 4th Edition" by Paul Albitz & Cricket Liu, O'Reilly &
Associates Inc.
[7] http://www.apache.org/
[8] D. Barr, RFC 1912, Common DNS Operational and Configuration Errors, 1
February, 1996
[9] P. Vixie, RFC 1996, A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY), August, 1996
- Next message (by thread): [dns-wg] Action Item 48.1: Lame Delegations -- first draft
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]