From billy.glynn at domainregistry.ie Mon Sep 6 19:05:11 2004 From: billy.glynn at domainregistry.ie (Billy Glynn) Date: Mon, 06 Sep 2004 18:05:11 +0100 Subject: [dns-wg] IPv6 in .ie Message-ID: <413C98C7.2030501@domainregistry.ie> Hi, FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new IPv6 compatible name server ns6.iedr.ie. Additionally, we have added AAAA glue for one of our slaves ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Kind regards -- ________________________________ Billy Glynn Network Operations Centre IE Domain Registry Ltd Tel: +353 (0)1 2365404 Mobile: +353 (0)87 9188317 billy.glynn at domainregistry.ie ________________________________ From jeroen at unfix.org Tue Sep 7 08:39:08 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 07 Sep 2004 08:39:08 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <413C98C7.2030501@domainregistry.ie> References: <413C98C7.2030501@domainregistry.ie> Message-ID: <1094539148.2721.124.camel@segesta.zurich.ibm.com> On Mon, 2004-09-06 at 19:05, Billy Glynn wrote: > Hi, > > FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new > IPv6 compatible name server ns6.iedr.ie. > Additionally, we have added AAAA glue for one of our slaves > ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp Neat, 2 IPv6 nameservers in the root for .ie. I also see that you have ns2.nic.fr listed in there, ns3.nic.fr has IPv6 for sure. You should maybe ask RIPE NCC if they can stick glue for ns.ripe.net into the . also with an IPv6 address, which would also give quite a number of other TLD's etc an IPv6 capable nameserver all of a sudden. RIPE NCC folks ? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From ask at ag-trek.de Tue Sep 7 08:49:29 2004 From: ask at ag-trek.de (Andreas S. Kerber) Date: Tue, 7 Sep 2004 08:49:29 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <1094539148.2721.124.camel@segesta.zurich.ibm.com> References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> Message-ID: <20040907064929.GA24832@osiris.speedkom.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Sep 07, 2004 at 08:39:08AM +0200, Jeroen Massar wrote: > I also see that you have ns2.nic.fr listed in there, ns3.nic.fr has IPv6 > for sure. > You should maybe ask RIPE NCC if they can stick glue for ns.ripe.net > into the . also with an IPv6 address, which would also give quite a > number of other TLD's etc an IPv6 capable nameserver all of a sudden. uuh, I guess that would get pretty close to 512 bytes when querying ie. # dig -t NS ie. @a.root-servers.net | grep MSG ;; MSG SIZE rcvd: 493 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBPVn5P0gnkXA27R8RAtu1AJ9doEPoSpXoJdKksX748X9/6bdwcwCfWKcY +ZLAVn6HthZDoqu0WN3qJa8= =TfJ6 -----END PGP SIGNATURE----- From Mohsen.Souissi at nic.fr Tue Sep 7 09:06:59 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Tue, 7 Sep 2004 09:06:59 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <1094539148.2721.124.camel@segesta.zurich.ibm.com> References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> Message-ID: <20040907070659.GY7139@kerkenna.nic.fr> Hi, On 07 Sep, Jeroen Massar wrote: | On Mon, 2004-09-06 at 19:05, Billy Glynn wrote: | > Hi, | > | > FYI, the IEDR in it's capacity as ccTLD manager of .ie have added a new | > IPv6 compatible name server ns6.iedr.ie. | > Additionally, we have added AAAA glue for one of our slaves | > ns3.ns.esat.net. ns3.ns.esat.net also slaves for the folks at .tp | | Neat, 2 IPv6 nameservers in the root for .ie. | | I also see that you have ns2.nic.fr listed in there, ns3.nic.fr has IPv6 | for sure. ==> ns2.nic.fr has been supporting IPv6 for several months. We published it's IPv6 address a couple of weeks ago and we intend to ask for sticking its AAAA in . soon. By the way, we will use 'b.nic.fr' instead of 'ns2.nic.fr' as we used 'c.nic.fr' instead of 'ns3.nic.fr' for fr AAAA glue under . Mohsen. | | You should maybe ask RIPE NCC if they can stick glue for ns.ripe.net | into the . also with an IPv6 address, which would also give quite a | number of other TLD's etc an IPv6 capable nameserver all of a sudden. | | RIPE NCC folks ? :) | | Greets, | Jeroen From daniel.karrenberg at ripe.net Tue Sep 7 11:40:41 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 7 Sep 2004 11:40:41 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <20040907064929.GA24832@osiris.speedkom.net> References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> <20040907064929.GA24832@osiris.speedkom.net> Message-ID: <20040907094041.GA3639@reifa.local> On 07.09 08:49, Andreas S. Kerber wrote: > > uuh, I guess that would get pretty close to 512 bytes when querying ie. So what? See below for examples of what could happen: soem glue is omitted. If the client supports IPv6 it almost certainly supports EDNS(0), so the 512 byte limit is no issue. If the lient does not support EDNS some glue may be dropped for very long names without problems. See http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf for a little more detail. (It can be argued that dropping AAAA glue first is a good tactic here because "see above". This will be implemented on all root name servers in the near future.) Daniel ----- ; <<>> DiG 8.2 <<>> @k.root-servers.net. short.ie. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 12 ;; QUERY SECTION: ;; short.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ice.netsource.ie. 2D IN A 212.17.32.2 ns6.iedr.ie. 2D IN A 213.190.149.221 ns6.iedr.ie. 2D IN AAAA 2001:bb0:ccc3::2 ;; Total query time: 71 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:29:37 2004 ;; MSG SIZE sent: 26 rcvd: 499 ; <<>> DiG 8.2 <<>> @k.root-servers.net. something.verylogindeed.fordemopurposes.ie ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 11 ;; QUERY SECTION: ;; something.verylogindeed.fordemopurposes.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ice.netsource.ie. 2D IN A 212.17.32.2 ns6.iedr.ie. 2D IN A 213.190.149.221 ;; Total query time: 69 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:29:43 2004 ;; MSG SIZE sent: 60 rcvd: 505 ; <<>> DiG 8.2 <<>> @k.root-servers.net. something.verylogindeed.fordemopurposes.evenlonger.toforceommittingmoreglue.ie ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 9 ;; QUERY SECTION: ;; something.verylogindeed.fordemopurposes.evenlonger.toforceommittingmoreglue.ie, type = A, class = IN ;; AUTHORITY SECTION: ie. 2D IN NS ns2.nic.fr. ie. 2D IN NS ns.ripe.net. ie. 2D IN NS banba.domainregistry.ie. ie. 2D IN NS uucp-gw-1.pa.dec.com. ie. 2D IN NS uucp-gw-2.pa.dec.com. ie. 2D IN NS ns3.ns.esat.net. ie. 2D IN NS gns1.domainregistry.ie. ie. 2D IN NS gns2.domainregistry.ie. ie. 2D IN NS ice.netsource.ie. ie. 2D IN NS ns6.iedr.ie. ;; ADDITIONAL SECTION: ns2.nic.fr. 2D IN A 192.93.0.4 ns.ripe.net. 2D IN A 193.0.0.193 banba.domainregistry.ie. 2D IN A 193.1.142.2 uucp-gw-1.pa.dec.com. 2D IN A 204.123.2.18 uucp-gw-2.pa.dec.com. 2D IN A 204.123.2.19 ns3.ns.esat.net. 2D IN A 192.111.39.100 ns3.ns.esat.net. 2D IN AAAA 2001:7c8:2:a::64 gns1.domainregistry.ie. 2D IN A 198.133.199.102 gns2.domainregistry.ie. 2D IN A 198.133.199.103 ;; Total query time: 67 msec ;; FROM: dienst.karrenberg.net to SERVER: k.root-servers.net. 193.0.14.129 ;; WHEN: Tue Sep 7 11:33:53 2004 ;; MSG SIZE sent: 96 rcvd: 509 From daniel.karrenberg at ripe.net Tue Sep 7 11:56:17 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 7 Sep 2004 11:56:17 +0200 Subject: [ipv6-wg@ripe.net] Re: [dns-wg] IPv6 in .ie In-Reply-To: References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> <20040907064929.GA24832@osiris.speedkom.net> <20040907094041.GA3639@reifa.local> Message-ID: <20040907095617.GC3639@reifa.local> On 07.09 11:46, Iljitsch van Beijnum wrote: > > So then nothing stands in the way of adding AAAA glue records to the > root? Nothing other than the fact that the root is considered special by many and our collective processes are careful with changes to it. Some of this actually has rechnical rationale. I'll just name two examples: 1) The root servers are already the most loaded servers for any zone. 2) There are concerns that buggy resolvers may behave badly and aggrevate 1) above. So some more testing will have to be done and then the collective processes will have to run their course..... . Daniel From andrei at ripe.net Wed Sep 8 09:57:52 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 08 Sep 2004 09:57:52 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <20040907064929.GA24832@osiris.speedkom.net> References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> <20040907064929.GA24832@osiris.speedkom.net> Message-ID: <413EBB80.10900@ripe.net> Andreas S. Kerber wrote: > On Tue, Sep 07, 2004 at 08:39:08AM +0200, Jeroen Massar wrote: > >>I also see that you have ns2.nic.fr listed in there, ns3.nic.fr has IPv6 >>for sure. >>You should maybe ask RIPE NCC if they can stick glue for ns.ripe.net >>into the . also with an IPv6 address, which would also give quite a >>number of other TLD's etc an IPv6 capable nameserver all of a sudden. > > > uuh, I guess that would get pretty close to 512 bytes when querying ie. > > # dig -t NS ie. @a.root-servers.net | grep MSG > ;; MSG SIZE rcvd: 493 I think adding another AAAA record will actually exceed this limit. Daniel wrote: > So what? See below for examples of what could happen: > soem glue is omitted. > But also the IANA procedure will not permit it: "5. If the number of name servers or IP addresses in the delegation exceeds eight (8), the size of responses to reasonable queries with the intended delegation will be checked to ensure that such responses fit into a 512 byte UDP packet. This is the standard size limitation for UDP response packets for most resolving name server software on the Internet today." Coming back to the issue with ns.ripe.net. The fact that it is a secondary for about 90 ccTLDs makes it impossible to insert AAAA record in the root for any of the zone, because that will affect others. Currently, we are planning to introduce a scheme whereby each ccTLD has its own name in the ripe.net domain, eg: ns-ie.ripe.net A 193.0.12.107 AAAA 2001:610:240:0:53:cc:12:107 All of the addresses for ccTLDs (ns-XX.ripe.net) are simply IP aliases on a shared machine. Regards, Andrei Robachevsky RIPE NCC From daniel.karrenberg at ripe.net Wed Sep 8 10:19:43 2004 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 8 Sep 2004 10:19:43 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <413EBB80.10900@ripe.net> References: <413C98C7.2030501@domainregistry.ie> <1094539148.2721.124.camel@segesta.zurich.ibm.com> <20040907064929.GA24832@osiris.speedkom.net> <413EBB80.10900@ripe.net> Message-ID: <20040908081943.GA490@reifa.karrenberg.net> On 08.09 09:57, Andrei Robachevsky wrote: > But also the IANA procedure will not permit it: > > "5. If the number of name servers or IP addresses in the delegation > exceeds eight (8), the size of responses to reasonable queries with the > intended delegation will be checked to ensure that such responses fit > into a 512 byte UDP packet. This is the standard size limitation for UDP > response packets for most resolving name server software on the Internet > today." That is correct. It depends what a reasonable query is. If I was IANA I would advise .ie strongly to rationalise the names in their glue to save space. However, my point is that exceeding this limit will not cause the sky to fall down. Daniel From jim at rfc1035.com Wed Sep 8 10:54:02 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 08 Sep 2004 09:54:02 +0100 Subject: [dns-wg] IPv6 in .ie In-Reply-To: Message from Daniel Karrenberg of "Wed, 08 Sep 2004 10:19:43 +0200." <20040908081943.GA490@reifa.karrenberg.net> Message-ID: <1136.1094633642@gromit.rfc1035.com> >>>>> "Daniel" == Daniel Karrenberg writes: Daniel> If I was IANA I would advise .ie strongly to rationalise Daniel> the names in their glue to save space. Yeah. Somebody needs to write up a draft on this as a BCP: using efficient label compression to avoid truncated responses. From Mohsen.Souissi at nic.fr Wed Sep 8 10:58:28 2004 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Wed, 8 Sep 2004 10:58:28 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <1136.1094633642@gromit.rfc1035.com> References: <20040908081943.GA490@reifa.karrenberg.net> <1136.1094633642@gromit.rfc1035.com> Message-ID: <20040908085828.GA68625@kerkenna.nic.fr> On 08 Sep, Jim Reid wrote: | >>>>> "Daniel" == Daniel Karrenberg writes: | | Daniel> If I was IANA I would advise .ie strongly to rationalise | Daniel> the names in their glue to save space. | | Yeah. Somebody needs to write up a draft on this as a BCP: using | efficient label compression to avoid truncated responses. ==> In order not to reinvent the wheel, I believe, this humble contribution might be a good start for whom wants to write such a draft. http://w6.nic.fr/dnsv6/resp-size.html#compress-tld-ans Mohsen. From dwmalone at maths.tcd.ie Wed Sep 8 13:05:54 2004 From: dwmalone at maths.tcd.ie (David Malone) Date: Wed, 08 Sep 2004 12:05:54 +0100 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: Your message of "Wed, 07 Jul 2004 14:20:15 BST." <200407071420.aa39091@salmon.maths.tcd.ie> Message-ID: <200409081205.aa10977@salmon.maths.tcd.ie> As the next RIPE meeting is rolling up, I just thought I'd raise the AAAA lookup misbehaviour thread again. To briefly remind you of where we'd got to: 1) I'd written up a short describing the problem with authoritative servers and recommending that new name servers should be tested before deployment. 2) Alvaro and Colm had highlighted some problems with client resolver libraries, but it wasn't clear if a description of these problems should live in the same document. 3) We were trying to figure out what action could be taken to encourage people to fix existing problem name servers. So, other than the hall of shame, what options do we have to encourage people to fix their software? Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action. Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone. Any other ideas? David. From jeroen at unfix.org Wed Sep 8 13:59:32 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 08 Sep 2004 13:59:32 +0200 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: <200409081205.aa10977@salmon.maths.tcd.ie> References: <200409081205.aa10977@salmon.maths.tcd.ie> Message-ID: <1094644772.8934.1.camel@segesta.zurich.ibm.com> On Wed, 2004-09-08 at 13:05, David Malone wrote: > As the next RIPE meeting is rolling up, I just thought I'd raise > the AAAA lookup misbehaviour thread again. To briefly remind you > of where we'd got to: > > 1) I'd written up a short describing the problem > with authoritative servers and recommending that > new name servers should be tested before deployment. > 2) Alvaro and Colm had highlighted some problems with > client resolver libraries, but it wasn't clear if > a description of these problems should live in the > same document. > 3) We were trying to figure out what action could be > taken to encourage people to fix existing problem > name servers. > > So, other than the hall of shame, what options do we have to > encourage people to fix their software? Working with vendors > of DNS solutions is certainly a good idea, and the dns-wg's > name could be useful when convincing vendors to take action. > > Another possibility would be to recommend that when problem > DNS servers are found, then they should be considered lame > and so dropped from the advertised list of NSs for a zone. > > Any other ideas? Notez bien that some software is also doing A6 lookups, even bind9 does this upto 9.3.x afaik. Add a small item about ip6.int and ip6.arpa and maybe even discussing (again as the previous time nicely got killed) about the quick removal of ip6.int in total. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From bmanning at vacation.karoshi.com Wed Sep 8 18:08:33 2004 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 8 Sep 2004 16:08:33 +0000 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <1136.1094633642@gromit.rfc1035.com> References: <20040908081943.GA490@reifa.karrenberg.net> <1136.1094633642@gromit.rfc1035.com> Message-ID: <20040908160833.GB16434@vacation.karoshi.com.> On Wed, Sep 08, 2004 at 09:54:02AM +0100, Jim Reid wrote: > >>>>> "Daniel" == Daniel Karrenberg writes: > > Daniel> If I was IANA I would advise .ie strongly to rationalise > Daniel> the names in their glue to save space. > > Yeah. Somebody needs to write up a draft on this as a BCP: using > efficient label compression to avoid truncated responses. you mean the resp-size draft that is already out there is not good enough? --bill From jim at rfc1035.com Wed Sep 8 18:38:20 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 08 Sep 2004 17:38:20 +0100 Subject: [dns-wg] IPv6 in .ie In-Reply-To: Message from bmanning@vacation.karoshi.com of "Wed, 08 Sep 2004 16:08:33 -0000." <20040908160833.GB16434@vacation.karoshi.com.> Message-ID: <2284.1094661500@gromit.rfc1035.com> >>>>> "Bill" == bmanning writes: Daniel> the names in their glue to save space. >> Yeah. Somebody needs to write up a draft on this as a BCP: >> using efficient label compression to avoid truncated responses. Bill> you mean the resp-size draft that is already out there Bill> is not good enough? I thought that had died..... From fgarcia at eurocomercial.es Thu Sep 9 10:25:52 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Thu, 9 Sep 2004 10:25:52 +0200 Subject: [dns-wg] Document to discuss for RIPE 49 Message-ID: Hello all After some years, I restarted an old proposal I made in a RIPE meeting and finally I'm finishing it. Is a document with the title "Planning the migration of a group of servers and associated DNS from an IP range to other" and I have asked for a timeslot in the DNS working group in RIPE 49 to discuss it. The idea is to have it as a operational best practices document to help network administrators to migrate a network without DNS problems (blackouts, lost of control, etc.) I expect to have a draft finished along the weekend and will post it (or a link to it, is a big document, about 90 K size) to the list. In the meantime, here is the table of contents so you can post questions, ideas and flames to the list or to me: 1 Index 2 Abstract 3 Unordered migration 3.1 Resolving without data in the cache 3.2 Resolving with out of date NIC information 3.3 Request with the DNS server in the cache 3.4 Request with the solicited server in the cache 3.4.1 Request to the secondary server 4 Causes 4.1 Change the domain from one ISP to other 4.2 Change the IP addressing of the ISP 5 Priority definition 5.1 Avoid the blackout of the domain 5.2 Avoid the pollution of DNS cache with incorrect information 6 Requirements 6.1 Control over the new DNS server 6.2 Authorized contact in the NIC 6.3 Minimal DNS knowledge 6.4 Plan in advance, two weeks minimum 6.5 Independent and duplicated DNS servers 6.6 If possible, duplicate the other servers 6.7 Coordination between ISP 7 Scenario 7.1 Starting situation 7.2 Ending situation 7.3 Limitations 8 Mechanism 8.1 Change of DNS servers 8.2 Change of other servers 8.3 Insert standard values in the SOA 8.4 Development 9 Detailed procedure 9.1 Create a new DNS server in the new DNS address range 9.1.1 Duplicate the existing information of this domain 9.1.2 Modify the server own address 9.1.3 Reduce the SOA times 9.2Check the new server 9.3 Modify the primary server information in the NIC 9.4 Modify the external secondaries 9.5 Verify the secondaries 9.6 Wait for the changes to propagate 9.7 Modify the address of the other servers 9.7.1 Time and space impact 9.7.2 Duplicate the servers 9.7.3 Move the servers 9.7.4 Duplicate IP addresses 9.7.5 Service implication 9.7.6 Modify ?IN A? and ?IN PTR? fields 9.8 Wait the propagation 9.9 Deactivate services in the old address range 10 Resumed procedure 11 Special situations 11.1 Traumatical change of provider 11.1.1 Help from a third party 11.1.2 Steps Appendix A.Glosary Appendix B.SOA values Appendix C.ES-NIC form example Appendix D.References Regards, Fernando -- ------------------------------------------------------------------------ ------ Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ------------------------------------------------------------------------ ------ From Joao_Damas at isc.org Thu Sep 9 11:12:41 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 9 Sep 2004 11:12:41 +0200 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: <200409081205.aa10977@salmon.maths.tcd.ie> References: <200409081205.aa10977@salmon.maths.tcd.ie> Message-ID: <675F8B8F-0240-11D9-B3FE-000D93B1DDA6@isc.org> On 8 Sep, 2004, at 13:05, David Malone wrote: > As the next RIPE meeting is rolling up, I just thought I'd raise > the AAAA lookup misbehaviour thread again. To briefly remind you > of where we'd got to: > > 1) I'd written up a short describing the problem > with authoritative servers and recommending that > new name servers should be tested before deployment. > 2) Alvaro and Colm had highlighted some problems with > client resolver libraries, but it wasn't clear if > a description of these problems should live in the > same document. > 3) We were trying to figure out what action could be > taken to encourage people to fix existing problem > name servers. > > So, other than the hall of shame, what options do we have to > encourage people to fix their software? Writing a RIPE document. People use them as reference material when they are well written, both within and outside the RIPE region > Working with vendors > of DNS solutions is certainly a good idea, and the dns-wg's > name could be useful when convincing vendors to take action. > Sure, buy me a beer. I am easy to convince :-) Now seriously, we try to do the right thing, we may have bugs some times. For instance there was some time ago a bug that went like this: 1679. [bug] When there was a single nameserver with multiple addresses for a zone not all addresses were tried. [RT #11706] e.g. If the server had one AAAA and one A, then A would not be tried. They will mark all addresses bad if they get a bad response from one of the addresses (bad response != no response). Although you could argue this goes in your favour as IPv6 promoter. > Another possibility would be to recommend that when problem > DNS servers are found, then they should be considered lame > and so dropped from the advertised list of NSs for a zone. > Well, that would depend on the nature of the misbehaviour. I am looking forward to your DNS-wg contribution. Joao From Joao_Damas at isc.org Thu Sep 9 11:13:18 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Thu, 9 Sep 2004 11:13:18 +0200 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: <1094644772.8934.1.camel@segesta.zurich.ibm.com> References: <200409081205.aa10977@salmon.maths.tcd.ie> <1094644772.8934.1.camel@segesta.zurich.ibm.com> Message-ID: <7D1E0C24-0240-11D9-B3FE-000D93B1DDA6@isc.org> On 8 Sep, 2004, at 13:59, Jeroen Massar wrote: > On Wed, 2004-09-08 at 13:05, David Malone wrote: >> As the next RIPE meeting is rolling up, I just thought I'd raise >> the AAAA lookup misbehaviour thread again. To briefly remind you >> of where we'd got to: >> >> 1) I'd written up a short describing the problem >> with authoritative servers and recommending that >> new name servers should be tested before deployment. >> 2) Alvaro and Colm had highlighted some problems with >> client resolver libraries, but it wasn't clear if >> a description of these problems should live in the >> same document. >> 3) We were trying to figure out what action could be >> taken to encourage people to fix existing problem >> name servers. >> >> So, other than the hall of shame, what options do we have to >> encourage people to fix their software? Working with vendors >> of DNS solutions is certainly a good idea, and the dns-wg's >> name could be useful when convincing vendors to take action. >> >> Another possibility would be to recommend that when problem >> DNS servers are found, then they should be considered lame >> and so dropped from the advertised list of NSs for a zone. >> >> Any other ideas? > > Notez bien that some software is also doing A6 lookups, even bind9 does > this upto 9.3.x afaik. > 9.3.x has no code left to deal with A6 records. Joao From brad at stop.mail-abuse.org Wed Sep 8 11:21:10 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 8 Sep 2004 11:21:10 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <1136.1094633642@gromit.rfc1035.com> References: <1136.1094633642@gromit.rfc1035.com> Message-ID: At 9:54 AM +0100 2004-09-08, Jim Reid wrote: > Yeah. Somebody needs to write up a draft on this as a BCP: using > efficient label compression to avoid truncated responses. That's a good idea. Should this be a RIPE BCP, or under IETF? I'll be glad to contribute some of my own personal experiences, if anyone wants to write such a beast. I'd be very interested to see how much supporting evidence could be gathered to explain why this is an important topic. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jaap at NLnetLabs.nl Wed Sep 8 14:38:51 2004 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 08 Sep 2004 14:38:51 +0200 Subject: [dns-wg] AAAA lookup misbehaviour In-Reply-To: Your message of Wed, 08 Sep 2004 12:05:54 +0100. <200409081205.aa10977@salmon.maths.tcd.ie> Message-ID: <200409081238.i88Ccpwx029102@open.nlnetlabs.nl> So, other than the hall of shame, what options do we have to encourage people to fix their software? Call the Internet Police :-). Effectively, there are not a lot of options other than make the problem know, Working with vendors of DNS solutions is certainly a good idea, and the dns-wg's name could be useful when convincing vendors to take action. Publishing a Ripe document identifying the problem and the solutions there to might help to convince the RIPE members to take action; have this in the RIPE course material where appropriate (LIR course ?); bring it under attention of the IPv6 working group and other IPv6 groups. Another possibility would be to recommend that when problem DNS servers are found, then they should be considered lame and so dropped from the advertised list of NSs for a zone. Recommend to who? To the parent is I guess your answer. We are dabbling into policy space here if you don't watch it (expecially when the parent is "." :-). Any other ideas? Call the local papers :-). No, honestly, publisch it. You might ask Ole whether he thinks it is useful for the Protocol Journal. jaap From olaf at ripe.net Thu Sep 9 14:37:09 2004 From: olaf at ripe.net (Olaf M. Kolkman) Date: Thu, 9 Sep 2004 14:37:09 +0200 Subject: [dns-wg] RIPE 48 Action Item. Message-ID: <20040909143709.6a924a07.olaf@ripe.net> Dear Colleagues, This is a small report on an action item that is upon us. Action 48.X [Olaf Kolkman] Send to the mailinglist [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. The reverse delegation "HOWTO" [1] refers to a web page[2] that can perform the delegation checks that our database update engine performs. That web-based delegation checker comes with an explanation of the most important checks[3]. We think that for the purpose of further discussion of the delegation checks the explanation in [3] is sufficient. However because of a library version mismatch the documentation in [3] may sometimes differ from what is actually verified during WHOIS Database updates. We will be working on updating the web based delegation checker to use the same back-end library and during that process update and audit the documentation. If you have any question regarding details we'll be happy to answer them. Kind regards, Olaf M. Kolkman New Projects, RIPE NCC [1] http://www.ripe.net/reverse/reverse_howto.html The explanation on how to request a reverse delegation [2] http://www.ripe.net/cgi-bin/nph-dc.cgi The web-based zone delegation checker [3] http://www.ripe.net/misc/dc-ext-descr.html From olaf at ripe.net Thu Sep 9 15:15:04 2004 From: olaf at ripe.net (Olaf M. Kolkman) Date: Thu, 9 Sep 2004 15:15:04 +0200 Subject: [dns-wg] IPv6 in .ie In-Reply-To: <2284.1094661500@gromit.rfc1035.com> References: <20040908160833.GB16434@vacation.karoshi.com.> <2284.1094661500@gromit.rfc1035.com> Message-ID: <20040909151504.2e7b67db.olaf@ripe.net> On Wed, 08 Sep 2004 17:38:20 +0100 Jim Reid wrote: > >>>>> "Bill" == bmanning writes: > > Daniel> the names in their glue to save space. > >> Yeah. Somebody needs to write up a draft on this as a BCP: > >> using efficient label compression to avoid truncated responses. > > Bill> you mean the resp-size draft that is already out there > Bill> is not good enough? > I thought that had died..... For your information and reference: resp-size is at: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-01.txt A common parent name is recommended in the resp-size draft: 4.1. The current practice of giving all nameserver names a common parent (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS responses and allows for more nameservers to be enumerated than would otherwise be possible. (Note that in this case it is wise to serve the common parent domain's zone from the same servers that are named within it, in order to limit external dependencies when all your eggs are in a single basket.) The document is not dead, it came up in the DNSOP meeting at IETF60 in San Diego. http://darkwing.uoregon.edu/~llynch/dnsop/msg03041.html Rob Austein: Paul, want to say anything about respsize doc? Paul Vixie: I know that one person actually read this and found clownish commentary I put in draft. Nobody flamed me. There is a very controversial comment in this draft. Peter Koch: Have one question or remark. We had funny discussion about what is allowed length for domain name. 255, 256, 253. It'. a bit late now to discuss this because this is very basic DNS stuff. Nothing to do with your draft, but obviously some basic questions yet unresolved. Anything we can do in this or another WG to resolve this? (Peters question sidetracked the discussion somewhat ... I skip that here... ) Paul Vixie: In terms of process, I do not think this draft is ready to progress, because no-one complained. So until I have some feeling that someone other than me has seen this text, I will say it's not ready to go forward. Rob Austein: So given that we had a number of people claiming this was important work, suggests that there is some work to be done in terms of reading doc that hasn't happened yet. You're all slackers. Go read the document! -- ---------------------------------| Olaf M. Kolkman ---------------------------------| RIPE NCC From fgarcia at eurocomercial.es Mon Sep 13 11:01:59 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Mon, 13 Sep 2004 11:01:59 +0200 Subject: [dns-wg] DNS migration draft Message-ID: Hello all As promised, here is the draft of the DNS migration recomendation document that I will present in RIPE 49. Remember, is a first draft, with errors, spaces to fill, etc. I welcome any commentaries about it. ---------------------------------------------------------------------------- Planning the migration of a server's network and associated DNS from an IP range to other Fernando Garc?a Fern?ndez Eurocomercial Informatca y Comunicaciones Date: September, 2004 1 Index 1 Index 2 Abstract 3 Unordered migration 3.1 Resolving whithout data in thecache 3.2 Resolbing wiht out of date NIC information 3.3 Request with the DNS server in the cache 3.4 Request with the solicited server in the cache 3.5 Request to the secondary server 4 Situations wich involve IP migration 4.1 Moving a domain name from a given ISP to other 4.2 The upstream ISP changes IP addresses 5 Prerequisites 5.1 Control over the new DNS Servers 5.2 Authorized contact in the NIC 5.3 Minimal DNS knowledge 5.4 Plan in advance 5.5 Independent and duplicated DNS servers 5.6 If possible, duplicate the other servers 5.7 Coordination between ISP 6 Scenario 6.1 Starting situacion 6.2 Ending situation 6.3 Limitations 7 Migration procedure 7.1 Create a new DNS server 7.1.1 Duplicate the existing information of this domain 7.1.2 Modify the server own address 7.1.3 Reduce the SOA times 7.2 Check the new server 7.3 Create the reverse resolution of the new address 7.4 Delegate the reverse resolution of the new address range 7.5 Change glue records in the parent DNS server 7.6 Modify the external secondaries 7.7 Verify the secondaries 7.8 Wait until changes are propagated 7.9 Change servers IP addresses 7.9.1 Modify "IN A" fields 7.10 Modify SOA Values 7.11 Wait the propagation 7.12 Deactivate services in the old address range 10 Resumed procedure 11 Traumatically change of provider 11.1 Help from a third party 11.1.1 Steps AP?NDICE A. Glossary AP?NDICE B. SOA Values AP?NDICE C. ES-NIC form example AP?NDICE D. References 2 Abstract DNS administration is considered to be typically an easy task by network and system administrators. Indeed, the daily administration of the DNS service in a generic organisation with a basic configuration should not imply major difficulties in its operation, but when a given organisation has more requirements than the basics or there?s an issue involving the DNS service, the complexity of the problem could jeopardize even administrators with years of experience in the field. One of the most complex and problematic situations which may be found operating a DNS server -even more complex than its initial installation- is to perform all tasks involved in an IP space migration. (i.e. Move all the information services in use in an organisation which is using the IP space assigned by its original provider to a new IP space assigned by a new provider). This migration basically implies an ordered sequence of changes in the information services under the organisation?s domain name (i.e. web, e-mail, ftp, ...). This changes basically means updating the IP address of these services/servers in the primary DNS server for that domain. Given this is not a situation network or systems administrators need to face off, it is common to make mistakes when undertaking the migration process, mistakes which could be fatal for the services depending on the DNS service. This situations and scenaries have been observed live by the author as he has been involved in these issues more often than desired. An additional problem to this migration process is the given fact that not every factor involved in the provider change can be controlled by the administrator. Even in the best case, the IP address or addresses of the authoritative DNS servers for that domain need to be updated in the upper domain DNS service (typically a top level domain ".com", ".es", ".de",".nl",...). These domains are operated by registries (country registries or companies like Verisign) where the update requests can be submitted by filling up either web-forms or sending a FAX. The update/changes could take place within a given period of time (either days or even weeks), being it almost impossible to know the exact moment when the changes will occur. Besides the fuzzyness this external dependency involves, any mistake during the migration procedure may provoke the lost of visibility of the domain during a long period of time. Having to chase the registrar, sending FAXes and even letters (proving authenticity somehow) in order to update the IP addresses with the right values for the authoritative DNS servers IPs. The main goal of this document is to define the required procedures to migrate a set of servers under a given Internet domain name from its original IP address space to another, avoiding or at least reducing to the minimum the possible invisibility of the domain name (and all services associated) from any other end of Internet. These procedures will be defined in the most generic way possible, following the RFC style, in order to make a useful tool out of this for administrators. The information which makes a domain name visible on the Internet (i.e Resource Records "RRs" associated to our domain) is firstly configured in the parent DNS server of that domain name. As these servers are queried by other DNS servers (typically configured as cache-resolvers) this information, these RRs are stored (i.e. cached) by them, so it gets spread all across the Internet. These RRs are stored by all cache resolver DNS servers with an expiration time, so the authoritative DNS servers for that domain are not queried again for that information. IP space migrations will usually involve either the change of IP address of the authoritative DNS servers as well as the servers providing typical internet services (i.e. http, ftp, smtp...). In case the IP addresses of all servers (DNS and other services) are simultaneously changed to the new IP addresses (according to the new IP addressing scheme) an immediate "blackout" would happen until the former DNS information related to our domain name expires. This information (i.e. Resource Records associated to our domain) are stored in the parent DNS servers, usually TLD servers as explained in the first paragraph of this section. To avoid the "blackout" and keep all internet services visible from Internet or reduce this time to the minimum, all tasks involved must be correctly and thoroughly scheduled. 3. Unordered migration If there is no ordered migration of the services, but all of them are changed simultaneously, and even considering that the related NIC change the DNS information instantly, there will be a blackout. This time depends on the computer that tries to access the services and is very variable. The following sections show all the cases that can happen with the estimated blackout time so the reader can understand the need of a coordinated migration. In all of this cases the changes of the servers are made in a time "t". 3.1 Resolving without data in the cache If the request is originated in a computer that never have accessed to the services of the migrated domain and the DNS server used has never accessed to this domain, it will not have any data in its cache with this information and when he tries to access any service in a time "t+x", the computer ask to his resolver, this one check in his cache and when he sees that he don't have the needed information, will check against the server of the TLD, that in this theorical discussion has the information up to date, will get the IP address of the new DNS server and will check with this one the IP address of the service that he want to use, getting the new one because the server checked is up to date. In this case the blackout time is zero 3.2 Resolving with out of date NIC information The second scenario happens when the NIC or equivalent organisation doesn't update his DNS server simultaneously with the domain change but in a time "t+n" and the computer that wants to make the request is in the same situation of the previous section. In this case a request made between the times "t" and "t+n" to the upper level domain server will return the old IP address of the DNS server. As this server has change it's IP address, the request of one of its services, i.e. www.foo.bar, wont work, because the DNS of foo.bar isn't in the IP address. But the resolver will maintain in his cache this address until the expire time "e" finish, time that the TLD server distributes together with the incorrect IP address of the domain server. This IP address will be returned during this time each time that the resolver receives the same request. Once this time "e" arrives, the resolver from the customer will discard the information stored in the cache y will do the request again, getting the correct IP address of the DNS server. The worst case in this situation is unpredictable because the time "n" is based in the upgrade of the TLD server and this upgrade in many cases is human based and can have a window of days. 3.3 Request with the DNS server in the cache The third situation happens if the resolver of the customer doesn't have the IP address of the associated service, i.e. www.foo.bar, but have the one of its DNS server. In the worst case the resolver stores the IP address of the DNS server in the time t-1 and will keep stored this address, as valid, during the time e. So during the time "e-1" this address will stay in the cache thought its invalid. For the domains of the Spain ccTLD (.es) the lifetime "e" is 172.800 seconds -two days- and the blackout period will be of 172.799 seconds, practically two days. For domains .com, .net and .org, handled actually by Network Solutions incorporated, this time "e" is 86.400 seconds and the maximum blackout can be of 86.399 seconds, practically one day. TLD of the domain to be migrated Maximum blackout time .es 172.799 seconds .com, .net, .org 86.399 seconds 3.4 Request with the solicited server in the cache If the resolver of the customer has the IP address of the server, it will maintain this address during a time "l", even though the real IP address change in the original DNS server, and this old address will be returned to the customer. In the worst case if the resolver stored the IP address one second before the change; the blackout time will be of "l-1" seconds. The value "l" is the field "TTL" or "Time To Live" of the SOA register of the domain. For the ".es" domains associated to the Spanish NIC, the standard recommendation for this field is[1] 172.800 seconds, i.e. two days and the blackout will be of 172.799 seconds or two days less one second. In the same document the recommendation for domains with frequent changes is to reduce this TTL to 28.800, i.e. 8 hours and the blackout of the server will be reduced to 28.799 seconds or 8 hours less one second. Even this last value can be high for services with intensive use and in this document besides the procedures for change we suggest alternate values for this field. The RIPE recommendations for the SOA field[2] suggest the same value for the TTL field in standard situations, that is 172.800 seconds, and consequently the same considerations are to be taken into account. TTL recommendations Maximum blackout ES-NIC, normal situation 172.799 seconds ES-NIC, frequent changes 28.799 seconds RIPE 172.799 seconds 3.5 Request to the secondary server In the previous cases we have supposed that the request was made always to the primary server but the situation can worsen if the request is made to the secondary server. The address update of the primary server must be coordinated with the secondary server, but the change of address pointing to the primary server in the configuration of the secondary server must be made manually and until the administrator of this equipment -that can depend of another organisation, typically many companies use the secondary DNS service provide by his carrier, ISP or NIC- doesn't update the IP address of the primary server and reload the configuration, this authoritative server wont contain the new values and will return incorrect information. This update time "a" of the secondary server must be added to the values stated previously but cant be predicted accurately because usually depends of human actions. If this change is not made, the secondary server will keep the old IP address and after the refresh time will try to renew the information from the primary server in the known address but it wont find it, or at least wont find the server with the new information and the update wont happen or will be made with incorrect data because will get it from the old machine. 4 Situations wich involve IP migration There are several situations that can drive to these changes in the DNS, including the following: 4.1 Moving a domain name from a given ISP to other When a given organisation with a domain name, changes from one ISP to another, either by economical or any other reasons, the new ISP will have different IP addresses and the namserver serving the DNS information for this organisation will be have an IP from this ISP. It could happen that it is the ISP who owns and manages the DNS server an service for the organisation, or the organisation itself who does it. In any case, collaboration from the previous ISP with the new one is always very recommendable in order to avoid a blackout in the internet for the organisation?s services. 4.2 The upstream ISP changes IP addresses Even if the organisation does not change of ISP, it could occur that the ISP could change its IP range, either because it moves to a different telecommunications operator or it could also be due to the ISP becomes LIR (Local Internet Registry) itself and renumbering is required. It?s also possible, although not likely to happen, that the ISP?s upstream carrier reorganises its IP addressing scheme and changes the IP range assigned to this ISP. This is essentially the same case as the simply moving from one ISP to another, but with the advantage that means not having to move the servers physically and the collaboration of the ISP is guaranteed as it is the same one. 5 Prerequisites To be able to do the migration process, it is necessary to meet a set of requirements that should be checked in advance to avoid problems during the migration. 5.1 Control over the new DNS servers It is compulsory that the person in charge of the domain migration or any other person under his/her supervision must have control over the contents and operation of the DNS server that will contain the domain information at the end of the migration. This control doesn't mean necesarily physical property of the machine, not even administration rights over it, but it's necesary to have control over the DNS software and it's configuration files. The best approach is that this control is managed directly by the person in charge of the technical issues of the migration. If the DNS server is managed by other company, i.e. the ISP that handles the Internet access for the company, and this company don't want to transfer the control of the DNS, perhaps that server host more domains, it's compulsory to have a perfect coordination between the person in charge of the migration and the person in charge of the server. This coordination must allow the timed edition of the DNS files related to the domain and, more important, the reload of the server information just when needed, and this operation can only be made by the administrator of the server. 5.2 Authorized contact in the NIC This person responsible for the migration must be registered in the NIC and must be the administrative or technical contact with permission to make changes in the domain information, specially the host name and IP of domain servers. It can happen that the existing contacts in the NIC for the domain wont be in the company anymore, that their email address doesn't exist (this email address doesn't need to belong to the domain) or that this contacts doesn't want to help in the migration as individuals or as a company. If this happen, this problem must be solved before any other step is made, specially you can't establish a calendar because recovering the control can be a time consuming task that is outside the scope of this document and that usually involves some administrivia including sending faxes and/or letters with the company letterhead to the NIC. 5.3 Minimal DNS knowledge Though is not compulsory a in depth knowledge of the DNS protocol and its implementations, it is necessary a minimal understanding of it's fundamentals and the working of the implementation used. If you don't own this understanding and a minimal experience on the subject the best you can do is get help from some technician with this knowledge. The second best thing that you can do is to install a DNS server in a spare computer and try all the operations that should be made latter but without having any delegation on this server neither using it as a resolver, so the problems that could arise and even the same test won't affect other users. 5.4 Plan in advance To avoid problems with time expiration and with incorrect data in the cache as explained previously, the changes must be started with enough time. Two weeks is usually a window enough wide if we follow the standard values recommended by RIPE and/or the local NIC for the SOA fields. Sometimes two weeks won't be enough and the time frame must be recalculated based on the SOA values. You should calculate the time spend in each step, add all and obtain the total time spend in the transition. You should take into account that some steps are not technical, but physical with the transportation of machines or administrative steps that can employ a large segment of the overall time. Very important is not to be optimistic (better pessimistic) in the forecast that the carrier gives you and if the migration implies changing carriers, you must maintain connectivity with the former one you shouldn't ask the termination of the service based on the forecast of installation of the new carrier. This forecast is usually very volatile and depends of municipality permissions, poor quality in the cabling, overbooking in the switching equipment of the carrier, etc. Any of these elements can lead of delays of days, weeks or even more (The author of this document suffered a delay of three months in the installation of a line due to the lack of license to install a cable by the carrier). If you have asked for the termination of the contract with the previous carrier and suffer one of these problems, you will find yourself in the nasty situation of not having Internet connectivity and, even worse, loosing the DNS servers as explained previously. So, even if this involves a bigger cost, you must keep the former carrier connectivity until the migration is finished. 5.5 Independent and duplicated DNS servers This migration plan forces that the hardware used by the DNS servers to be independent of the hardware used by the other servers, so the change of network configuration of this servers can be made without impact in the other services. Also, to ensure the stability of the services, these DNS servers must be duplicated during some time, so you will need duplicate machines. Once the migration is finished the machines used for the old IP address can be unplugged and its hardware reused. If the migration is between two ISP and these are the ones that provide the DNS service, the duplicated DNS server is implied and you don't need to install additional hardware. 5.6 If possible, duplicate the other servers Though is not so critical as the previous requirement, try to duplicate all servers accessible from Internet. This will allow not only the domain to be visible all the time, but also the services to keep running all the time. If you don't use duplicate servers, during the migration of the servers from one IP range to other -even if there is no physical movement- you get a blackout. This blackout is not limited to the shutdown time of the server but you must add the propagation time of the new IP address. Though you should reduce the TTL of this address, the IP address are stored in the cache of other DNS server with this limited TTL and will be returned until its expiration. 5.7 Coordination between ISP Though it's possible to make the migration without the cooperation of the administrator of the old DNS service (in many cases is an ISP that is losing a customer) and sometimes is the only way to go, we recommend looking for the help of both DNS administrators. There are no enforceable rules or laws for the former DNS administrator to help in the migration, and the only motivation is the good old Internet courtesy. 6 Scenario The scenario designed is probably one of the more complex but it's also one of the more generic and can be tailored to other situations removing the extra procedures. All the examples of in this document use the IP address ranges defined in the RFC 1918 [1] to avoid damaging the rights and network of the owner of an IP space in case of missconfiguration. Of course you must change this address for the ones assigned to you by the RIR/LIR in charge. In the same fashion the domains and subdomains used in this examples are fictitious and use the informal standard "foo.bar"[2]. Any coincidence with real domain names is purely accidental. 6.1 Starting situation Company X owns the domain "foo.bar" and the domain registry organisation of the top level is http://www.nic.bar/. This company X has Internet connectivity through the Internet carrier A, that has delegated to the X company the IP range 192.168.10.0/24 of his PA addressing block. Using this range, the network administrator of the company X has inserted the following information in the servers of the registry: * Primary server of the domain "foo.bar": 192.168.10.2 * Secondary server of the domain "foo.bar": 192.168.10.240 He also has installed the domain servers in these addresses and has configured them to translate the following names to its IP address: * www.foo.bar translates to 192.168.10.10 * mail.foo.bar translates to 192.168.10.15 He also configured the mail server information for the domain: * The mail server for the domain foo.bar is mail.foo.bar with a preference of 10 The administrator of the network has too configured the inverse resolution of the network in the name servers after getting this inverse resolution in the RIR/LIR. So, the configuration files for the BIND 9 DNS server should be as follows if you have follow the RIPE published recommendations for the SOA values. $ORIGIN foo.bar. ; @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( 2001070401 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 3600000 ; expire, seconds 172800 ) ; Minimum TT, seconds ; name servers IN NS primary.foo.bar. IN NS secondary.foo.bar. ; mail servers IN MX 10 mail.foo.bar. localhost IN A 127.0.0.1 www IN A 192.168.10.10 mail IN A 192.168.10.15 primary IN A 192.168.10.2 secondary IN A 192.168.10.240 The inverse resolution from IP to names -this resolution must be delegated from RIPE or the LIR- is as follows: $ORIGIN 10.168.192.IN-ADDR.ARPA. @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( ; 2001070401 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 3600000 ; expire 172800 ) ; minimum TTL ; name servers NS primary.foo.bar. NS secondary.foo.bar. ; host lists 2 PTR primary.foo.bar. 10 PTR www.foo.bar. 15 PTR mail.foo.bar. 240 PTR secondary.foo.bar. 6.2 Ending situation After the migration, company X will be connected through carrier B and both companies have agreed carrier B to delegate to company X a range of IP address, specifically 10.40.5.0/24. The new servers will have the following information: * Primary server for the domain "foo.bar": 10.40.5.2 * Secondary server for the domain "foo.bar": 10.40.5.240 The address for the associated servers should be set as follows: * www.foo.bar translates to 10.40.5.10 * mail.foo.bar translates to a 10.40.5.15 The mail server will be configured for the domain as follows: * The mail server for the domain foo.bar is mail.foo.bar with a preference of 10 and no secondary mail server The inverse resolution for the new IP range will be delegated and configured correctly. The archive for the zone must finish in this configuration: $ORIGIN foo.bar. ; @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( 2001072001 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 3600000 ; expire, seconds 172800 ) ; minimum TTL, seconds ; name servers IN NS primary.foo.bar. IN NS secondary.foo.bar. ; mail servers IN MX 10 mail.foo.bar. localhost IN A 127.0.0.1 www IN A 10.40.5.10 mail IN A 10.40.5.15 primary IN A 10.40.5.2 secondary IN A 10.40.5.240 And the DNS configuration for the new inverse resolution, that you should delegate, will be: $ORIGIN 5.40.10.IN-ADDR.ARPA. @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( ; 2001072001 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 2592000 ; expire 172800 ) ; minimum TTL ; name servers NS primary.foo.bar. NS secondary.foo.bar. ; hosts list 2 PTR primary.foo.bar. 10 PTR www.foo.bar. 15 PTR mail.foo.bar. 240 PTR secondary.foo.bar. 6.3 Limitations Some of the procedures described in this work are specific of each NIC, mainly the administrative tasks and the forms to be completed. In the following description the steps associated with the NIC are explained generically using the common subset. 7 Migration procedure The underlying idea is to achieve the transition in a few steps, having to complete each of them considering the times required for the changes to get propagated, before starting the next one. 7.1 Create a new DNS server As explained before, it is recommended to install new DNS servers (i.e. a new primary DNS server) with the new ISP?s IP addresses, with the same information as the old DNS primary server. The DNS servers in the previous ISP are maintained to reply to queries from clients who don?t have yet the new DNS server?s IP address. The steps to introduce new data in this machine are: 7.1.1 Duplicate the information for the domain Once there?s a new primary nameserver in the new ISP (i.e. running BIND, dnscache, djbdns, nsd, ?) the configuration and zone files need to be the same as the existing before in the nameservers hosted by the previous ISP (still up&running), with minor changes. This can be achieved with a zone transfer (AXFR) from the old primary server to the new server. In a Unix server running DNS Bind 8.0 or later, the transfer of the domain can be made with: #dig @192.168.10.2 foo.bar. axfr in > /etc/foo.db Once the zone is transferred, the domain name has to be added to the configuration file, usually called named.conf in BIND installations. It should look like this: zone "foo.bar." { type master; file foo.db; }; The most important to preserve is the current addresses for the internet servers, so www.foo.bar still point to 192.168.10.10 and mail.foo.bar point to 192.168.10.15. 7.1.2 Modify the server own address It?s also necessary to edit the zone file (foo.db) to modify the ?IN NS? resource record to the new DNS server?s name. The secondary servers only need to be modified if they are in the IP space of the previous ISP and the new ones will be in the new ISP IP space. There?s no need to do this if all secondary servers are outside our network, there?s no need to change their IP address. The administrators of the secondary servers will only have to modify their configurations files to point to the new IP address of the primary nameserver in case they configured their ?named.conf? file using the IP address instead of the server?s name. So far no changes happen in the parent servers hosted by the corresponding NIC or registrar. This will happen after some more steps. 7.1.3 Reduce the SOA times Once the described changes are done in the new nameserver, it is necessary or recommendable to reduce the times expressed in the SOA header of the zone file ?foo.db?. Originally in the top of the file "foo.db" you will find the following lines (the values stored in each field can be different depending if you follow the recommendations of RIPE or the ones of your local NIC or if you have follow you own instincts): @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( ; 2001072001 ; serial based on "date+number" 86400 ; refresh, seconds 7200 ; retry, seconds 2592000 ; expire, seconds 172800 ) ; TTL minimum, seconds It is recommended to note these values to restore this configuration after the migration process is completed. New values are recommendable before switching from the previous nameservers to the new nameservers. Suggested values for this field depend of the load of the servers, how critical is the service and if they can be duplicated. If some they can be duplicated and/or are not critical, the values can be relaxed. Field Old value New value without duplication New value with duplication Serial number X X+1 X+1 Refresh 86400 300 14400 Retry 7200 150 (=)7200 Expire 2592000 (=)2592000 (=)2592000 TTL 172800 300 14400 * Field marked with (=) doesn't need to be modified and can preserve their original values. * The field "serial" must be incremented respect the previous value of the same field. This is the only technical requirement of this field, but most organisations related to the domain handling suggest that the serial number follows the format: YYYYMMDDNN, with YYYY being the year with four digits, MM the month with two digits, DD the day of the month with two digits and NN the change number inside that day and starting by one each day. So the first change made on July, 2, 2004 will have the serial 2004070201. If the same day you make other change, the new serial will be 2004070202, but if you make another change the next day, its serial will be 2004070301. * The refresh field can have two values depending if the services can be duplicated in another server. o If you can duplicate them, the value can be greater because if some client access the old IP address after the change the old server will still be in place and will answer the query. A value of 14400 seconds -four hours- as suggested by some NIC allows you to reduce the number of queries that the secondary server make without danger of blackout. o If you can't duplicate the servers, a value of 300 in the refresh field will force the secondary server to check every 300 seconds -5 minutes- that the information of the primary server hasn't been modified. This check doesn't imply a transfer of all the domain information, only the SOA record to check the serial number. If this values have been incremented then all domain information will be transferred. This value has been selected because a blackout of five minutes is usually acceptable even in high load servers during low traffic times (night, weekends). * The retry field must be lower that then refresh time. The recommendation for this field is to be an integer fraction of the last one. If the servers are duplicated you can keep the existing one if its lower than the refresh time. If the servers aren't duplicated, we suggest a value half the refresh time, that is, 150 seconds. This small value is not excessive because the secondary servers use the retry time only if there are connectivity problems and they can't check the information from the primary when the refresh time expires. * The TTL field has similar considerations to the ones made with the refresh time, but in this case the considerations apply to customers not to the secondary servers. Also the transfers made when this lifetime expires -14400 seconds if the servers are duplicated and 300 if they aren't- are only for the A register of the requested service. After all this changes the file "foo.db" will have the following data. Take into account that the only A registers that have new values are the ones of the DNS servers itself: @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( ; 2001072002 ; serial based on "date+number" 300 ; refresh, seconds 7200 ; retry, seconds 2592000 ; expire, seconds 300 ) ; minimum TTL, seconds ; name servers IN NS primary.foo.bar. IN NS secondary.foo.bar. ; mail servers IN MX 10 mail.foo.bar. localhost IN A 127.0.0.1 www IN A 192.168.10.10 mail IN A 192.168.10.15 primary IN A 10.40.5.2 secondary IN A 10.40.5.240 7.2 Check the new server Once the values in the SOA header have been updated, it is necessary to reload the zone and check the server is operating as expected. In case BIND is in use, these commands can be used: To reload the server: # ndc reload To check the server is running appropriately # ndc status If logging has been appropriately configured it is advisable to have a look at it to check the zone modified has been correctly loaded. If using NOTIFY feature, we could also see whether the server has ?notified? to the secondaries about it. Finally, querying the server by using ?dig? or ?nslookup? tools is recommendable: $ nslookup - 10.40.5.2 > www.foo.bar. 192.168.10.10 7.3 Create the reverse resolution of the new address This step can be made even before installing any machine in the new range. You need to create a new domain configuration file, lets call iit 10.40.5.db: $ORIGIN 5.40.10.IN-ADDR.ARPA. @ IN SOA primary.foo.bar. hostmaster.foo.bar. ( ; 2004072001 ; serial based on "date+number" 86400 ; refresh 7200 ; retry 2592000 ; expire 172800 ) ; minimum TTL ; name servers NS primary.foo.bar. NS secondary.foo.bar. ; hosts list 2 PTR primary.foo.bar. 10 PTR www.foo.bar. 15 PTR mail.foo.bar. 240 PTR secondary.foo.bar. To let the DNS server know about this file you will need to edit the file /etc/named.conf and add: zone "5.40.10.in-addr.arpa." { type master; file 10.40.5.db; }; Reload the file DNS server configuration after this configuration. In the secondary server simply add the following lines to /etc/named.conf: Zone "5.40.10.in-addr.arpa." in { Type slave; File "db.10.40.5"; Masters { 10.40.5.2; }; }; Reload the file DNS server configuration after this configuration. 7.4 Delegate the reverse resolution of the new address range Request to your RIR/LIR the delegation of the reverse resolution of the new address range. This delegation must be made pointing to the address of the new DNS server s(10.40.5.2 and 10.40.5.240) 7.5 Change glue records in the parent DNS server This is now possible. Requesting the change of the glue records for the zone we are migrating is a critical administrative process consisting in submitting the corresponding form. In this form it will be requested the change of IP address for the primary server of the zone and the secondaries in case these would be in the network of the previous ISP and will stay present in the new ISP network. Typically, ccTLD NICs have their own form, most of the times just in their local languages and sometimes in English as well. Using a local registrar entity could solve the possible language issue. The same applies basically for organisational TLDs (.com, .org, .net,?). The duration of this process absolutely depends on the NIC responsible for that domain and the period of time to wait until changes are alive, go from hours to even weeks. Always consider this waiting times pessimistically when planning the migration. It is fundamental that both nameservers (in case duplication was possible) are alive and running during this time as otherwise if the NIC checks for this servers and they are not alive the change would be postponed. Once the change at the parent server occurs, the new queries will be sent to the new primary nameserver. Clients with the previous primary nameserver?s IP address cached will not query the new server until the TTL time is reached. During that period of time these clients with old information cached will keep on querying the old primary nameserver. So the old primary nameserver will have to keep alive and running for some more time. This TTL is not controlled by us, but by the NIC. It is the TTL associated with the glue records for our domain in the parent?s zone. The expire times obtained at the moment of the writing of this document are: TLD Expire time in seconds .es 172.800 .com, .org .net 86.400 So until this time has elapsed since the change its unsure that the changes its propagated. NICs have normally a mechanism to notify the changes have been done to the responsibles for the domain but it is recommended to verify this by doing this: Checking the information in the whois database: [localhost:~] fernando% whois foo.bar Whois Server Version 1.3 Domain names in the .com, .net, and .org domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. Domain Name: FOO.BAR Registrar: NETWORK SOLUTIONS, INC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: PRIMARY.FOO.BAR Name Server: SECONDARY.FOO.BAR Updated Date: 03-may-2001 7.6 Modify the external secondaries Once the NIC has performed the requested changes in the whois database and the DNS parent servers and the changes have propagated it is time to update the secondary servers. These servers will be typically in outer networks and will be the corresponding administrator to whom the change request will be sent. The secondary nameserver administrators will have to change all possible reference to the primary server IP address to the new IP address and reload their servers if possible so changes are made alive immediately. This change is made modifying the following fields: In servers with version 4.x of BIND the file to be modified is /etc/named.boot and the change to do is substitute: Secondary foo.bar 192.168.10.2 db.foo By Secondary foo.bar 10.40.5.2 db.foo For servers with versions 8.x or 9.x of BIND the file to be modified is /etc/named.conf and the change to be made is: Zone "foo.bar" in { Type slave; File "db.foo"; Masters { 192.168.10.2; }; }; By Zone "foo.bar" in { Type slave; File "db.foo"; Masters { 10.40.5.2; }; }; 7.7 Verify the secondaries Once this changes are made, you must check the change using dig or nslookup like in the following example. In this one we suppose there is a third DNS server in an external network in addition to the two stated in the initial configuration: $ nslookup - dns.otroservidor.com > set type=ns > foo.bar. foo.bar nameserver = primary.foo.bar foo.bar nameserver = secondary.foo.bar foo.bar nameserver = dns.otherserver.com primary.foo.bar internet address = 10.40.5.2 secondary.foo.bar internet address = 10.40.5.240 dns.otherserver.com internet address = 192.168.13.13 In this information you must check the information of the primary server. The IP address associated to this must be the new one you have just set. If the address is the old one the change hasn't happen because the secondary server didn't reload the data or is incorrectly configured. 7.8 Wait until changes are propagated Once all changes are done, it is necessary to wait until the new information is propagated. The minimum time for this to happen would be the ?Expiration? time expressed in the SOA header. It is recommended to check the changes have propagated by querying other nameservers randomly chosen. When all these servers return (reply) the new information, it is possible to proceed with next steps. This verification can be made as follows: $ nslookup - external-name-server > set type=NS > foo.bar foo.bar nameserver = primary.foo.bar foo.bar nameserver = secondary.foo.bar foo.bar nameserver = dns.otherserver.com primary.foo.bar internet address = 10.40.5.2 secondary.foo.bar internet address = 10.40.5.240 The answer must be the IP address of the new DNS server 7.9 Change servers IP addresses At this stage, a new DNS server known all across the internet is available. The times expressed in the SOA header are still the ?reduced? ones, but the information this server about the internet servers in the organisation is the previous one (i.e. the old IP addresses hopefully still routed by the previous ISP for this organisation). It is, the ?IN A? resource records are still pointing to the previous IP addresses. Next it is necessary to change the internet servers IP addresses. To migrate all the network it is necessary to modify all these ?IN A? resource records so they make reference to the new IP addresses assigned by the new ISP to the organisation. This has to be coordinated with the installation of the new systems with the new IP addresses, otherwise the DNS service will be pointing to unexisting internet servers. This situation is not problematic for workstations but for servers providing public services to the rest of the Internet. Specially critical would be services like electronic mail or web service. Again, as it occurred with the DNS service migration, all this process will be much easier if duplication of servers is possible. 7.9.1 Modify "IN A" fields After the installation of the servers in the new address range, you must modify the records in the new DNS servers of the domain, to point to the new address of the equipment. It's not compulsory to made the change in the old DNS servers, in theory this servers are not used anymore but, it's not a bad idea to change them also. If the secondary doesn't have the updated information, the two servers can distribute incongruent information, and worse, inconsistent information can be obtained if two servers are accessed (i.e. reading the mail from two different POP3 servers). The conclusion is that it is recommended to speed up the update of the secondaries. One method of instant update is using the NOTIFY[10] message, sent by the primary server when the information its modified. This message tells the secondaries that the information of that domain has been modified and they need to reload. However not all the DNS servers support this message -the primary must support it to send the NOTIFY and the secondaries must act upon it when received. If a secondary doesn't support the message, try to push it doing a manual reload of the configuration. The servers must be changed in the foo.db from: www IN A 192.168.10.10 mail IN A 192.168.10.15 to: www IN A 10.40.5.10 mail IN A 10.40.5.15 7.10 Modify SOA values The same way we did for the DNS server changes, we will wait until the contents of the zone file get propagated, checking a list of nameservers to verify this. See section 7.7 and appendix A. SOA times have to remain lower until all changes are done and the new information is propagated. Afterwards, the recommended values (v.g. RIPE recommended values) can be restored. 7.11 Wait the propagation Use the method described previously with the nslookup or dig commands to verify the redistribution of the changes. Use a selected group of servers as a statistical measure of the change. 7.12 Deactivate services in the old address range With the changes made, all request are directed to the new servers and you can disable all servers in the old range, including the DNS server and the resolution of the reverse DNS. 8 Resumed procedure If you have experience managing DNS servers, this abbreviated list will be enough for you: * Create (install and configure) a DNS server in the new address space * Configure this server with the information related to the current servers and their IP. That is, copy the existing "A", "MX" records, etc. * In this configuration, modify the primary name server record (NS) to point to this new server himself. * Modify the address of the secondary name servers only if they are also in the address range to migrate. Don't change them if thy are located in other networks (ISP, carrier, NIC) * Reduce the SOA times of the domain as indicated in appendix B * Start the server * Use a DNS client program (nslookup, dig) to check all the information * Configure the inverse resolution of the new address range in the new server, inserting "PTR" records for all servers to be migrated * Request the inverse resolution delegation of the new address range to the LIR or RIR * Fill and send the form asking the NIC the change of primary server (and secondary if its located in the same network) * Wait for the changes to take effect and to propagate * Verify the propagation of changes with some DNS tools and checking in some DN servers distributed around the world * If possible, install duplicate servers (mail, http, etc.) In the new address range. * Modify the "A" records of the new DNS server to point to the new servers * Wait to the changes to be propagated (verify again with several external servers) * Restore the SOA values to their original value * Deactivate the old DNS servers 9 Traumatically change of provider The best method to migrate the services from one provider to other is to keep both providers and their IP address during all the change. But if you can't have both connections simultaneously, the migration is more complex, critical and the blackout can be very long. The main problem is that you can't have both address range simultaneously and so you can't keep servers in both ranges at the same time. 9.1 Help from a third party The minimum requirements are to have a DNS server visible all the time. This is a difficult task, because you don't know in advance when the information will change and some NIC ask for the new server to be configured (and they check it) before making the change. The only way to meet this requirement in this scenery is through a third party that provides a DNS server for the domain across the migration. In this case the only service that is keep active is the DNS. The blackout of all the other services depends of the time between the unplug from the old provider and the connection with the new one. 9.2 Steps A quick description of the process is: * Reduce the SOA values of the existing DNS and wait for the information to propagate * Install a new DNS server in a third party network and configure that DNS server as a primary server * Change the information of the NIC to point to this DNS server * Wait the information to propagate * Remove the servers (web, mail, etc) from the old ISP of unplug your network from the old ISP, depending of the situation * Install the servers in the new ISP or connect your network to the new carrier. This jump from the old to the new carrier must be made ASAP to reduce the blackout, though usually this time depends of the providers * In the server installed in the third party network, change the IP address for the new ones * Install a DNS server in the new network and configure it as a primary of the domain with the address of the new servers and the NS record pointing to itself. Return the SOA values of this server to the original ones * Send the request to the NIC to change the IP address of the server to point to this new one * When the information is updated and propagated, disable the DNS server installed in the third party During the time lapse between the unplug from one provider and the plug of the new one (hours, days, even weeks) there is a blackout of the services because the only server that answer request is the DNS server. Ap?ndice A. Glossary To Be Filled Ap?ndice B. SOA values Beside the recommendations that RIPE and the local NIC made regarding the SOA values to be filled in the domain files for the second level domains, to know the expire time of the IP address assigned to that domain you must know the SOA values of the TLD associated so you can check the TTL field and know how long will stay the old DNS server address in the cache of the client resolvers. To discover this values, that sometimes are not published, do the following: [localhost:~] fernando% nslookup Default Server: dns.foo.bar Address: 192.168.10.2 > set type=ns > es. Server: dns.foo.bar Address: 192.168.10.2 Non-authoritative answer: es nameserver = NS3.NIC.FR es nameserver = MUNNARI.OZ.AU es nameserver = NS.EU.NET es nameserver = NS.EUNET.es es nameserver = PRADES.CESCA.es es nameserver = SUN.REDIRIS.es es nameserver = SUNIC.SUNET.SE es nameserver = NS.UU.NET es nameserver = NS1.nic.es es nameserver = ineco.nic.es Authoritative answers can be found from: NS3.NIC.FR internet address = 192.134.0.49 MUNNARI.OZ.AU internet address = 128.250.1.21 NS.EU.NET internet address = 192.16.202.11 NS.EUNET.es internet address = 193.127.1.11 PRADES.CESCA.es internet address = 192.94.163.152 SUN.REDIRIS.es internet address = 130.206.1.2 SUNIC.SUNET.SE internet address = 192.36.125.2 NS.UU.NET internet address = 137.39.1.3 NS1.nic.es internet address = 194.69.254.1 ineco.nic.es internet address = 194.69.254.2 > server ns1.nic.es Default Server: ns1.nic.es Address: 194.69.254.1 > set type=soa > es. Server: ns1.nic.es Address: 194.69.254.1 es origin = ns1.nic.es mail addr = hostmaster.nic.es serial = 2001070200 refresh = 86400 (1D) retry = 7200 (2H) expire = 2592000 (4w2d) minimum ttl = 172800 (2D) es nameserver = ns1.nic.es es nameserver = ineco.nic.es es nameserver = sun.rediris.es es nameserver = ns.eunet.es es nameserver = prades.cesca.es es nameserver = ns.eu.net es nameserver = sunic.sunet.se es nameserver = ns.uu.net es nameserver = munnari.oz.au es nameserver = ns3.nic.fr ns1.nic.es internet address = 194.69.254.1 ineco.nic.es internet address = 194.69.254.2 sun.rediris.es internet address = 130.206.1.2 ns.eunet.es internet address = 193.127.1.11 prades.cesca.es internet address = 192.94.163.152 ns.eu.net internet address = 192.16.202.11 sunic.sunet.se internet address = 192.36.125.2 ns.uu.net internet address = 137.39.1.3 munnari.oz.au internet address = 128.250.22.2 munnari.oz.au internet address = 128.250.1.21 ns3.nic.fr internet address = 192.134.0.49 > Doing this operation for the first level domain associated to the one you're migrating, you can get the expire and renewal times. For the .es domain this values are (in seconds): Refresh 86400 Retry 7200 Expire 2592000 Minimum TTL 172800 For the .com, .net and .org domain this values are: Refresh 1800 Retry 900 Expire 604800 Minimum TTL 86400 Ap?ndice C. ES-NIC form example This is an example of the filled form that you must send to the Spanish NIC (ES-NIC) to address domreg at nic.es to ask for a change of address of the domain servers. This form has been filled with the example data used along this document and must be send as a ASCII text. Note: We keep using the domain "foo.bar" in this example, though the Spanish NIC only have authority to register, delegate and modify information of the domain under the ".es" ccTLD, so this examples is not valid -it could be valid if we use foo.es. Information about how to fill this document can be obtained from the own ES-NIC pages [12] FSE Version: 1.0 SECCION 0 - Tipo Solicitud 0a. Accion a efectuar (N|CR|B|CD)..................:CR 0b. Estado Dominio (para N, CR o CD) (R|D|MX).....................:D 0c. Dominio a expirar (para CD)..:foo.bar SECCION 1 - Dominio Objeto de Registro 1. Nombre Dominio...............:foo.bar SECCION 2 - Organizacion Usuaria del Nombre de Dominio 2a. Nombre Organizacion Completo.:Foo Limitada 2b. Forma Juridica...............:S.L. 2c. N.I.F........................:B-99887766 2d. Fecha de Constitucion........:19610718 2e. Domicilio (Calle,No...)......:Fantasia, 555 2f. Domicilio (Municipio)........:Madrid 2g. Domicilio (Cod. Postal)......:E-28066 2h. Domicilio (Provincia)........:Madrid 2i. Domicilio (Pais).............:SPAIN SECCION 3 - Para Nombre de Dominio Asociado a Marca Registrada en lugar de al Nombre Oficial de la Organizacion 3a. Marca Registrada en OEPM.....: 3b. Numero Inscripcion en OEPM...: 3c. Fecha de Concesion...........: SECCION 4 - Persona de Contacto Administrativo 4a. NIC Handle...................:FGF2-NIC 4b. Nombre y Apellidos...........: 4c. Nombre Organizacion Completo.: 4d. Nombre Departamento..........: 4e. Cargo........................: 4f. Direccion (Calle,No...)......: 4g. Direccion (Municipio)........: 4h. Direccion (Cod. Postal)......: 4i. Direccion (Provincia)........: 4j. Direccion (Pais).............: 4k. E-mail.......................: 4l. Numero Fax...................: 4m. Numero Telefono..............: SECCION 5 - Persona(s) de Contacto Tecnico 5a. NIC Handle...................:FGF2-NIC 5b. Nombre y Apellidos...........: 5c. Nombre Organizacion Completo.: 5d. Nombre Departamento..........: 5e. Cargo........................: 5f. Direccion (Calle,No...)......: 5g. Direccion (Municipio)........: 5h. Direccion (Cod. Postal)......: 5i. Direccion (Provincia)........: 5j. Direccion (Pais).............: 5k. E-mail.......................: 5l. Numero Fax...................: 5m. Numero Telefono..............: SECCION 6 - Persona de Contacto Facturacion 6a. NIC Handle...................:FGF2-NIC 6b. Nombre y Apellidos...........: 6c. Nombre Organizacion Completo.: 6d. Nombre Departamento..........: 6e. Cargo........................: 6f. Direccion (Calle,No...)......: 6g. Direccion (Municipio)........: 6h. Direccion (Cod. Postal)......: 6i. Direccion (Provincia)........: 6j. Direccion (Pais).............: 6k. E-mail.......................: 6l. Numero Fax...................: 6m. Numero Telefono..............: 6n. N.I.F. (Organizacion en 6c)..: SECCIONES 7 Y 8 - Para Delegacion de Zona Asociada al Dominio 7a. Nombre Servidor Primario.....:primario.foo.bar 7b. Direccion IP S. Primario.....:10.40.5.2 8a. Nombre Servidor Secundario...:secundario.foo.bar 8b. Direccion IP S. Secundario...:10.40.5.240 SECCION 9 - Para Registro(s) MX asociado(s) al Dominio 9a. Nombre Estafeta E-mail SMTP..: SECCION 10 - Proveedor(es) de Servicio de Acceso a Internet 10. Acronimo de Proveedor........:CARRIERB La parte solicitante de esta operacion de registro de nombre de dominio (persona solicitante y organizacion usuaria en cuya representacion se actua) declara que: - Esta al corriente de las normas y procedimientos vigentes, terminos y condiciones, tarifas y forma de pago, requisitos tecnicos, etc. establecidos para el registro de nombres de dominio bajo "es" en el DNS de Internet y los acepta en su totalidad (la informacion mencionada es publica y puede obtenerse en http://www.nic.es). En particular, la organizacion usuaria acepta someterse a las normas, procedimientos, terminos y condiciones recogidos en el documento <> (disponible en ftp://ftp.nic.es/docs/es-dom-normas.txt) y a hacerlo por escrito firmado en el momento en que le sea requerido. - Conoce y acepta que las normas y procedimientos vigentes en la actualidad pueden sufrir en el futuro las modificaciones que el ES-NIC, la IANA (Internet Assigned Number Authority) o la ICANN (Internet Corporation for Assigned Names and Numbers) estimen oportunas. - Los datos facilitados en la presente solicitud son ciertos, salvo error u omision de buena fe. - Es consciente y acepta que cualquier falsedad en los datos consignados en la presente solicitud podra ser causa de rechazo de la misma o de baja del nombre de dominio en cualquier momento si el registro ya se hubiera producido y que, en este caso, el nombre de dominio es reutilizable para su posterior registro por parte de otra organizacion de acuerdo con las normas y procedimientos establecidos. - Se compromete, una vez le sea comunicado el resultado favorable del procesamiento de su solicitud, al pago, en los plazos establecidos, de las cuotas de alta y mantenimiento presentes y futuras que le correspondan. - Es consciente y acepta que, en caso de impago o pago insuficiente tras los plazos y prorrogas establecidos, el nombre de dominio registrado sera dado de baja y reutilizable desde ese mismo momento para su registro por parte de otra organizacion de acuerdo con las normas y procedimientos establecidos. - Es consciente y acepta que, en caso de no enviar al ES-NIC el correspondiente FSF ("Formulario de Solicitud Firmado") firmado por la persona de contacto administrativo de la organizacion usuaria (en los casos y plazos en que sea requerido) el nombre de dominio registrado sera dado de baja y reutilizable desde ese mismo momento para su registro por parte de otra organizacion de acuerdo con las normas y procedimientos establecidos. - Es consciente y acepta que, en caso de incompetencia o negligencia tecnica, un nombre de dominio registrado puede ser dado de baja de forma temporal o definitiva. - De acuerdo con su conocimiento, el uso del dominio propuesto no viola los derechos de ninguna tercera parte. - Es consciente y acepta de que el registro por parte del ES-NIC del nombre de dominio propuesto no le confiere ningun derecho legal sobre el mismo y de que cualquier disputa sobre los derechos de uso de un determinado nombre de dominio habra de ser resuelta entre las partes contendientes utilizando los cauces legales normales, tal y como establece el documento de Internet RFC 1591. Asimismo acepta que, en caso de disputa, el ES-NIC no tendra otro papel ni responsabilidad que el de facilitar a las partes en conflicto la informacion de contacto necesaria para que puedan resolver sus diferencias de la forma que crean oportuna (acuerdo bilateral, Juzgados y Tribunales competentes, etc.). - La persona de contacto administrativo de la organizacion usuaria facilitada en la presente solicitud es el responsable a todos los efectos de cualquier problema relacionado con los derechos de uso del nombre, lo cual es conocido y aceptado por el. - Todas las entidades y personas relacionadas en la presente solicitud son conscientes de ello y se cuenta con su consentimiento, de acuerdo con lo establecido por la Ley Organica 15/1999 de 13 de diciembre de Proteccion de Datos de Caracter Personal, para que sus datos aparezcan en las bases de datos internas y publicas mantenidas por el ES-NIC. - Se compromete a mantener siempre actualizada la informacion facilitada en esta solicitud, mediante el envio al ES-NIC de solicitudes de cambio de los datos de un registro previo siempre que haya modificaciones en cualquiera de los datos consignados. El no hacerlo asi puede dar lugar a que el dominio sea dado de baja (por ejemplo, por imposibilidad de comunicar con las personas que figuran como responsables de facturacion, administrativo o tecnico del dominio al no haber notificado cambios de sus datos de contacto o cambios de responsables). Ap?ndice D. References [1] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear, RFC 1918 - Address Allocation for Private Internets, February, 1996 [2] ripe-192 - Simple DNS Configuration Example [3] ripe-203 - Recommendations for DNS SOA Values [4] ripe-114 - Taking Care of Your Domain [5] "DNS & BIND 3rd Edition" by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc. [6] http://www.apache.org/ [7] D. Eastlake 3rd, C. Manros, E. Raymond, RFC 3092 - Etymology of "Foo", April,1 2001 [8] Alan O. Freier, Philip Karlton, Paul C. Kocher, Internet Draft - The SSL Protocol Version 3.0 , November, 18 1996 [9] D. Barr, RFC 1912, Common DNS Operational and Configuration Errors, February, 1996 [10] P. Vixie, RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), August, 1996 [11] http://www.nic.es/FSE/index.html [12] ftp://ftp.nic.es/docs/es-dom-dnsconfig.txt -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- -- From jim at rfc1035.com Wed Sep 15 21:15:07 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 15 Sep 2004 20:15:07 +0100 Subject: [dns-wg] DNS migration draft In-Reply-To: Message from Fernando Garcia of "Mon, 13 Sep 2004 11:01:59 +0200." Message-ID: <17686.1095275707@gromit.rfc1035.com> Fernando, thanks for producing such an comprehensive document. There's a lot to digest.... I've taken a quick scan through the document. My first impression is that it tries to do everything for everyone. So it might not have enough focus to help those who need help. :-( It's not clear who the document is aimed at. Some of it seems to be for policy makers. Some looks to be for naive DNS administrators. I wonder if it might be best to try and seperate the policy and implementation stuff? ie The WG gets two documents out of you for the price of one. :-) Your document is a good step in the right direction and I very much welcome this contribution. Has anyone else on the list got something to say about this? I look forward to a healthy discussion on this list and at the WG next week. I'll read the document more carefully over the weekend and follow up with detailed comments later. From alvaro.vives at consulintel.es Fri Sep 17 10:08:15 2004 From: alvaro.vives at consulintel.es (Alvaro Vives) Date: Fri, 17 Sep 2004 10:08:15 +0200 Subject: [dns-wg] DNS migration draft Message-ID: <00c701c49c8d$7d5830f0$ce00000a@consulintel.es> Hi Fernando, The draft looks fine for me, and as DNS administrator seems to be useful, thanks. My duties include managing DNS servers and several domains, with full IPv6 support. This way I found that from the IPv6 point of view some comments could be made, also from my own experience. You can interpret me as thinking aloud: 1) In case of having IPv4 and IPv6 addresses for the DNS server of example.org domain, changing addresses in different moments could lead to reduce the blackout, at least for the dualstack user resolvers. For example: example.org. NS A 10.1.2.3 NS AAAA 2001:800:40:2a2f::1 Your change of ISP could mean just changing the IPv4 or IPv6 address range. In this case just changing one of the addresses is enough, as the other still can be used. If you have to change both (v6 and v4), first change one of the RRs (AAAA for example, as the default behavour is to try first the AAAA address) and when everything is stable again change the other RR (A for example). I understand that few DNS servers have IPv6 and IPv4 connectivity today, but this situation will be there in the future, while coexistence of IPv4 and IPv6 increase. 2) Your solution is based on replicating equipment (having two servers), but, could this be avoided using two addresses in the same interface? Or for example installing two network cards to the server, one for each address? 3) It is a common practice to have servers in different ASs , this way being prepared for network looses of conectivity. This could be used as a backup solution, previous the address changes. For example, you have your master DNS server in you network with your future ex-ISP. You also have one or more secondaries in other networks with addresses from other ISP(S). Before changing the addreses of you master DNS server, you can change the configuration in order to make one of the secondaries being the new master. Then, after the changes of addresses, change the whole configuration (NIC, etc.) with the new address. This involves a lot of administrative work, but seems to me as a possible solution. This idea is based in our experience, as we have control over DNS servers in different ASs. Looks like your section 9.1, but with no help of third-party DNS server(s). Best regards, Alvaro Vives Consulintel ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From fgarcia at eurocomercial.es Fri Sep 17 11:06:01 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Fri, 17 Sep 2004 11:06:01 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: Message-ID: Hello Alvaro First of all, Thanks a lot for your feedback!. I really appreciate it. On 17/9/04 09:45, "Alvaro Vives" wrote: > 1) In case of having IPv4 and IPv6 addresses for the DNS server of example.org > domain, changing addresses in different moments could lead to reduce the > blackout, at least for the dualstack user resolvers. For example: > > example.org. NS A 10.1.2.3 > NS AAAA 2001:800:40:2a2f::1 IPv6 is one of the main items of my "to do" list for the meeting (not being a big expert in IPv6). I will include your proposal in the presentation to be discused/agreed (it seems fine to me) > 2) Your solution is based on replicating equipment (having two servers), but, > could this be avoided using two addresses in the same interface? Or for > example installing two network cards to the server, one for each address? I though about it, but it can lead to interesting problems. (thinking aloud): - The same equipment with to IP address/interfaces. Everything will follow the default route regardless of the source IP routing and A) packets wont follow best route B) could be filtered by anti spoofing filters. - Using source routing is a possible solution, but not al servers OS have source routing and using it is tricky at best. - Other solution is using source NAT in one connection. I.e. All packets received through the non default connection, to be NATed so the server seems them as coming from the NAT machine and so the reply goes to the NAT machine. Its ok if your software works ok with NAT (if you don't use statistics source IP autentication, etc.) perhaps we could add it as a option. > 3) It is a common practice to have servers in different ASs , this way being > prepared for network looses of conectivity. This could be used as a backup > solution, previous the address changes. For example, you have your master DNS > server in you network with your future ex-ISP. You also have one or more > secondaries in other networks with addresses from other ISP(S). Before > changing the addreses of you master DNS server, you can change the > configuration in order to make one of the secondaries being the new master. > Then, after the changes of addresses, change the whole configuration (NIC, > etc.) with the new address. This involves a lot of administrative work, but > seems to me as a possible solution. > This idea is based in our experience, as we have control over DNS servers in > different ASs. Looks like your section 9.1, but with no help of third-party > DNS server(s). -PROs: avoid installing a temporary machine -CONs: Two changes in the NIC in place of one. I prefer one change in the NIC (I am really, really afraid of some NICs working methods) and use your solution if no duplicate server is possible. We can discuss it, of course. Thanks a lot y Saludos. Fernando > > Best regards, > Alvaro Vives > Consulintel > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- -- From jeroen at unfix.org Fri Sep 17 11:12:30 2004 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 17 Sep 2004 11:12:30 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: References: Message-ID: <1095412350.1978.4754.camel@firenze.zurich.ibm.com> On Fri, 2004-09-17 at 11:06, Fernando Garcia wrote: > Hello Alvaro > > First of all, Thanks a lot for your feedback!. I really appreciate it. > > On 17/9/04 09:45, "Alvaro Vives" wrote: > > > 1) In case of having IPv4 and IPv6 addresses for the DNS server of example.org > > domain, changing addresses in different moments could lead to reduce the > > blackout, at least for the dualstack user resolvers. For example: > > > > example.org. NS A 10.1.2.3 > > NS AAAA 2001:800:40:2a2f::1 When documenting things or making examples please use the 192.0.2.0/24 and 2001:db8::/32 prefixes and not made up or real addresses... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From alvaro.vives at consulintel.es Fri Sep 17 11:25:32 2004 From: alvaro.vives at consulintel.es (Alvaro Vives) Date: Fri, 17 Sep 2004 11:25:32 +0200 Subject: RV: [dns-wg] DNS migration draft References: <1095412350.1978.4754.camel@firenze.zurich.ibm.com> Message-ID: <01ca01c49c98$48d076c0$ce00000a@consulintel.es> Hi Jeroen, Yes, my fault... Thanks. BR, Alvaro Vives Consulintel ----- Original Message ----- From: "Jeroen Massar" To: "Fernando Garcia" Cc: Sent: Friday, September 17, 2004 11:12 AM Subject: Re: RV: [dns-wg] DNS migration draft ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From brad at stop.mail-abuse.org Fri Sep 17 15:57:23 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Fri, 17 Sep 2004 15:57:23 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: References: Message-ID: At 11:06 AM +0200 2004-09-17, Fernando Garcia quoted "Alvaro Vives" : >> 1) In case of having IPv4 and IPv6 addresses for the DNS server >> of example.org domain, changing addresses in different moments could >> lead to reduce the blackout, at least for the dualstack user >> resolvers. For example: >> >> example.org. NS A 10.1.2.3 >> NS AAAA 2001:800:40:2a2f::1 > > IPv6 is one of the main items of my "to do" list for the meeting (not being > a big expert in IPv6). I will include your proposal in the presentation to > be discused/agreed (it seems fine to me) Sorry, this just hit me. Unfortunately, we don't use IP addresses in NS records. We use domainnames. Try this instead: example.org. NS ns1.example.org. ns1.example.org. A 10.1.2.3 AAAA 2001:800:40:2a2f::1 > - The same equipment with to IP address/interfaces. Everything will follow > the default route regardless of the source IP routing and A) packets wont > follow best route B) could be filtered by anti spoofing filters. Well, if the routes are via different providers, and the network administrator ensures that the incoming and outgoing packets are routed via the appropriate provider, I don't see what the problem is. You can always have sub-optimal routing, that's just something you have to live with. Otherwise, BIND is good at knowing which interface a given query came in on, and making sure that the reply goes back out on the same interface. So, there shouldn't be any filtering problems, at least not any more than you could potentially run into anyway. And I don't see any reason to use any of the other methods, regardless. The only issue I see here is that the delegation data won't match the in-zone data for these hostnames, unless you make changes at your registrar. Of course, some registrars may limit the number of known IP addresses for a given host/domain name, so you may have to decide how you want to deal with that problem. > -PROs: avoid installing a temporary machine > -CONs: Two changes in the NIC in place of one. > I prefer one change in the NIC (I am really, really afraid of some NICs > working methods) and use your solution if no duplicate server is possible. > We can discuss it, of course. I think you have the problem of multiple changes at the registrar no matter what. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fgarcia at eurocomercial.es Sat Sep 18 00:41:50 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Sat, 18 Sep 2004 00:41:50 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: Message-ID: Hello Brad On 17/9/04 15:57, "Brad Knowles" wrote: > Unfortunately, we don't use IP addresses in NS records. We use > domainnames. Try this instead: > > example.org. NS ns1.example.org. > ns1.example.org. A 10.1.2.3 > AAAA 2001:800:40:2a2f::1 Good point. I take note. > Well, if the routes are via different providers, and the network > administrator ensures that the incoming and outgoing packets are > routed via the appropriate provider, I don't see what the problem is. > You can always have sub-optimal routing, that's just something you > have to live with. Otherwise, BIND is good at knowing which > interface a given query came in on, and making sure that the reply > goes back out on the same interface. So, there shouldn't be any > filtering problems, at least not any more than you could potentially > run into anyway. I was not only thinking about DNS but all the other servers that must be migrated AND this document should not be BIND centered (though the examples use bind). I'm not sure about how the DNS server for Windows work, but let me be a little suspicious. The problem in your phrase is "network administrator ensures.. Outgoing packets are routed via the appropiate provider", this usually means "source routing" (I can paint many scenarios with this meaning), a not so simple task and the person -network administrator- that will use this document (I hope) is not a very qualified technician, if she/he is qualified, she/he wouldn't need this document. > > And I don't see any reason to use any of the other methods, regardless. > > > The only issue I see here is that the delegation data won't match > the in-zone data for these hostnames, unless you make changes at your > registrar. Of course, some registrars may limit the number of known > IP addresses for a given host/domain name, so you may have to decide > how you want to deal with that problem. > >> -PROs: avoid installing a temporary machine >> -CONs: Two changes in the NIC in place of one. >> I prefer one change in the NIC (I am really, really afraid of some NICs >> working methods) and use your solution if no duplicate server is possible. >> We can discuss it, of course. > > I think you have the problem of multiple changes at the registrar > no matter what. Its a problem, so the less changes, the better. Do you agree with this statement? Regards, Fernando -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- -- From brad at stop.mail-abuse.org Sat Sep 18 01:16:48 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Sat, 18 Sep 2004 01:16:48 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: References: Message-ID: At 12:41 AM +0200 2004-09-18, Fernando Garcia wrote: > I was not only thinking about DNS but all the other servers that must be > migrated AND this document should not be BIND centered (though the examples > use bind). I'm not sure about how the DNS server for Windows work, but let > me be a little suspicious. Fair enough. > The problem in your phrase is "network administrator ensures.. Outgoing > packets are routed via the appropiate provider", this usually means "source > routing" (I can paint many scenarios with this meaning), a not so simple > task and the person -network administrator- that will use this document (I > hope) is not a very qualified technician, if she/he is qualified, she/he > wouldn't need this document. The issue is that there's not really anything we can do to fix this problem. If their administrators are not minimally competent, there is nothing that you can do with any written document that can help, and indeed you are likely to make a bad situation worse by overwhelming them with procedures and policies that they are unlikely to understand. I think the principle needs to be kept as simple as possible, and the resulting document should be kept as short as possible. >> I think you have the problem of multiple changes at the registrar >> no matter what. > > Its a problem, so the less changes, the better. Do you agree with this > statement? Changes should be kept to a minimum, yes. However, I don't think we can assume that the Registrar will automatically screw up everything, every time. Simple sets of changes should be no problem, even if they need to be done more than once. If we assumed that the Registrar would screw up everything, every time, then the entire DNS would collapse. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From fgarcia at eurocomercial.es Mon Sep 20 15:51:55 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Mon, 20 Sep 2004 15:51:55 +0200 Subject: RV: [dns-wg] DNS migration draft In-Reply-To: Message-ID: Hi everybody On 18/9/04 01:16, "Brad Knowles" wrote: >> The problem in your phrase is "network administrator ensures.. Outgoing >> packets are routed via the appropiate provider", this usually means "source >> routing" (I can paint many scenarios with this meaning), a not so simple >> task and the person -network administrator- that will use this document (I >> hope) is not a very qualified technician, if she/he is qualified, she/he >> wouldn't need this document. > > The issue is that there's not really anything we can do to fix > this problem. If their administrators are not minimally competent, > there is nothing that you can do with any written document that can > help, and indeed you are likely to make a bad situation worse by > overwhelming them with procedures and policies that they are unlikely > to understand. > > I think the principle needs to be kept as simple as possible, and > the resulting document should be kept as short as possible. Good point. Jim said the same, so we probably should cut or split the document. I think this is something that must be speak in the wg on Thursday. BTW, mi personal opinion is that "source routing" doesnt fit in the "simple" category. I know a lot more people that feel comfortable with DNS but doesnt know source routing (but this is my personal opinion). > Changes should be kept to a minimum, yes. However, I don't think > we can assume that the Registrar will automatically screw up > everything, every time. Simple sets of changes should be no problem, > even if they need to be done more than once. Not necesarily screw up, but sometimes delay. The spanish NIC used to have a waiting queue of one week. 1 change= 1 week delay, 2 changes=2 weeks delay. (I think they have improve now, but I can guarantee the same for all the NIC under the RIPE umbrella). Regards, Fernando -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- -- From fgarcia at eurocomercial.es Wed Sep 22 10:58:53 2004 From: fgarcia at eurocomercial.es (Fernando Garcia) Date: Wed, 22 Sep 2004 09:58:53 +0100 Subject: [dns-wg] DNS migration draft - new version Message-ID: 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 at nic.es to ask for a change of address of the domain servers. This form has been filled with the example data used along this document and must be send as a ASCII text. Note: We keep using the domain "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 <> (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 , November, 18 1996 [9] D. Barr, RFC 1912, Common DNS Operational and Configuration Errors, February, 1996 [10] P. Vixie, RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY), August, 1996 [11] http://www.nic.es/FSE/index.html [12] ftp://ftp.nic.es/docs/es-dom-dnsconfig.txt -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Inform?tica y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- -- From brad at stop.mail-abuse.org Wed Sep 22 11:55:13 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 22 Sep 2004 11:55:13 +0200 Subject: [dns-wg] DNS migration draft - new version In-Reply-To: References: Message-ID: At 9:58 AM +0100 2004-09-22, Fernando Garcia wrote: Almost all the issues I have here have to do with the writing, not the technical details. I'm not a technical writer myself, but I hope you aren't offended if I make some suggestions. In general, you want to change passive voice into active voice throughout the document. Using passive voice makes reading the document much more difficult, which means you'll have to spend a lot more time writing and re-writing and re-re-writing to try to make up for the problems it introduces. If you change everything to using active voice, this should be less of a problem. If you have access to good writing analysis tools (including grammar, usage, mechanics, style, and organization), they can give you suggestions which can help with this process. However, I'd also suggest that you try to find a good technical writer who has a native command of the English language (or native equivalent). Software might be able to help you solve the easy 80% of the problems in this paper, but nothing beats a good technical writer who understands the reasoning behind the rules and knows when and how to break them, in addition to knowing the basics of things like Strunk & White or the Chicago Manual of Style. I know of these things, because I have met real technical writers, although I am not one myself. > 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. I think you meant "... face often", not "... face off". > 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. This paragraph seems confusing to me. Let's try re-wording this slightly: The person in charge of the domain migration, and all persons 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. Again, remove the first bits and re-word: Both ranges of IP addresses must be simultaneously active 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. Re-word: 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. > 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. Re-word: 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 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. Re-word: The process must be started early enough so that you can avoid problems with old data persisting too long, or new data not being propagated quickly enough. Once everything else is in place and ready to go, handling the changes at the registrar can usually be accomplished in two weeks, if you have followed the standard DNS values recommended by RIPE. If the other aspects of your transition will take longer than two weeks, you need to adjust your schedule so that they will be complete in time for the changes to have taken place at the registrar. > 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. Re-word: 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 (and presumably some time before and after), so you will 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. Re-word: This will not only allow the domain to be visible at all times throughout the transition, but to also keep the services running during the entire transition. > 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. Re-word: Otherwise, you will suffer a shutdown and lack of availability of services during the transition. > 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. Re-word: 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. Ideally, it should be a part of your written service contract that your old provider must provide any and all assistance you require during such a transition. If you do not currently have such a provision in your service contract, this would be a good time to get it amended. You certainly want to make sure that this provision is a part of the service contract with your new provider, should you ever have to go through this process again. And that's about as far as I've gotten so far. Many more hours of polishing and wordsmithing should be applied before this thing actually goes out. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From jim at rfc1035.com Wed Sep 22 13:35:55 2004 From: jim at rfc1035.com (Jim Reid) Date: Wed, 22 Sep 2004 12:35:55 +0100 Subject: [dns-wg] DNS migration draft - new version In-Reply-To: Message from Brad Knowles of "Wed, 22 Sep 2004 11:55:13 +0200." Message-ID: <29170.1095852955@gromit.rfc1035.com> 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. From brad at stop.mail-abuse.org Wed Sep 22 13:43:48 2004 From: brad at stop.mail-abuse.org (Brad Knowles) Date: Wed, 22 Sep 2004 13:43:48 +0200 Subject: [dns-wg] DNS migration draft - new version In-Reply-To: <29170.1095852955@gromit.rfc1035.com> References: <29170.1095852955@gromit.rfc1035.com> Message-ID: At 12:35 PM +0100 2004-09-22, Jim Reid wrote: > 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. Sorry, I didn't realize the time frame. I also didn't realize that I was going to have such extensive comments on such a relatively short section of the document. Sorry about that! -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From ddiaz at satec.es Wed Sep 22 13:58:41 2004 From: ddiaz at satec.es (Daniel Diaz) Date: Wed, 22 Sep 2004 13:58:41 +0200 Subject: [dns-wg] DNS migration draft - new version In-Reply-To: <29170.1095852955@gromit.rfc1035.com> Message-ID: <20040922115908.886214E041@postman.ripe.net> Jim, It is not possible for me to be in Manchester tomorrow but I?d be glad to be part of that small team to work on this document though. IMHO if this results in a ripe-doc to guide the DNS community it should focus on the operational issues leaving some theoretical or even political aspects aside. If we achieve this, again in my humble opinion, the document could be the "never written guide we needed during that IP migration ...". In esence we could have a good guide for DNS administrators who are involved in any of the situations described in the document. I had the chance to comment some of my opinions with Fernando about the document and I will be happy to keep on talking with him and the WG about it so if you want to count me in I?ll find some time for this. Regardz. -- daniel.diaz > -----Mensaje original----- > De: dns-wg-admin at ripe.net [mailto:dns-wg-admin at ripe.net] En > nombre de Jim Reid > Enviado el: mi?rcoles, 22 de septiembre de 2004 13:36 > Para: Brad Knowles > CC: Fernando Garcia; dns-wg at ripe.net > Asunto: Re: [dns-wg] DNS migration draft - new version > > 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. >