From Daniel.Karrenberg at ripe.net Tue Nov 5 08:33:24 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 05 Nov 2002 08:33:24 +0100 Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <004a01c2845c$c506f3a0$5d2300c0@VAIO> References: <002401c28459$8b1414a0$5d2300c0@VAIO> Message-ID: <4.3.2.7.2.20021105083039.02f657e8@localhost.ripe.net> Also note that a hints file change is ***not required***. You can do that anytime within the next -say- 5 **years** or so. Your DNS will continue to work as long as there is at least one valid root server address in the hints file. Daniel From crain at icann.org Tue Nov 5 00:49:08 2002 From: crain at icann.org (John Crain) Date: Mon, 4 Nov 2002 15:49:08 -0800 Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <002401c28459$8b1414a0$5d2300c0@VAIO> Message-ID: <004a01c2845c$c506f3a0$5d2300c0@VAIO> Please note that ftp.internic.net:/doamin/named.root Should read ftp.internic.net:/domain/named.root Not enough coffee today JC > -----Original Message----- > From: lir-wg-admin at ripe.net [mailto:lir-wg-admin at ripe.net] On > Behalf Of John Crain > Sent: Monday, November 04, 2002 3:26 PM > To: RIPE DNS WG; RIPE LIR WG > Subject: [lir-wg] Important Informational Message - root.zone change > > > > > *** PGP Signature Status: good > *** Signer: John Crain > *** Signed: 11/4/2002 3:25:47 PM > *** Verified: 11/4/2002 3:45:39 PM > *** BEGIN PGP VERIFIED MESSAGE *** > > *****PLEASE NOTE***** > This is an important Informational Message to the internet community: > > November 5, 2002, the IP address for J.root-servers.net will > change in the authoritative NS set for "dot". The change will > be reflected in zone serial # 2002110501. > > The new set of servers authoritative for "dot" will be: > A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 > H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 > C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 > G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 > F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 > B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 > J.ROOT-SERVERS.NET. 5w6d16h IN A 192.58.128.30 > K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 > L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 > M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 > I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 > E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 > D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 > > This WILL require a change to your root hints file. The new > file will be available via anonymous ftp from > rs.internic.net:/domain/named.root as well as > ftp.internic.net:/doamin/named.root starting 11/5/02 1700UTC > (12pm EST/9am PST). > > Both the new and old j.root-servers.net IP space will provide > answers in parallel for the foreseeable future. > > _________________________________________ > > John Crain > Manager of Technical Operations > ICANN/IANA > > crain at icann.org > 1AF4 F638 4B2D 3EF2 F9BA 99E4 8D85 69A7 > > _________________________________________ > > > *** END PGP VERIFIED MESSAGE *** > From pk at TechFak.Uni-Bielefeld.DE Tue Nov 5 12:22:49 2002 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 05 Nov 2002 12:22:49 +0100 Subject: Important Informational Message - root.zone change In-Reply-To: Your message of "Tue, 05 Nov 2002 08:33:24 +0100." <4.3.2.7.2.20021105083039.02f657e8@localhost.ripe.net> Message-ID: <200211051122.gA5BMnY27626@grimsvotn.TechFak.Uni-Bielefeld.DE> > Your DNS will continue to work as long as there is at least > one valid root server address in the hints file. This is true as long as the old IP address is taken out of service, i.e. doesn't answer "." DNS queries at all or - as in this case - continues to serve the "right" NS RRSet. And, the ftp copy is not necessary, because "dig @${X}.root-servers.net. . ns" does the job (for $X in A .. M) - unless you trust the DNS less than you trust ftp - after the "root-servers.net" zone will have been updated. -Peter From Daniel.Karrenberg at ripe.net Tue Nov 5 13:12:22 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 05 Nov 2002 13:12:22 +0100 Subject: Distributing K-Root Service by Anycast Routing Message-ID: <4.3.2.7.2.20021105130422.03074ed0@localhost.ripe.net> Dear Colleagues, below you find the proposal to start distributing the service of k.root-servers.net by using anycast. I welcome comments and suggestions either privately or on the DNS WG list. I would like to see a good discussion so that we can proceed with support from the RIPE community. Can we have this discussion on the DNS WG list too please? In particular I would like to hear technical suggestions for Appendix A. Thanks Daniel --------- Distributing K-Root Service by Anycast Routing of 193.0.14.129 Daniel Karrenberg $Id: k-any.ms,v 1.9 2002/11/05 12:03:32 dfk Exp $ ABSTRACT This memo proposes to distribute the DNS ser- vice provided by k.root-servers.net across multi- ple locations in the Internet topology. It dis- cusses the motivation for and the principles of implementation. A first inventory of detailed issues is provided in an appendix. 1. Introduction DNS root name servers need to be accessible by Internet hosts in order for the DNS to function properly. Accessi- bility is determined by the ability of the server to handle a given query load and by the connectivity of the server to the rest of the Internet. The RIPE NCC operates k.root-servers.net (K-root) in the RIPE region in order to help safeguard the quality of the DNS in the Internet and in the RIPE region in particular. The RIPE NCC obtains guidance from RIPE. For K-root the connectivity issue has been addressed by placing it at the LINX, a topologically very well connected point. The server load issue has been addressed by deploy- ing successive generations of hardware with increased pro- cessing power and by distributing the load locally among a number of machines at different LINX sites. A cold spare system has been available in Amsterdam at all times to pro- vide continuity in case of catastrophic failures at the pri- mary server location. Over the years this set-up has pro- vided very reliable service. However issues about differences in connectivity to the ser- vice across the RIPE region have been raised repeatedly. A more distributed provision of the service is generally seen as positive because of - lower network delays due to shorter paths between clients and servers, - less dependence on connectivity to a single location, - better load and DDoS attack resiliance because of dis- tributed servers, - more overall redundancy. For these reasons numerous organisations have offered to host additional servers operated by the RIPE NCC. So far this has not been considered because the number of unique IP addresses at which the service can be provided is exhausted by currently assigned servers. 2. Scope of this Memo This memo proposes to deploy multiple servers providing k.root-servers.net name service across the RIPE region, each using the same IP address. This is commonly called 'any- casting'. A detailed description of one implementation can be found in RFC3258. The intention of this memo is to establish the principles of this, inventarise the major issues and request comments from the RIPE community and other interested parties. An initial inventory of detailed issues is provided as an appendix. 3. Proposal Simply put the RIPE NCC will provide K-root name service at multiple locations dispersed over the Internet topology but at the same IP address. No DNS client/resolver changes are necessary. The service will appear exactly the same for the users. Normal Internet routing will distribute the traffic among the different instances of K-root. This will be implemented by installing multiple copies of the current server sets at different points and announcing the current prefix 193.0.14/24 from these points. The main challenge with this set-up is to ensure consis- tency: operation - All servers will be operated in a consistent way by the RIPE NCC. They will have appropriate out-of-band access path to ensure that the operations centre can access them. monitoring - The availability and responses will be monitored by dedicated monitoring systems installed at multiple locations. Also the BGP propagation of the prefix 193.0.14/24 will be monitored constantly by the exist- ing remote route collectors. [http://www.ripe.net/ris] Users will be able to identify the particular instance they are using by published methods using DNS queries. [draft-ietf-dnsop-serverid] correctness - The correctness and authenticity of the root zone data will eventually be guaranteed using DNSSEC. Until this can be deployed the current method will need to be employed: ISPs will need to closely monitor where they route traffic to 193.0.14/24 and from where they accept traffic from that address. The RIPE NCC will publish and maintain a list with the locations of the k-root instances, the BGP autonomous system numbers of their immediate neighbors and any other information that can help ISPs and others to ensure that they reach an authentic instance of K-root. This list will be main- tained until appropriate routing security technology is widely deployed. The RIPE NCC and K-root itself are well suited for this mode of operation. IANA asked the RIPE NCC to operate K-root, the geographic and topological location of K-root was not specified in any way other than "somewhere in the RIPE region". The RIPE NCC was chosen because it is neutral and professional but above all directly accountable to RIPE and its membership. The location at the LINX was subsequently chosen based on evaluation of the Internet topology in the region and a rec- ommendation by the RIPE DNS working group. Distributing K- root over a number of places is a natural continuation of this policy. In addition to operating K-root at a remote location the RIPE NCC has considerable experience in operating dis- tributed services. The Test Traffic Measurements Service operates more than 80 machines all over the world to collect performance measurements. Some of these can be used to mon- itor the DNS service of K-root as well. The Routing Infor- mation Service operates 9 remote route collectors at exchange points all over the world to collect BGP routing information. These route collectors will be used to monitor the routing of 193.0.14/24. At any point in time there is a trade-off between the added benefit of adding more servers and the difficulty of operat- ing them consistently. The optimal number of servers depends on a large number of constantly changing factors. It needs to be evaluated continuously as things progress. 4. Operational & Funding Models For the purpose of stability and for gaining experience all instances of K-root will be operated by the RIPE NCC. This ensures smooth transitions, consistency and correctness of root zone data. After the initial deployment there are a number of possible operational and funding models. 4.1. Traditional Traditionally K-root operations have been part of general RIPE NCC activities and thus have been collectively funded by the RIPE NCC membership. This is an appropriate funding model as all members benefit from stable root name service. It is also easy to administer. Difficulties may arise when the number of locations is such that the operational costs increase very significantly. Another important drawback of this model is that the number of additional sites will be limited by available funds and the sites will have to be determined by a selection procedure based on criteria including - position in Internet topology, - position relative to existing K-root instances, - local operations support, - operational requirements [rfc2870], - commitment to fund operations at a later stage. 4.2. Location Fees The drawbacks of the traditional model can be largely over- come by charging the organisations hosting K-root instances a fee that covers the operational costs. This obviously scales better and requires less of a beauty contest, because the funds available will more closely match the operational costs. It is quite possible that the initial demand will be higher than the operational capabilities of the RIPE NCC. Also it should be observed that in funding and some other aspects this is exactly the opposite of the traditional model: In the traditional model the RIPE NCC pays facilities management fees to the hosts whereas in this model the hosts pay. Transition should be planned carefully. 4.3. Operated and Funded Decentrally In this model anyone who wishes would be able to operate a K-root instance. This model has such serious problems with guaranteeing stability and consistency that it cannot be implemented today or in the near future. The minimum requirement for this operational mode is a zone signing mechanism that ensures consistency and authenticity of root zone data. Implementing this also requires a changed model of service responsibility as it is obviously impossible to hold any one entity responsible for the service. While this may ultimately scale the best, it is extremely premature at this point. We propose to continue with the traditional model for now and explore other models while gaining operational experi- ence. The associated selection procedures will be executed by the RIPE NCC and guided by the relevant requirements RFCs and the RIPE DNS working group. 5. Implementation Plan 5.1. Initial BGP change The routing announcements of the current server prefix 193.0.14/24 will change from AS5459 (LINX) to the dedicated new K-root autonomous system number AS25152. ISPs need to be aware of this and adapt their routing fil- ters accordingly. It is recommended that ISPs who do not already do so, take precautions, safeguaring that they receive this prefix from an authentic K-root via a trusted path and that they route traffic to it via trusted paths as far as possible. At the same time an initial set of BGP and DNS service monitors will be deployed. 5.2. Move the Cold Standby to Service The current cold standby server at the RIPE NCC will be activated as a regular server. AS25152 will be announced also by the RIPE NCC at the AMS-IX. As the server is already available and configured this can be done fairly rapidly. The distribution of the load, BGP routing informa- tion and other operational data will be gathered and evalu- ated. ISPs will have the opportunity to test this set-up and provide feedback. In case of problems the RIPE NCC instance of K-root will be deactivated quickly, returning to the previous service level. 5.3. Implement Further Instances While monitoring continuously a number of further instances of K-root will be deployed. Currently we expect this to be about 5 additional instances. This number is limited by operational and monitoring capacity. It is important not to deploy more instances than can safely be operated and moni- tored. Especially the capacity to detect and correct prob- lems in this distributed set-up needs to be carefully moni- tored. 5.4. Spreading Further Planning further than this is currently difficult because of lack of experience with distributed K-root operations and possible funding models. Acknowledgements The author would like to thank Joao Silva Damas for comments on an earlier draft as well as Andrei Robachevsky and Henk Uijterwaal who provided comments on recent drafts. Appendix A - Detailed Issues Using a router or having a server speak BGP? Withdrawing BGP announcements based on service availability? Distributed service monitoring: Using current RIPE NCC oper- ated machines all over the world is an easy option. Maybe distributing automatic monitoring software to be run by vol- unteers is another. What is essentially needed is to try a small number of queries periodically including the query identifying the instance of the server. Then transmitting the results back to a (set of) collection point(s). Distributed BGP Monitoring: The RIS can be used for this. Coverage should be sufficient. Information Campaign: What is needed to reach all ISPs that need to know? How long a lead time do they need for the var- ious stages of the deployment? From JimFleming at ameritech.net Tue Nov 5 13:33:57 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 06:33:57 -0600 Subject: Distributing K-Root Service by Anycast Routing References: <4.3.2.7.2.20021105130422.03074ed0@localhost.ripe.net> Message-ID: <0ab101c284c7$9cc96d80$c7b22443@repligate> Note, with BGP taken out of the picture in the Next Generation Internet Plan. The proposal below does not work as easily, or will be hidden behind the GovNet curtains.... Whitehouse Ready to Release Next Generation Internet Plan http://news.com.com/2100-1023-958159.html?tag=politech http://www.politechbot.com/p-03994.html http://www.uscryptomail.org/cybersecurity/ Note: The new plan calls for the same architecture used with IPv8 and IPv16, whereby, users do not have direct access to the (out-of-band) IPv16 network. ----- Original Message ----- From: "Daniel Karrenberg" To: "RIPE DNS WG" Cc: "RIPE Routing WG" Sent: Tuesday, November 05, 2002 6:12 AM Subject: Distributing K-Root Service by Anycast Routing > Dear Colleagues, > > below you find the proposal to start distributing the service > of k.root-servers.net by using anycast. I welcome comments > and suggestions either privately or on the DNS WG list. > I would like to see a good discussion so that we can proceed > with support from the RIPE community. Can we have this > discussion on the DNS WG list too please? In particular > I would like to hear technical suggestions for Appendix A. > > Thanks > > Daniel > > > --------- > > > > > > Distributing K-Root Service by Anycast Routing of > 193.0.14.129 > > > Daniel Karrenberg > > > $Id: k-any.ms,v 1.9 2002/11/05 12:03:32 dfk Exp $ > > > > ABSTRACT > > > This memo proposes to distribute the DNS ser- > vice provided by k.root-servers.net across multi- > ple locations in the Internet topology. It dis- > cusses the motivation for and the principles of > implementation. A first inventory of detailed > issues is provided in an appendix. > > > > 1. Introduction > > DNS root name servers need to be accessible by Internet > hosts in order for the DNS to function properly. Accessi- > bility is determined by the ability of the server to handle > a given query load and by the connectivity of the server to > the rest of the Internet. > > The RIPE NCC operates k.root-servers.net (K-root) in the > RIPE region in order to help safeguard the quality of the > DNS in the Internet and in the RIPE region in particular. > The RIPE NCC obtains guidance from RIPE. > > For K-root the connectivity issue has been addressed by > placing it at the LINX, a topologically very well connected > point. The server load issue has been addressed by deploy- > ing successive generations of hardware with increased pro- > cessing power and by distributing the load locally among a > number of machines at different LINX sites. A cold spare > system has been available in Amsterdam at all times to pro- > vide continuity in case of catastrophic failures at the pri- > mary server location. Over the years this set-up has pro- > vided very reliable service. > > However issues about differences in connectivity to the ser- > vice across the RIPE region have been raised repeatedly. A > more distributed provision of the service is generally seen > as positive because of > > - lower network delays due to shorter paths between > clients and servers, > > - less dependence on connectivity to a single location, > > - better load and DDoS attack resiliance because of dis- > tributed servers, > > - more overall redundancy. > > > For these reasons numerous organisations have offered to > host additional servers operated by the RIPE NCC. So far > this has not been considered because the number of unique IP > addresses at which the service can be provided is exhausted > by currently assigned servers. > > > 2. Scope of this Memo > > This memo proposes to deploy multiple servers providing > k.root-servers.net name service across the RIPE region, each > using the same IP address. This is commonly called 'any- > casting'. A detailed description of one implementation can > be found in RFC3258. The intention of this memo is to > establish the principles of this, inventarise the major > issues and request comments from the RIPE community and > other interested parties. An initial inventory of detailed > issues is provided as an appendix. > > > 3. Proposal > > Simply put the RIPE NCC will provide K-root name service at > multiple locations dispersed over the Internet topology but > at the same IP address. No DNS client/resolver changes are > necessary. The service will appear exactly the same for the > users. Normal Internet routing will distribute the traffic > among the different instances of K-root. > > This will be implemented by installing multiple copies of > the current server sets at different points and announcing > the current prefix 193.0.14/24 from these points. > > The main challenge with this set-up is to ensure consis- > tency: > > > operation - > All servers will be operated in a consistent way by the > RIPE NCC. They will have appropriate out-of-band > access path to ensure that the operations centre can > access them. > > > monitoring - > The availability and responses will be monitored by > dedicated monitoring systems installed at multiple > locations. Also the BGP propagation of the prefix > 193.0.14/24 will be monitored constantly by the exist- > ing remote route collectors. [http://www.ripe.net/ris] > Users will be able to identify the particular instance > they are using by published methods using DNS queries. > [draft-ietf-dnsop-serverid] > > > correctness - > The correctness and authenticity of the root zone data > will eventually be guaranteed using DNSSEC. Until this > can be deployed the current method will need to be > employed: ISPs will need to closely monitor where they > route traffic to 193.0.14/24 and from where they accept > traffic from that address. The RIPE NCC will publish > and maintain a list with the locations of the k-root > instances, the BGP autonomous system numbers of their > immediate neighbors and any other information that can > help ISPs and others to ensure that they reach an > authentic instance of K-root. This list will be main- > tained until appropriate routing security technology is > widely deployed. > > > > The RIPE NCC and K-root itself are well suited for this mode > of operation. IANA asked the RIPE NCC to operate K-root, > the geographic and topological location of K-root was not > specified in any way other than "somewhere in the RIPE > region". The RIPE NCC was chosen because it is neutral and > professional but above all directly accountable to RIPE and > its membership. > > The location at the LINX was subsequently chosen based on > evaluation of the Internet topology in the region and a rec- > ommendation by the RIPE DNS working group. Distributing K- > root over a number of places is a natural continuation of > this policy. > > In addition to operating K-root at a remote location the > RIPE NCC has considerable experience in operating dis- > tributed services. The Test Traffic Measurements Service > operates more than 80 machines all over the world to collect > performance measurements. Some of these can be used to mon- > itor the DNS service of K-root as well. The Routing Infor- > mation Service operates 9 remote route collectors at > exchange points all over the world to collect BGP routing > information. These route collectors will be used to monitor > the routing of 193.0.14/24. > > > At any point in time there is a trade-off between the added > benefit of adding more servers and the difficulty of operat- > ing them consistently. The optimal number of servers > depends on a large number of constantly changing factors. > It needs to be evaluated continuously as things progress. > > > 4. Operational & Funding Models > > > For the purpose of stability and for gaining experience all > instances of K-root will be operated by the RIPE NCC. This > ensures smooth transitions, consistency and correctness of > root zone data. > > After the initial deployment there are a number of possible > operational and funding models. > > > 4.1. Traditional > > Traditionally K-root operations have been part of general > RIPE NCC activities and thus have been collectively funded > by the RIPE NCC membership. This is an appropriate funding > model as all members benefit from stable root name service. > It is also easy to administer. Difficulties may arise when > the number of locations is such that the operational costs > increase very significantly. Another important drawback of > this model is that the number of additional sites will be > limited by available funds and the sites will have to be > determined by a selection procedure based on criteria > including > > - position in Internet topology, > > - position relative to existing K-root instances, > > - local operations support, > > - operational requirements [rfc2870], > > - commitment to fund operations at a later stage. > > > > 4.2. Location Fees > > The drawbacks of the traditional model can be largely over- > come by charging the organisations hosting K-root instances > a fee that covers the operational costs. This obviously > scales better and requires less of a beauty contest, because > the funds available will more closely match the operational > costs. It is quite possible that the initial demand will be > higher than the operational capabilities of the RIPE NCC. > > Also it should be observed that in funding and some other > aspects this is exactly the opposite of the traditional > model: In the traditional model the RIPE NCC pays facilities > management fees to the hosts whereas in this model the hosts > pay. > > Transition should be planned carefully. > > > 4.3. Operated and Funded Decentrally > > In this model anyone who wishes would be able to operate a > K-root instance. This model has such serious problems with > guaranteeing stability and consistency that it cannot be > implemented today or in the near future. The minimum > requirement for this operational mode is a zone signing > mechanism that ensures consistency and authenticity of root > zone data. Implementing this also requires a changed model > of service responsibility as it is obviously impossible to > hold any one entity responsible for the service. While this > may ultimately scale the best, it is extremely premature at > this point. > > > We propose to continue with the traditional model for now > and explore other models while gaining operational experi- > ence. The associated selection procedures will be executed > by the RIPE NCC and guided by the relevant requirements RFCs > and the RIPE DNS working group. > > > > 5. Implementation Plan > > > > 5.1. Initial BGP change > > The routing announcements of the current server prefix > 193.0.14/24 will change from AS5459 (LINX) to the dedicated > new K-root autonomous system number AS25152. > > ISPs need to be aware of this and adapt their routing fil- > ters accordingly. It is recommended that ISPs who do not > already do so, take precautions, safeguaring that they > receive this prefix from an authentic K-root via a trusted > path and that they route traffic to it via trusted paths as > far as possible. At the same time an initial set of BGP and > DNS service monitors will be deployed. > > > 5.2. Move the Cold Standby to Service > > The current cold standby server at the RIPE NCC will be > activated as a regular server. AS25152 will be announced > also by the RIPE NCC at the AMS-IX. As the server is > already available and configured this can be done fairly > rapidly. The distribution of the load, BGP routing informa- > tion and other operational data will be gathered and evalu- > ated. ISPs will have the opportunity to test this set-up > and provide feedback. In case of problems the RIPE NCC > instance of K-root will be deactivated quickly, returning to > the previous service level. > > > 5.3. Implement Further Instances > > While monitoring continuously a number of further instances > of K-root will be deployed. Currently we expect this to be > about 5 additional instances. This number is limited by > operational and monitoring capacity. It is important not to > deploy more instances than can safely be operated and moni- > tored. Especially the capacity to detect and correct prob- > lems in this distributed set-up needs to be carefully moni- > tored. > > > 5.4. Spreading Further > > Planning further than this is currently difficult because of > lack of experience with distributed K-root operations and > possible funding models. > > > Acknowledgements > > The author would like to thank Joao Silva Damas for comments > on an earlier draft as well as Andrei Robachevsky and Henk > Uijterwaal who provided comments on recent drafts. > > > > Appendix A - Detailed Issues > > Using a router or having a server speak BGP? > > Withdrawing BGP announcements based on service availability? > > Distributed service monitoring: Using current RIPE NCC oper- > ated machines all over the world is an easy option. Maybe > distributing automatic monitoring software to be run by vol- > unteers is another. What is essentially needed is to try a > small number of queries periodically including the query > identifying the instance of the server. Then transmitting > the results back to a (set of) collection point(s). > > Distributed BGP Monitoring: The RIS can be used for this. > Coverage should be sufficient. > > Information Campaign: What is needed to reach all ISPs that > need to know? How long a lead time do they need for the var- > ious stages of the deployment? > From bmanning at ISI.EDU Tue Nov 5 14:43:01 2002 From: bmanning at ISI.EDU (Bill Manning) Date: Tue, 5 Nov 2002 05:43:01 -0800 (PST) Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <4.3.2.7.2.20021105083039.02f657e8@localhost.ripe.net> from Daniel Karrenberg at "Nov 5, 2 08:33:24 am" Message-ID: <200211051343.gA5Dh1Z10519@boreas.isi.edu> % Also note that a hints file change is ***not required***. % You can do that anytime within the next -say- 5 **years** or so. % Your DNS will continue to work as long as there is at least % one valid root server address in the hints file. % % Daniel not required -now- but it will be, eventually. to clarify the last statement, "...at least one reachable, valid..." as long as this announced change is fresh in your minds, it might be useful to make the changes in you live systems, then be on the lookout for any new systems deployed in the next few years as it will nessasary to fix them as well (since they are already in the "channel" and will have stale data.) in general, this is not a make/break situation. there is no flag day. folks can even make the change before the "insertion" day and still be functional. -- --bill From JimFleming at ameritech.net Tue Nov 5 14:54:37 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 07:54:37 -0600 Subject: [lir-wg] Important Informational Message - root.zone change References: <200211051343.gA5Dh1Z10519@boreas.isi.edu> Message-ID: <0b3d01c284d2$e1bc2e40$c7b22443@repligate> Now that UltraDNS and others have been selected to run .ORG[Y]... http://www.ultradns.com/about/advisors.html Dr. Dave Farber Bill Manning http://www.arin.net/about_us/ab_org_bot.html Bill Manning http://www.iana.org/assignments/ipv4-address-space ================================= How is the .ORG[Y] $6 per domain per year divided between all of the various people ? ----- Original Message ----- From: "Bill Manning" To: "Daniel Karrenberg" Cc: ; ; Sent: Tuesday, November 05, 2002 7:43 AM Subject: Re: [lir-wg] Important Informational Message - root.zone change > % Also note that a hints file change is ***not required***. > % You can do that anytime within the next -say- 5 **years** or so. > % Your DNS will continue to work as long as there is at least > % one valid root server address in the hints file. > % > % Daniel > > not required -now- but it will be, eventually. > to clarify the last statement, "...at least one > reachable, valid..." > > as long as this announced change is fresh in your > minds, it might be useful to make the changes in > you live systems, then be on the lookout for > any new systems deployed in the next few years > as it will nessasary to fix them as well (since > they are already in the "channel" and will have > stale data.) > > in general, this is not a make/break situation. > there is no flag day. folks can even make the change > before the "insertion" day and still be functional. > > > -- > --bill From JimFleming at ameritech.net Tue Nov 5 17:50:31 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 10:50:31 -0600 Subject: [lir-wg] Important Informational Message - root.zone change References: <000701c284ea$272b7b90$6701a8c0@VAIO> Message-ID: <0c2b01c284eb$7424e070$c7b22443@repligate> Modern DNS software does all that automatically. People do not have to touch it. Manual operations are expensive, prone to error and require humans to fly around in meat space explaining how things do not work. It is better to build a NetWork. Jim Fleming 128-bit DNS is closer than you think... COM...DE...NET...ORG...INFO...BIZ...US http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au ----- Original Message ----- From: "John Crain" To: "'Daniel Karrenberg'" Cc: "'RIPE DNS WG'" ; "'RIPE LIR WG'" Sent: Tuesday, November 05, 2002 10:41 AM Subject: RE: [lir-wg] Important Informational Message - root.zone change This is of course true, but it doesn't mean you should wait 5 years. Not updating you hints is not going to cause you any grief but it is good practice to keep it up to date when it changes. JC > -----Original Message----- > From: lir-wg-admin at ripe.net [mailto:lir-wg-admin at ripe.net] On > Behalf Of Daniel Karrenberg > Sent: Monday, November 04, 2002 11:33 PM > To: John Crain > Cc: 'RIPE DNS WG'; 'RIPE LIR WG' > Subject: RE: [lir-wg] Important Informational Message - > root.zone change > > > Also note that a hints file change is ***not required***. > You can do that anytime within the next -say- 5 **years** or > so. Your DNS will continue to work as long as there is at > least one valid root server address in the hints file. > > Daniel > From Niall.oReilly at ucd.ie Tue Nov 5 18:00:04 2002 From: Niall.oReilly at ucd.ie (Niall.oReilly at ucd.ie) Date: Tue, 05 Nov 2002 17:00:04 +0000 Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: Message from John Crain "of Tue, 05 Nov 2002 08:41:11 PST." <000701c284ea$272b7b90$6701a8c0@VAIO> Message-ID: <0H5405UME4K5VZ@Salicet.ucd.ie> > This is of course true, but it doesn't mean you should wait 5 years. > > Not updating you hints is not going to cause you any grief but it is > good practice to keep it > up to date when it changes. > > JC Indeed. I always prefer to deal early with 5-year time bombs! 8-) Niall From JimFleming at ameritech.net Tue Nov 5 18:13:52 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 11:13:52 -0600 Subject: [lir-wg] Important Informational Message - root.zone change References: <0H5405UME4K5VZ@Salicet.ucd.ie> Message-ID: <0c4e01c284ee$b78c66f0$c7b22443@repligate> ----- Original Message ----- From: To: "John Crain" Cc: "'RIPE DNS WG'" ; "'RIPE LIR WG'" Sent: Tuesday, November 05, 2002 11:00 AM Subject: Re: [lir-wg] Important Informational Message - root.zone change > > This is of course true, but it doesn't mean you should wait 5 years. > > > > Not updating you hints is not going to cause you any grief but it is > > good practice to keep it > > up to date when it changes. > > > > JC > > Indeed. I always prefer to deal early with 5-year time bombs! 8-) > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 3:119 IE (IRELAND) Don't worry, it does not take 5 years for the new DNS software to remove your TLD. With no IN-ADDR.IE zone, it is easy to spot the ones slated to be phased out. http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=in-addr.ie&Type=255&submit=Lookup With so few "slots" open in the legacy root servers, only a limited number of TLDs can be supported. Jim Fleming 128-bit DNS is closer than you think... COM...DE...NET...ORG...INFO...BIZ...US...ONLINE http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au From JimFleming at ameritech.net Tue Nov 5 19:03:39 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 12:03:39 -0600 Subject: [lir-wg] Important Informational Message - root.zone change References: <0H5405UME4K5VZ@Salicet.ucd.ie> <0c4e01c284ee$b78c66f0$c7b22443@repligate> <20021105174107.GF27832@marowsky-bree.de> Message-ID: <0c6e01c284f5$abaad9f0$c7b22443@repligate> ----- Original Message ----- From: "Lars Marowsky-Bree" To: "Jim Fleming" Cc: "'RIPE DNS WG'" ; "'RIPE LIR WG'" Sent: Tuesday, November 05, 2002 11:41 AM Subject: Re: [lir-wg] Important Informational Message - root.zone change > On 2002-11-05T11:13:52, > Jim Fleming said: > > > With no IN-ADDR.IE zone, it is easy to spot the ones slated to be phased > > out. > > http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=in-addr.ie&Type=255&submit=Lookup > > > > With so few "slots" open in the legacy root servers, only a limited number > > of TLDs can be supported. > > Can you translate that to English please? > "Experts" have apparently been paid (or had their arms twisted) to lie to the U.S. Government and tell them that the 32-bit legacy root servers are under attack, are over-loaded, etc. and can only handle a limited number of TLDs. That of course has been orchestrated by the lobbyists who do not want more TLDs, for obvious reasons. Since obviously it is easy to show an ASCII zone file to any clueless politician and explain how it can have a lot of entries, the "experts" turn to the operational mysteries of the DNS and claim the sky will fall if the roots are over-loaded with "traffic" resulting from new TLDs. Given that things are working, it is hard for the experts to claim that a couple hundred TLDs do not work. 256 is a good number at the moment. Of course, as the need arises to have less and less TLDs, because of the fictitious load and operational concerns, that 256 will have to be reduced, as existing TLDs are removed. The same mentality can of course be used to show that ultimately, only one operating system can be supported or only one computer language. The lobbyists will not likely stop until they have reduced the TLDs to something they can understand and control. Starting at 256 it might seem that they would work down one by one. It seems more likely with the current climate that they would go for broke and declare that only TLDs with signed contracts can remain. Certainly, signed contracts, and $1 per domain, per year, fees will help to make those operational and load concerns vanish. It looks like there are less than 32 TLDs with signed contracts and money flowing to the right people. What 32 TLDs do you think should be in the legacy root servers ? Jim Fleming 128-bit DNS is closer than you think... COM...DE...NET...ORG...INFO...BIZ...US...ONLINE http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au From JimFleming at ameritech.net Tue Nov 5 19:25:56 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Tue, 5 Nov 2002 12:25:56 -0600 Subject: [lir-wg] Important Informational Message - root.zone change References: <0H5405UME4K5VZ@Salicet.ucd.ie> <0c4e01c284ee$b78c66f0$c7b22443@repligate> <20021105174107.GF27832@marowsky-bree.de> Message-ID: <0ca601c284f8$c8aaae60$c7b22443@repligate> ----- Original Message ----- From: "Lars Marowsky-Bree" > > > > With so few "slots" open in the legacy root servers, only a limited number > > of TLDs can be supported. > > Can you translate that to English please? > By the way, there are other solutions to the aging legacy 32-bit roots. One solution is to have PKs and GKs point directly to the TLD Clusters. Some top-down-mentality-thinkers can not grasp how that could work. For them, a modified version of the no-root approach is to have "the root" formed by selected "Seed TLDs", and then those TLD Clusters can be queried about the location of other TLD Clusters. You can visualize it as a ring, where in this example, COM and ONLINE are next to each other. Each TLD below, contributes a Cluster of servers. All of the servers in all of these TLDs could be viewed as "the root"... COM...DE...NET...ORG...INFO...BIZ...US...ONLINE Jim Fleming 128-bit DNS is closer than you think... http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au From marc at schneiders.org Wed Nov 6 00:11:52 2002 From: marc at schneiders.org (Marc Schneiders) Date: Wed, 6 Nov 2002 00:11:52 +0100 (CET) Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <0H5405UME4K5VZ@Salicet.ucd.ie> Message-ID: <20021106001040.H38048-100000@voo.doo.net> On Tue, 5 Nov 2002, at 17:00 [=GMT-0000], Niall.oReilly at ucd.ie wrote: > > This is of course true, but it doesn't mean you should wait 5 years. > > > > Not updating you hints is not going to cause you any grief but it is > > good practice to keep it > > up to date when it changes. > > > > JC > > Indeed. I always prefer to deal early with 5-year time bombs! 8-) Secondary root from one of the few root-servers.net that allow axfr? f (Vixie) does. One or two others too. From crain at icann.org Tue Nov 5 17:41:11 2002 From: crain at icann.org (John Crain) Date: Tue, 5 Nov 2002 08:41:11 -0800 Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <4.3.2.7.2.20021105083039.02f657e8@localhost.ripe.net> Message-ID: <000701c284ea$272b7b90$6701a8c0@VAIO> This is of course true, but it doesn't mean you should wait 5 years. Not updating you hints is not going to cause you any grief but it is good practice to keep it up to date when it changes. JC > -----Original Message----- > From: lir-wg-admin at ripe.net [mailto:lir-wg-admin at ripe.net] On > Behalf Of Daniel Karrenberg > Sent: Monday, November 04, 2002 11:33 PM > To: John Crain > Cc: 'RIPE DNS WG'; 'RIPE LIR WG' > Subject: RE: [lir-wg] Important Informational Message - > root.zone change > > > Also note that a hints file change is ***not required***. > You can do that anytime within the next -say- 5 **years** or > so. Your DNS will continue to work as long as there is at > least one valid root server address in the hints file. > > Daniel > From jwkckid1 at ix.netcom.com Wed Nov 6 03:04:29 2002 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 05 Nov 2002 18:04:29 -0800 Subject: [ga] More Root-Servers? References: <20021106002246.H38048-100000@voo.doo.net> Message-ID: <3DC878AB.4708FC5C@ix.netcom.com> Marc, Daniel, and all assembly members, stakeholders or other interested parties, It would seem more logical to fix the protocol to allow for more Root servers than to use Anycast to piggyback additional Root servers. Even better would be a SROOTS or MultiRoot structure. But of course ICANN is strongly against that... :( None the less, Bind 9.0+ has been modified in our [INEG. INC] version to allow for up to 255 root servers. We call this fix or improved/inhanced version, BindPlus, and have been quietly deploying it for some time now.. I do believe that Anycast or Multicast can and has been tested a number of times to be used for linking/stacking of Root servers under existing Bind restrictions. One might consider asking Paul Vixie about some of this if I recall correctly. Marc Schneiders wrote: > Yesterday suggestions were made here for placing root-servers more > geographically spread around the world. The problem is that 13 is > the maximum. > > Below an idea that RIPE (which operates K) is considering. In short: > there would be several machines with the same IP number in different > places using anycast. So there would in fact be more root-servers that > appear to be just one of the 13. > > ---------- Forwarded message ---------- > Date: Tue, 05 Nov 2002 13:12:22 +0100 > From: Daniel Karrenberg > To: RIPE DNS WG > Cc: RIPE Routing WG > Subject: Distributing K-Root Service by Anycast Routing > > Dear Colleagues, > > below you find the proposal to start distributing the service > of k.root-servers.net by using anycast. I welcome comments > and suggestions either privately or on the DNS WG list. > I would like to see a good discussion so that we can proceed > with support from the RIPE community. Can we have this > discussion on the DNS WG list too please? In particular > I would like to hear technical suggestions for Appendix A. > > Thanks > > Daniel > > --------- > > Distributing K-Root Service by Anycast Routing of > 193.0.14.129 > > Daniel Karrenberg > > > $Id: k-any.ms,v 1.9 2002/11/05 12:03:32 dfk Exp $ > > ABSTRACT > > This memo proposes to distribute the DNS ser- > vice provided by k.root-servers.net across multi- > ple locations in the Internet topology. It dis- > cusses the motivation for and the principles of > implementation. A first inventory of detailed > issues is provided in an appendix. > > 1. Introduction > > DNS root name servers need to be accessible by Internet > hosts in order for the DNS to function properly. Accessi- > bility is determined by the ability of the server to handle > a given query load and by the connectivity of the server to > the rest of the Internet. > > The RIPE NCC operates k.root-servers.net (K-root) in the > RIPE region in order to help safeguard the quality of the > DNS in the Internet and in the RIPE region in particular. > The RIPE NCC obtains guidance from RIPE. > > For K-root the connectivity issue has been addressed by > placing it at the LINX, a topologically very well connected > point. The server load issue has been addressed by deploy- > ing successive generations of hardware with increased pro- > cessing power and by distributing the load locally among a > number of machines at different LINX sites. A cold spare > system has been available in Amsterdam at all times to pro- > vide continuity in case of catastrophic failures at the pri- > mary server location. Over the years this set-up has pro- > vided very reliable service. > > However issues about differences in connectivity to the ser- > vice across the RIPE region have been raised repeatedly. A > more distributed provision of the service is generally seen > as positive because of > > - lower network delays due to shorter paths between > clients and servers, > > - less dependence on connectivity to a single location, > > - better load and DDoS attack resiliance because of dis- > tributed servers, > > - more overall redundancy. > > For these reasons numerous organisations have offered to > host additional servers operated by the RIPE NCC. So far > this has not been considered because the number of unique IP > addresses at which the service can be provided is exhausted > by currently assigned servers. > > 2. Scope of this Memo > > This memo proposes to deploy multiple servers providing > k.root-servers.net name service across the RIPE region, each > using the same IP address. This is commonly called 'any- > casting'. A detailed description of one implementation can > be found in RFC3258. The intention of this memo is to > establish the principles of this, inventarise the major > issues and request comments from the RIPE community and > other interested parties. An initial inventory of detailed > issues is provided as an appendix. > > 3. Proposal > > Simply put the RIPE NCC will provide K-root name service at > multiple locations dispersed over the Internet topology but > at the same IP address. No DNS client/resolver changes are > necessary. The service will appear exactly the same for the > users. Normal Internet routing will distribute the traffic > among the different instances of K-root. > > This will be implemented by installing multiple copies of > the current server sets at different points and announcing > the current prefix 193.0.14/24 from these points. > > The main challenge with this set-up is to ensure consis- > tency: > > operation - > All servers will be operated in a consistent way by the > RIPE NCC. They will have appropriate out-of-band > access path to ensure that the operations centre can > access them. > > monitoring - > The availability and responses will be monitored by > dedicated monitoring systems installed at multiple > locations. Also the BGP propagation of the prefix > 193.0.14/24 will be monitored constantly by the exist- > ing remote route collectors. [http://www.ripe.net/ris] > Users will be able to identify the particular instance > they are using by published methods using DNS queries. > [draft-ietf-dnsop-serverid] > > correctness - > The correctness and authenticity of the root zone data > will eventually be guaranteed using DNSSEC. Until this > can be deployed the current method will need to be > employed: ISPs will need to closely monitor where they > route traffic to 193.0.14/24 and from where they accept > traffic from that address. The RIPE NCC will publish > and maintain a list with the locations of the k-root > instances, the BGP autonomous system numbers of their > immediate neighbors and any other information that can > help ISPs and others to ensure that they reach an > authentic instance of K-root. This list will be main- > tained until appropriate routing security technology is > widely deployed. > > The RIPE NCC and K-root itself are well suited for this mode > of operation. IANA asked the RIPE NCC to operate K-root, > the geographic and topological location of K-root was not > specified in any way other than "somewhere in the RIPE > region". The RIPE NCC was chosen because it is neutral and > professional but above all directly accountable to RIPE and > its membership. > > The location at the LINX was subsequently chosen based on > evaluation of the Internet topology in the region and a rec- > ommendation by the RIPE DNS working group. Distributing K- > root over a number of places is a natural continuation of > this policy. > > In addition to operating K-root at a remote location the > RIPE NCC has considerable experience in operating dis- > tributed services. The Test Traffic Measurements Service > operates more than 80 machines all over the world to collect > performance measurements. Some of these can be used to mon- > itor the DNS service of K-root as well. The Routing Infor- > mation Service operates 9 remote route collectors at > exchange points all over the world to collect BGP routing > information. These route collectors will be used to monitor > the routing of 193.0.14/24. > > At any point in time there is a trade-off between the added > benefit of adding more servers and the difficulty of operat- > ing them consistently. The optimal number of servers > depends on a large number of constantly changing factors. > It needs to be evaluated continuously as things progress. > > 4. Operational & Funding Models > > For the purpose of stability and for gaining experience all > instances of K-root will be operated by the RIPE NCC. This > ensures smooth transitions, consistency and correctness of > root zone data. > > After the initial deployment there are a number of possible > operational and funding models. > > 4.1. Traditional > > Traditionally K-root operations have been part of general > RIPE NCC activities and thus have been collectively funded > by the RIPE NCC membership. This is an appropriate funding > model as all members benefit from stable root name service. > It is also easy to administer. Difficulties may arise when > the number of locations is such that the operational costs > increase very significantly. Another important drawback of > this model is that the number of additional sites will be > limited by available funds and the sites will have to be > determined by a selection procedure based on criteria > including > > - position in Internet topology, > > - position relative to existing K-root instances, > > - local operations support, > > - operational requirements [rfc2870], > > - commitment to fund operations at a later stage. > > 4.2. Location Fees > > The drawbacks of the traditional model can be largely over- > come by charging the organisations hosting K-root instances > a fee that covers the operational costs. This obviously > scales better and requires less of a beauty contest, because > the funds available will more closely match the operational > costs. It is quite possible that the initial demand will be > higher than the operational capabilities of the RIPE NCC. > > Also it should be observed that in funding and some other > aspects this is exactly the opposite of the traditional > model: In the traditional model the RIPE NCC pays facilities > management fees to the hosts whereas in this model the hosts > pay. > > Transition should be planned carefully. > > 4.3. Operated and Funded Decentrally > > In this model anyone who wishes would be able to operate a > K-root instance. This model has such serious problems with > guaranteeing stability and consistency that it cannot be > implemented today or in the near future. The minimum > requirement for this operational mode is a zone signing > mechanism that ensures consistency and authenticity of root > zone data. Implementing this also requires a changed model > of service responsibility as it is obviously impossible to > hold any one entity responsible for the service. While this > may ultimately scale the best, it is extremely premature at > this point. > > We propose to continue with the traditional model for now > and explore other models while gaining operational experi- > ence. The associated selection procedures will be executed > by the RIPE NCC and guided by the relevant requirements RFCs > and the RIPE DNS working group. > > 5. Implementation Plan > > 5.1. Initial BGP change > > The routing announcements of the current server prefix > 193.0.14/24 will change from AS5459 (LINX) to the dedicated > new K-root autonomous system number AS25152. > > ISPs need to be aware of this and adapt their routing fil- > ters accordingly. It is recommended that ISPs who do not > already do so, take precautions, safeguaring that they > receive this prefix from an authentic K-root via a trusted > path and that they route traffic to it via trusted paths as > far as possible. At the same time an initial set of BGP and > DNS service monitors will be deployed. > > 5.2. Move the Cold Standby to Service > > The current cold standby server at the RIPE NCC will be > activated as a regular server. AS25152 will be announced > also by the RIPE NCC at the AMS-IX. As the server is > already available and configured this can be done fairly > rapidly. The distribution of the load, BGP routing informa- > tion and other operational data will be gathered and evalu- > ated. ISPs will have the opportunity to test this set-up > and provide feedback. In case of problems the RIPE NCC > instance of K-root will be deactivated quickly, returning to > the previous service level. > > 5.3. Implement Further Instances > > While monitoring continuously a number of further instances > of K-root will be deployed. Currently we expect this to be > about 5 additional instances. This number is limited by > operational and monitoring capacity. It is important not to > deploy more instances than can safely be operated and moni- > tored. Especially the capacity to detect and correct prob- > lems in this distributed set-up needs to be carefully moni- > tored. > > 5.4. Spreading Further > > Planning further than this is currently difficult because of > lack of experience with distributed K-root operations and > possible funding models. > > Acknowledgements > > The author would like to thank Joao Silva Damas for comments > on an earlier draft as well as Andrei Robachevsky and Henk > Uijterwaal who provided comments on recent drafts. > > Appendix A - Detailed Issues > > Using a router or having a server speak BGP? > > Withdrawing BGP announcements based on service availability? > > Distributed service monitoring: Using current RIPE NCC oper- > ated machines all over the world is an easy option. Maybe > distributing automatic monitoring software to be run by vol- > unteers is another. What is essentially needed is to try a > small number of queries periodically including the query > identifying the instance of the server. Then transmitting > the results back to a (set of) collection point(s). > > Distributed BGP Monitoring: The RIS can be used for this. > Coverage should be sufficient. > > Information Campaign: What is needed to reach all ISPs that > need to know? How long a lead time do they need for the var- > ious stages of the deployment? > > -- > This message was passed to you via the ga at dnso.org list. > Send mail to majordomo at dnso.org to unsubscribe > ("unsubscribe ga" in the body of the message). > Archives at http://www.dnso.org/archives.html Regards, -- Jeffrey A. Williams Spokesman for INEGroup - (Over 127k members/stakeholders strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Contact Number: 214-244-4827 or 972-244-3801 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 From lmb at in-addr.de Tue Nov 5 18:41:07 2002 From: lmb at in-addr.de (Lars Marowsky-Bree) Date: Tue, 5 Nov 2002 18:41:07 +0100 Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <0c4e01c284ee$b78c66f0$c7b22443@repligate> References: <0H5405UME4K5VZ@Salicet.ucd.ie> <0c4e01c284ee$b78c66f0$c7b22443@repligate> Message-ID: <20021105174107.GF27832@marowsky-bree.de> On 2002-11-05T11:13:52, Jim Fleming said: > With no IN-ADDR.IE zone, it is easy to spot the ones slated to be phased > out. > http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=in-addr.ie&Type=255&submit=Lookup > > With so few "slots" open in the legacy root servers, only a limited number > of TLDs can be supported. Can you translate that to English please? Sincerely, Lars Marowsky-Br?e -- Principal Squirrel SuSE Labs - Research & Development, SuSE Linux AG "If anything can go wrong, it will." "Chance favors the prepared (mind)." -- Capt. Edward A. Murphy -- Louis Pasteur From Daniel.Karrenberg at ripe.net Wed Nov 6 19:03:23 2002 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 06 Nov 2002 19:03:23 +0100 Subject: Important Informational Message - root.zone change In-Reply-To: <200211051122.gA5BMnY27626@grimsvotn.TechFak.Uni-Bielefeld. DE> References: Message-ID: <4.3.2.7.2.20021106185728.03120008@localhost.ripe.net> It is important to stress that there is no flag day and no rush. I expect this audience to know that but I already had some questions from the less clueful. Anything to avoid such questions is a Good Thing(TM). Daniel From beri at eurorings.net Wed Nov 6 17:10:00 2002 From: beri at eurorings.net (Berislav Todorovic) Date: Wed, 6 Nov 2002 17:10:00 +0100 (MET) Subject: [lir-wg] Important Informational Message - root.zone change In-Reply-To: <004a01c2845c$c506f3a0$5d2300c0@VAIO> Message-ID: Would be also nice to have proper reverse resolving for J's new IP address (192.58.128.30). So far 198.41.0.10 still resolves to j.root-servers.net, while the new address doesn't resolve into anything: ; <<>> DiG 8.3 <<>> @depot.nstld.com 30.128.58.192.in-addr.arpa ANY ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 30.128.58.192.in-addr.arpa, type = ANY, class = IN ;; AUTHORITY SECTION: 128.58.192.in-addr.arpa. 1D IN SOA DEPOT.NSTLD.COM. nstld.verisign-grs.COM. ( 2002041800 ; serial 1H ; refresh 15M ; retry 2W ; expiry 1D ) ; minimum ;; Total query time: 87 msec ;; FROM: balder to SERVER: depot.nstld.com 198.41.3.109 ;; WHEN: Wed Nov 6 17:09:20 2002 ;; MSG SIZE sent: 44 rcvd: 114 From webmaster at ripe.net Tue Nov 12 15:06:55 2002 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 12 Nov 2002 15:06:55 +0100 Subject: New draft document available Message-ID: <200211121406.gACE6tJc028305@birch.ripe.net> Dear Colleagues, A new draft document is available from the RIPE Document Store and was send to the RIPE DNS-WG list for comment. "DRAFT: Distributing K-Root Service by Anycast Routing of 193.0.14.129" is available at: http://www/ripe/draft-documents/k-root-anycasting.htm Comments on this draft document will be accepted up to and including the week of RIPE 44, 27 - 31 January 2003. After incorporating any suggested changes to the document, the final document will be published as a RIPE Document. All comments and suggestions should be sent to . Kind Regards, Jeroen Bet RIPE NCC Webmaster From webmaster at ripe.net Tue Nov 12 16:29:01 2002 From: webmaster at ripe.net (RIPE NCC WebMaster) Date: Tue, 12 Nov 2002 16:29:01 +0100 Subject: Correction Message-ID: <200211121529.gACFT1Jc031702@birch.ripe.net> Dear Colleagues, The draft document: "DRAFT: Distributing K-Root Service by Anycast Routing of 193.0.14.129" is available from: http://www.ripe.net/ripe/draft-documents/k-root-anycasting.html Apologies for the incorrect URL earlier. Regards Jeroen Bet RIPE NCC WEBMASTER ================== From JimFleming at ameritech.net Wed Nov 20 21:49:35 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Wed, 20 Nov 2002 14:49:35 -0600 Subject: .UK ?...3:71 GB (UNITED-KINGDOM) Message-ID: <058701c290d6$55fcff00$b8bf2443@repligate> http://www.arin.net/library/internet_info/RIPEcountries.htm UNITED KINGDOM GB GBR RIPE ==== 3:71 GB (UNITED-KINGDOM) Jim Fleming 128-bit DNS is closer than you think... IPv16...NET...COM...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au From JimFleming at ameritech.net Wed Nov 20 22:06:04 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Wed, 20 Nov 2002 15:06:04 -0600 Subject: .UK ?...3:71 GB (UNITED-KINGDOM) References: <058701c290d6$55fcff00$b8bf2443@repligate> <20021120210044.GA10087@bfib.colo.bit.nl> Message-ID: <05a701c290d8$a3d053b0$b8bf2443@repligate> ----- Original Message ----- From: "Pim van Pelt" > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim at ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- Will .NL be moving under .AM ?.....NL.AM....or NL.NR...?..or NL.NO ? Where will .UK end up ? IPv16...NET...COM AM...NZ AE...FM...NR...SZ AC...DE...FI...JM...NO...PR...ST...UZ From JimFleming at ameritech.net Wed Nov 20 22:11:21 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Wed, 20 Nov 2002 15:11:21 -0600 Subject: Correction...NL.NZ...??Re: .UK ?...3:71 GB (UNITED-KINGDOM) Message-ID: <05c101c290d9$60ab3090$b8bf2443@repligate> Will .NL be moving under .NZ ?.....NL.AM....or NL.NR...?..or NL.NO ? ...or NL.EU ? Where will .UK end up ? IPv16...NET...COM AM...NZ AE...FM...NR...SZ AC...DE...FI...JM...NO...PR...ST...UZ ----- Original Message ----- From: "Jim Fleming" To: "Pim van Pelt" Cc: "RIPE DNS WG" Sent: Wednesday, November 20, 2002 3:06 PM Subject: Re: .UK ?...3:71 GB (UNITED-KINGDOM) > ----- Original Message ----- > From: "Pim van Pelt" > > ---------- - - - - -+- - - - - ---------- > > Pim van Pelt Email: pim at ipng.nl > > http://www.ipng.nl/ IPv6 Deployment > > ----------------------------------------------- > > Will .NL be moving under .AM ?.....NL.AM....or NL.NR...?..or NL.NO ? > > Where will .UK end up ? > > IPv16...NET...COM > AM...NZ > AE...FM...NR...SZ > AC...DE...FI...JM...NO...PR...ST...UZ > > From JimFleming at ameritech.net Wed Nov 20 23:35:20 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Wed, 20 Nov 2002 16:35:20 -0600 Subject: "the European Commission to run the proposed .EU TLD registry." ? Message-ID: <064601c290e5$1c38cbf0$b8bf2443@repligate> http://www.dnso.org/clubpublic/registrars/Arc01/msg03617.html From: "Paul M. Kane" "the European Commission to run the proposed .EU TLD registry." === http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=eu&submit=Submit Analysis : Top Level Domain EU exists. ORSC : Open Root Server Confederation : 199.166.24.1 VueDig Results : Answer = 2 : Authority = 0 : Additional = 0. eu. 1D IN NS uk.universalroot.com. eu. 1D IN NS us.universalroot.com. Jim Fleming 128-bit DNS is closer than you think... IPv16...NET...COM...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ http://ipv8.dyndns.tv http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au From pim at ipng.nl Wed Nov 20 22:00:44 2002 From: pim at ipng.nl (Pim van Pelt) Date: Wed, 20 Nov 2002 22:00:44 +0100 Subject: .UK ?...3:71 GB (UNITED-KINGDOM) In-Reply-To: <058701c290d6$55fcff00$b8bf2443@repligate> References: <058701c290d6$55fcff00$b8bf2443@repligate> Message-ID: <20021120210044.GA10087@bfib.colo.bit.nl> Jim, Could you possibly be somewhat more verbose when you blatantly post yet another link to a public forum. Somehow I think you are trying to make a point but you never actually _say_ anything, except for pointers to URLs in which we (the RIPE community) are supposed to find hidden agenda's. Many folk already have you procmailed out of their life. Also people have requested to list operators at the RIPE NCC to have your posting privileges removed, to which they refrained to keep these RIPE fora truely open. I for one would appreciate it if you simply made your point and not wasted everybodies time over and over again pasting irrelevant and off-topic URLs, forcing them down everybodies throat. Do you wish to be removed also in the European fora ? This is meant as a rhetorical question, by the way. On Wed, Nov 20, 2002 at 02:49:35PM -0600, Jim Fleming wrote: | http://www.arin.net/library/internet_info/RIPEcountries.htm | UNITED KINGDOM | GB | GBR | RIPE I don't have a clue what you mean, and am offended (like I always am) by the fact that your ridiculous IPv8 signature takes up more space in my mailfolder than the actual body of the mails you send. Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim at ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From JimFleming at ameritech.net Wed Nov 27 16:19:27 2002 From: JimFleming at ameritech.net (Jim Fleming) Date: Wed, 27 Nov 2002 09:19:27 -0600 Subject: Fw: ?:? .NAME...Still in Proof-of-Concept Phase ? Message-ID: <066d01c29628$6094add0$cdba2543@repligate> NSpace : Name.Space : 209.48.2.11 VueDig Results : Answer = 2 : Authority = 0 : Additional = 2. NAME. 2D IN NS NS.ICANN.ORG. NAME. 2D IN NS NS.RIPE.NET. Sent: Wednesday, November 27, 2002 9:18 AM Subject: ?:? .NAME...Still in Proof-of-Concept Phase ? > http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt > ?:? .NAME > ==== > > http://www.icann.org/minutes/report-gnr-whois-26nov02.htm > > http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=NAME&submit=Submit > Analysis : Top Level Domain NAME exists. > > > Jim Fleming > 128-bit DNS is closer than you think... > IPv16...COM...NET...AM...NZ...AE...FM...NR...SZ...AC...DE...FI...JM...NO...PR...ST...UZ > http://ipv8.dyndns.tv > http://ipv8.dyns.cx > http://ipv8.no-ip.com > http://ipv8.no-ip.biz > http://ipv8.no-ip.info > http://ipv8.myip.us > http://ipv8.dyn.ee > >