- dns-wg - mailman.ripe.net

Re: ORSN-SERVERS.NET
by Marco Huggenberger 22 Oct '04

22 Oct '04

Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H

1 0

Re: ORSN-SERVERS.NET
by Marco Huggenberger 22 Oct '04

22 Oct '04

Hi Folks! Markus Grundman, founder of the ORSN project has asked me to post the following: "Dear list members! ORSN is not transparently enough? Sorry! But I must laughing about this posting. We do provide all needed information for interested users. You must read our homepage carefully before you can write about our project. The independent mode of ORSN was implemented to disable the automatic synchronization of the database. Regards, Markus Grundmann ORSN, Open Root Server Network Germany" A detailed view about network/server transparency is and was always available at: http://european.ch.orsn.net/servers.php If you have any questions about ORSN, please feel free to contact us directly on our mailinglist: http://european.ch.orsn.net/lists.php Cheers Marco Huggenberger Init Seven AG, Switzerland AS13030 Operator of the ORSN Root Server H

1 0

Re: [dns-wg] Re: ORSN-SERVERS.NET
by Jim Reid 14 Oct '04

14 Oct '04

>>>>> "Steffen" == Steffen Reithermann <dns-wg(a)Reithermann.de> writes: Steffen> Don't get me wrong ... I don't say ICANN's decisions are Steffen> transparent all or even most of the time. Some Steffen> independence of Europe regarding DNS and other critical Steffen> Internet infrastructure is a creditable goal, but I think Steffen> it needs a stronger basis and a broader support in the Steffen> ISP community than ORSN seems to have currently. Personal opinion: People who are unhappy with ICANN -- and who isn't? -- should be working to reform it from within. ICANN's processes are open and everyone is free to participate. [Sort of.] Supporting or encouraging efforts like alternate DNS roots undermines ICANN. That could lead to the replacement of ICANN with something even less palatable to Internet people: internet governance by international civil servants through some part of the United Nations.

1 0

ORSN-SERVERS.NET
by Yiorgos Adamopoulos 13 Oct '04

13 Oct '04

[ Sorry if this has been discussed before ] Recenlty I came across ORSN <http://www.orsn.net/>. Soonafter I discovered that one of our peers is using their rootzone (and we are forwarding queries to them). So, the question is: What do you think of this effort? o any members of the group use the ORSN-SERVERS.NET root instead of the traditional one? If so why? If not why? TIA, -Yiorgos.

10 17

Re: [dns-wg] ORSN-SERVERS.NET
by Jim Reid 13 Oct '04

13 Oct '04

>>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> writes: Jeroen> RFC's are still Request For Comments, not Standards, Some RFCs *are* standards and get labelled as such. Sadly 2826 isn't one of them. :-( Jeroen> nevertheless anyone can choose to use any infrastructure, Jeroen> rootserver, firewalling policies, routing policies and a Jeroen> whole lot of other politics that that person/organisation Jeroen> whishes to follow. For that matter if someone would setup Jeroen> his/her/it's own RIR and started giving out IPv4 or IPv6 Jeroen> addresses, who is going to stop you? That it won't Jeroen> interoperate with what most of the people on this globe Jeroen> call 'the internet' is another question, but isn't that Jeroen> their problem? Not really. Granted, they have the lion's share of the problems. But those problems won't stop at the boundary of their net. For example, a bogus TLD will leak out to people on the real internet, links on web pages can't be resolved (or point elsewhere), users get confused, mail gets bounced or treated as spam, etc, etc. Once that happens, bogus root servers and suchlike become a serious problem for the helpdesks and support people at ISPs on the real internet. If only there was a Protocol Police to deal with these impostors.

2 1

Re: [dns-wg] blackhole-*.iana.org gone ?
by James Aldridge 06 Oct '04

06 Oct '04

Dave Knight wrote: > At 19:36 01/10/2004 +0200, Dave Knight wrote: > >Hi, > > > >The RIPE NCC AS112 server, as112.ripe.net [195.69.144.39] is up and > >running again and is advertising the 192.175.48.0/24 network. > > As we are continuing to have issues with this machine and have decided > to take it offline until they are definitively fixed. We plan to replace > the hardware and bring it back online next week. Since around 13:00 UTC yesterday afternoon, as112.ripe.net has been running on new hardware (with a software upgrade at the same time for good measure). Regards, James

1 0

Reverse delegation checks: call for discussion
by Peter Koch 04 Oct '04

04 Oct '04

Dear DNS wg, from http://www.ripe.net/ripe/wg/dns/action-list.html you can see action item 48.3: Send to the mailing list (a pointer to) the current list of checks applied to IN-ADDR.ARPA zones before reverse delegation is activated or updated. Initiate review of those checks and propose, if necessary, updates and/or additional tests. Olaf sent the requested information to this list early September: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00172.html During the Action Item Review in Manchester it was decided to take this item to the list with a six week comment period. Anyone interested in changing the currently applied tests (i.e. the set of checks or a particular one) is invited to discuss this on the list or approach the WG co-chairs until November, 5th. Action Item 48.3 will be closed after that date unless tangible proposals have been made. Of course, there's always the opportunity to address this issue in the future should the need arise. Please expect the action item list to be updated after the minutes of RIPE 49 have been circulated. -Peter

1 0

blackhole-*.iana.org gone ?
by Pim van Pelt 01 Oct '04

01 Oct '04

Hi, The nameserver on blackhole-[12].iana.org does not seem to reply queries for me. $ dig @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; <<>> DiG 8.3 <<>> @blackhole-1.iana.org PTR 1.0.0.10.in-addr.arpa. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend: Connection refused I am in AS12859. Is anybody else experiencing this problem ? -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)

5 8

Re: [dns-wg] DNS migration draft - new version
by Jim Reid 22 Sep '04

22 Sep '04

Brad, many thanks for your constructive input. You've made a number of very helpful suggestions. However I feel that document editing by mailing list is not an efficient way to make progress. Please bear that in mind. Fernando's document will be presented and discussed at the WG tomorrow. [Listen to the webcast if you can't be in Manchester!] I plan to ask the WG for volunteers for a small Design Team that could work on the document. IMO this will be a better and quicker way to edit the document. And of course the final draft would get posted here for everyone to review.

3 2

DNS migration draft - new version
by Fernando Garcia 22 Sep '04

22 Sep '04

Hello all After some revieving, recomendations and bashing, I have created a new version of the document about "best operational practice on migrate a domain from one ip rage to other". A smaller and more practical oriented version. I include it here for you to read and comment. Tomorrow, Thursday I will present it in the DNS WG. Regards, Fernando DNS recommendations and procedure during IP migrations Fernando García Fernández Eurocomercial Informática y Comunicaciones Date: September 2004 1 Index of contents 1 Index 2 Abstract 3 Prerequisites 3.1 Control over the new DNS Server 3.2 Overlapping in time IP ranges 3.3 Guarantee authority with the corresponding NIC 3.4 Have a minimum knowledge of DNS service operation 3.5 Plan in advance 3.6 Duplicate DNS servers 3.7 Duplicate other services' servers 3.8 ISP coordination (and cooperation) 4 Scenario 4.1 Starting situation 4.2 Ending situation 4.3 Limitations 5 Migration procedure 5.1 New DNS server 5.1.1 Duplicate the information for the domain 5.1.2 Change the new DNS Server's IP address 5.1.3 Reduce SOA times 5.2 Check the new server is operating correctly 5.3 Create the reverse resolution of the new address 5.4 Delegate the reverse resolution of the new address 5.5 Change glue records in the parent DNS server (Contact NIC) 5.6 Change records listing secondary servers 5.7 Verify information in secondary servers 5.8 Wait until changes are propagated 5.9 Change servers IP addresses 5.9.1 Modify "IN A" resource records 5.10 Modify SOA Values 5.11 Wait until changes get propagated 5.12 Shutdown old servers hosted by the previous ISP APPENDIX A. Traumatically change of provider APPENDIX B. SOA Values APPENDIX C. ES-NIC form example APPENDIX D. Bibliography 2 Abstract One of the most complex and problematic situations that 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 that 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. 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. 3 Prerequisites A number of requisites are considered vital to avoid blackout: 3.1 Control over the new DNS server 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. 3.2 Overlapping in time IP ranges This procedure requires both ranges of IP addresses to be active simultaneously during the migration. 3.3 Guarantee authority with the corresponding 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. 3.4 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. 3.5 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 wide enough if we follow the standard values recommended by RIPE and/or the local NIC for the SOA fields. 3.6 Duplicate 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 on the other services. Also, to ensure the stability of the services, these DNS servers must be duplicated during some time, so you need duplicate machines. 3.7 Duplicate other services' servers 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 shutdown of the services. 3.8 ISP coordination (and cooperation) 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 it's the only way to go, we recommend looking for the help of both DNS administrators. 4 Scenario All the examples of in this document use the IP address ranges defined in the RFC 1918 [1]. Of course you must change this address for the ones assigned to you by the RIR/LIR in charge. REMEMBER: The address used in this documents are NOT valid address and you should change them with your own address, don¹t simply copy and paste this examples and check twice the information is correct. The domains and subdomains used in these examples are fictitious and use the standard "example.com"[2]. You also should change it with your assigned domain name. For the examples in this document we 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 software. 4.1 Starting situation Company X has the domain "example.com". This company X has Internet connectivity through the Internet carrier A, which has assigned to the company X 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 glue records of the delegating zone: * Primary server of the domain "example.com": 192.168.10.2 * Secondary server of the domain "example.com": 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.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 zone configuration files should be as follows: $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 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.example.com. hostmaster.example.com. ( ; 2001070401 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 3600000 ; expire 172800 ) ; minimum TTL ; name servers NS primary.example.com. NS secondary.example.com. ; host lists 2 PTR primary.example.com. 10 PTR www.example.com. 15 PTR mail.example.com. 240 PTR secondary.example.com. 4.2 Ending situation After the migration, company X will be connected through carrier B and both companies have agreed carrier B to assign 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 "example.com": 10.40.5.2 * Secondary server for the domain "example.com": 10.40.5.240 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 inverse resolution for the new IP range will be delegated and configured correctly. The archive for the zone must finish in 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 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.example.com. hostmaster.example.com. ( ; 2001072001 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 2592000 ; expire 172800 ) ; minimum TTL ; name servers NS primary.example.com. NS secondary.example.com. ; hosts list 2 PTR primary.example.com. 10 PTR www.example.com. 15 PTR mail.example.com. 240 PTR secondary.example.com. 4.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. 5 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. 5.1 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. This step is described next in more detail 5.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. 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; }; The most important to preserve is the current addresses for the Internet servers, so for instance our web server www.example.com. Keeps on having a ³IN A² record with its original IP address: $ORIGIN <...> www IN A 192.168.10.10 5.1.2 Change the new DNS server's IP address It¹s 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 and the new ones will be in the new ISP IP space. So far no changes happen in the parent servers hosted by the corresponding NIC or registrar. This will happen after some more steps. 5.1.3 Reduce SOA times Once the described changes are done in the zone, 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 note these values to restore this configuration after the migration process is completed. In case it has been possible to duplicate nameservers, the values recommended are: Serial: increasing the version digit in 1 unit (i.e. +1) Refresh: 14400 secs. Retry: (=) 7200 secs. Expiration: (=) 3600000 TTL: 14400 Field marked with (=) doesn't need to be modified and can preserve their original values. example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 2004091301 ; serial YYYYMMDDnn 14400 ; refresh (4 hours) 7200 ; retry (2 hours) 3600000 ; expire (1000 hours) 14400 ) ; minimum TTL (4 hours) Refresh: reducing the refresh time makes the secondary servers to transfer the zone file more frequently so the chance these servers have incorrect/outdated information is lower. This is considered a safe value, could be even higher. The time the clients querying the nameserver will cache the information obtained will be lowered to 4 hours. In case it was not possible to duplicate the new servers in the new ISP, these values have to be modified in the zone file stored at the namservers in the previous ISP instead. These would be the values recommended, they will be lower in order to reduce the time clients will cache the replies and therefore the blackout time is reduced to the minimum: Serial: increasing the version digit in 1 unit (i.e. +1) Refresh: 300 Retry: 150 (or lower) Expiration: (=) 2592000 TTL: 300 Refresh: as in the case where duplication of nameservers was possible, reducing this time to a lower value, makes the secondary servers to transfer and update the zone file more often so the chance of a blackout is reduced to that time (i.e. five minutes). Query rate will go higher in the servers as the information cached will last only for 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 do perform all these changes during the night. 5.2 Check the new server is operating correctly 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 secondary about it. Finally, querying the server by using ³dig² or ³nslookup² tools is recommendable: $ nslookup - 10.40.5.2 > www.example.com. 192.168.10.10 5.3 Create the reverse resolution of the new address 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 that for the old addresses after the migration. There are also no glue problems so this step can be made even before installing any machine in the new range. You need to create a new domain configuration file for the reverse as described in 4.2 and add it to your DNS server configuration file. 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. 5.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 servers (10.40.5.2 and 10.40.5.240) 5.5 Change glue records in the parent DNS server (contact NIC) 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 secondary 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. NICs have normally a mechanism to notify the changes have been done to the contact for the domain but it is recommended to verify this by doing as follows. 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 5.6 Change records listing secondary servers 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. In case the secondary servers for the zone are running BIND 8.x or 9.x, the syntax to use in the /etc/named.conf file would be: Zone "example.com" in { Type slave; File "db.example"; Masters { 10.40.5.2; }; }; Being 10.40.5.2 the IP for the new primary nameserver of the domain. 5.7 Verify information in secondary servers To verify the changes are made correctly in the secondary servers, use nslookup, dig or any other dns client tool. Using nslookup: $ nslookup - dns.example.net > set type=ns > example.com. example.com nameserver = primary.example.com example.com nameserver = secondary.example.com example.com nameserver = dns.example.net primary.example.com internet address = 10.40.5.2 secondary.example.com internet address = 10.40.5.240 dns.example.net internet address = 192.168.13.13 In this answer 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. 5.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. 5.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 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 a 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. 5.9.1 Modify "IN A" fields Once the servers are installed in the new IP range it is necessary to modify the ³IN A² and the ³IN PTR² 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 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 5.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 5.7. SOA times have to remain lower until all changes are done and the new information is propagated. Afterwards, the recommended values (e.g. RIPE recommended values) can be restored. 5.11 Wait until changes get propagated 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. 5.12 Shutdown old servers hosted by the previous ISP Once the changes are done, and information is propagated across the internet, all queries will be addressed to the new IP space, therefore to the new internet servers. So the old servers including the old primary nameserver can be safely shutdown. Appendix A 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 shutdown 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. A.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. A.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. APPENDIX 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.example.com Address: 192.168.10.2 > set type=ns > es. Server: dns.example.com 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 APPENDIX 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(a)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 "example.com" 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)..:example.com SECCION 1 - Dominio Objeto de Registro 1. Nombre Dominio...............:example.com 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.example.com 7b. Direccion IP S. Primario.....:10.40.5.2 8a. Nombre Servidor Secundario...:secundario.example.com 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). APPENDIX D. Bibliography [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] "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(a)eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- --

2 1