- dns-wg - mailman.ripe.net

Re: [ga] More Root-Servers?
by Jeff Williams 06 Nov '02

06 Nov '02

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 <Daniel.Karrenberg(a)ripe.net> > To: RIPE DNS WG <dns-wg(a)ripe.net> > Cc: RIPE Routing WG <routing-wg(a)ripe.net> > 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 > <daniel.karrenberg(a)ripe.net> > > $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(a)dnso.org list. > Send mail to majordomo(a)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(a)ix.netcom.com Contact Number: 214-244-4827 or 972-244-3801 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

1 0

Re: [lir-wg] Important Informational Message - root.zone change
by Niall.oReilly＠ucd.ie 05 Nov '02

05 Nov '02

> 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

4 5

Distributing K-Root Service by Anycast Routing
by Daniel Karrenberg 05 Nov '02

05 Nov '02

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 <daniel.karrenberg(a)ripe.net> $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?

2 1

Mailing List Software Migration
by RIPE NCC WebMaster 10 Oct '02

10 Oct '02

Dear Mailing List Subscriber, The RIPE NCC will change its mailing list software from "majordomo" to "mailman" on 17 October 2002. The new mailing list software will give users more options to manage their subscriptions to the RIPE and RIPE NCC mailing lists. Additionally, this change is being made to ensure stability and continuity of mailing list management and archiving. The new mailing list software will give users a number of options using a web interface: - Subscribing and Unsubscribing to mailing lists - Reviewing general information about the mailing lists - Viewing subscriptions to mailing lists - Temporarily disabling mail delivery - Choosing between regular and digests of mailing list postings - Acknowledgements to postings The web interface will be located at the following URL: http://www.ripe.net/mailman/ As well as using the web interface, mailing list users can manage their subscription and retrieve information by using an e-mail client. Further details on this are available at the above URL. Please note that if mailing list users are already subscribed to one or more mailing lists, they do not have to take any action. Messages can still be sent to the regular mailing lists addresses and subscriptions will not have to be re-confirmed. If you have any questions about this migration, please feel free to send an e-mail to <webmaster(a)ripe.net> Kind Regards, Jeroen Bet RIPE NCC Mailing List Moderation

1 0

How to change hardware dns?Please lead us!
by chizari＠irost.com 02 Sep '02

02 Sep '02

Dear Sir/Madam IN Ripe NCC DNS WG Staff Hello,I hope you have fine time, We are one of your LIR and have two DNS server which work as primary & secondary.because of old hardware version of this server we deside to change primary server to new system without losing zonefiles which registred at dns manager and disconnecting of internet connection of our customer.we know that one way is create primary as a master and other system as slave and forward files to new system then converting new system to primary whith the same ip.but we intrest that is there new and easy way to transferring zone files from old system to new system?and if we have only master & slave configuration to rech the aim do you please lead us with step by step configutation to success prossessing.We deside change only system from nt 4. to new system with same IP address. Please advise us Thanks a lot The Best regards.

1 0

E-mail address masquerading for archived mail messages
by RIPE NCC WebMaster 16 Aug '02

16 Aug '02

Dear Colleagues, [Apologies for duplicate mails] Beginning today, 16 August, the RIPE NCC will implement "e-mail address masquerading" for messages displayed on the web site in the RIPE and the RIPE NCC mailing list archives. E-mail masquerading makes it more difficult for spammers to harvest e-mail addresses from the mailing list archives. When masquerading is applied, the e-mail address of the sender will be hidden in the mail archived messages. Those reading archived mail will see a return e-mail address that appears as "<somebody@localhost>". When clicking on this e-mail address, the address of the original sender will be loaded in your mail program, enabling you to send a message to the author. The RIPE NCC has chosen to implement this security measure as there have been various complaints from members of the RIPE community that e-mail addresses were being abused by spammers for Unsolicited Bulk E-mail (UBE). By implementing this security measure we anticipate there will be a sharp reduction to address harvesting of archived e-mail addresses. We will be checking for harvesters who manage to overcome this measure and will take further steps if necessary. E-mail masquerading will be applied to all mailing lists found in the following directories: http://www.ripe.net/ripencc/mail-archives/ http://www.ripe.net/ripe/mail-archives/ We appreciate your understanding on this matter. Regards Jeroen Bet RIPE NCC WEBMASTER ==================

1 0

REMINDER DNSSEC, introduction to the concept and current state (fwd)
by Henk Uijterwaal (RIPE-NCC) 15 Aug '02

15 Aug '02

FYI. ---------- Forwarded message ---------- Date: Thu, 15 Aug 2002 12:13:19 +0200 From: RIPE NCC Training <training(a)ripe.net> To: local-ir(a)ripe.net Subject: REMINDER DNSSEC, introduction to the concept and current state * * * Reminder * * * DNSSEC, introduction to the concept and current state Date: Saturday 14 September 2002 Time: 0900 - 1700 Location: Rhodes, Greece AND Date: Tuesday 22 October 2002 Time: 0900 - 1700 Location: Sarajevo, Bosnia AND Date: Thursday 28 November 2002 Time: 0900 - 1700 Location: Paris, France AND Date: Thursday 12 December 2002 Time: 0900 - 1700 Location: Amsterdam, The Netherlands The Domain Name System (DNS) is one of the main parts of the Internet Infrastructure. DNS is trusted by many end-users to give correct results. At the moment, however, DNS lacks a mechanism to establish the authenticity and integrity of the data it provides. DNSSEC is a set of extensions to provide end-to-end authenticity and integrity. This introduction will cover. - DNS security threats; - DNSSEC security mechanisms; + DNSSEC server protection; + DNSSEC data protection; - Delegation issues; - Key management issues; - Current developments; The DNSSEC introduction is intended for those who are familiar with common DNS terminology and are interested in learning about the concepts and mechanisms that DNSSEC offers. Our goal is to provide participants with sufficient background to be able to deploy DNSSEC in their own organization. Examples are based on the BIND name server. More information about the details of the DNSSEC Introduction can be found at: http://www.ripe.net/disi/ Kind regards, Sandra Gijzen RIPE NCC Training Co-Ordinator REGISTRATION ============ To register for these Courses, please complete the registration form below and reply to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add a value in the `box' area marked between the square brackets (i.e. "[" and "]" ). Alternatively, you can use the Training Course Request Form at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions about the DNSSEC Introduction, your registration form or the web page, please contact us at <training(a)ripe.net>. -------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The Course you plan to attend (date and location) # COURSE [ ] %END

1 0

Re: New draft charter for the RIPE DNS WG
by Jim Reid 17 Jul '02

17 Jul '02

>>>>> "Brad" == Brad Knowles <brad.knowles(a)skynet.be> writes: Brad> I think that we'll all agree that the DNS really needs Brad> to be seriously cleaned up, and if we don't do what we can Brad> to help spur that process along, then who will? This is fair comment. The trouble is how to improve things. There isn't a DNS police to enforce BCPs or whatever and throw persistent offenders in jail. Having a hall of shame for the people with the most badly broken setups is hardly likely to be productive either. And as Peter pointed out, the process for getting TLD delegations amended can be painful and slow, even when the TLD wants to make a change. Friendly persuasion and quiet words of advice from a Jon Postel would probably be effective. But who is there that has that stature and broad acceptance today?

1 0

draft-whois-srv-02.txt
by Gerhard Winkler 16 Jul '02

16 Jul '02

Hi, we have now changed our first version and have incorporated a lot of comments which were made during/after the last RIPE meeting. Please feel free to discuss and send any comments. We will try to move this paper forward. regards, Gerhard draft-whois-srv-02.txt Linus Corin Marcos Sanz Gerhard Winkler 1 July 2002 Using DNS SRV records to locate whois servers Status of this Memo This document is a draft on the usage of the DNS SRV RR for the location of whois servers. Abstract Whois servers are used to locate administrative, technical and security contacts for given IP addresses, domain names or other network objects associated with an organisation, e.g. AS numbers. While usually Top Level Domain (TLD) registries run a whois server, there is no generic name for it and it may not even be obvious that the TLD registry's whois server is the right one to ask, since there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) also provide whois service as part of their coordination task. All this can be solved by central "master" or "meta" whois servers, which keep track of all new and changing servers and refer to the DNS registries' or RIRs' whois servers. This document proposes an approach which eliminates the need for a central master repository and works down to lower levels in the hierarchy. It is the intent to locate a whois server as close to the target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. This situation can be improved by using DNS SRV records and SRV-cognizant whois clients. This document deals with domain information only and it describes how DNS SRV records should be used but it does not define any search strategies (this will be discussed in a additional document). 0. Definitions The key words "MUST", "SHOULD", and "RECOMMENDED" in this document are to be interpreted as described in [RFC 2119]. Other terms used in this document are defined in the DNS specification, [RFC 1034]. 1. Format The general format of DNS SRV records is documented in RFC 2782: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Therefore the simplest format of an SRV record to locate a whois server is: _nicname._tcp IN SRV 0 0 43 whois.nic.example. [IANA-NUM] foresees the possibility of a whois service over UDP. Common use is TCP but nothing would prevent from analogously setting the _Proto field to the value _udp. Nevertheless this document deals with the TCP case only. The symbolic name of the service is defined as "nicname" (case insensitive), because it is defined in [RFC 954] in this way; though the most familiar name is "whois". Priority and Weight have a value of 0 in the example above just for readability purposes. It is RECOMMENDED to use the port number 43, as specified in [IANA-NUM]. SRV-cognizant whois clients SHOULD interoperate with traditional whois servers which are in place right now. 2. Usage If there is a whois server running for a specific domain, such an SRV record can be defined. When used for looking up information about a domain, whois clients can do DNS lookups for SRV records, and can use the retrieved target information to point their whois queries accordingly. This kind of client is called "SRV-cognizant" or "SRV-aware" whois client. It is imaginable that this functionality could be extended for other purposes (like IP address space allocation or handle lookup), but this remains open for a future discussion. 3. Restrictions The service record functionality is meant as an extension to the existing whois service and not as a new service. In the absence of a whois protocol whose specification calls for the use of other weighting information, the field Weight in the SRV record keeps the standard meaning specified in [RFC 2782]. As defined in [RFC 2782] the client SHOULD abort if it finds a record defined like: _nicname._tcp IN SRV 0 0 0 . This means the SRV processing should be aborted at that level. But nothing avoids the client to search for other SRV records above or under that level. This behavior should be scope of search strategies. The given SRV record does not provide any information about the existance/absence of a service with the same name on subdomains or zones below or above. The search behavior of the client must be defined as it should be independant from conventional DNS search algorithms defined by searchlists. To avoid unnecessary load on the DNS root servers, a client MUST NOT ask for a whois server for the root domain, i.e. it MUST NOT issue queries for _nicname._tcp. 4. Authority There is no authority which defines who should run a whois server, though it is usual that the TLD registry runs a whois service for the zone where it is authoritative. There is no definition of which target should be used as a default for an SRV-cognizant whois client if no whois server could be discovered by means of SRV records. The use of a default whois server is local dependent. 5. Security Considerations The same security considerations as defined in [RFC 2782] should apply. There is no discussion on security, data protection and privacy relating to the contents of the whois server in this paper. This is the responsibility of the whois server operator and has nothing to do with a mechanism that describes how whois servers can be reached. A client developer must be aware that DNS search algorithms can lead to this problem: By using DNS query logging an organisation could find out who is issuing whois queries about them even without operating a whois server themselves. 6. References [RFC 954] NICNAME/WHOIS [RFC 1034] Domain names - concepts and facilities [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) [IANA-NUM] www.iana.org: Directory of General Assigned Numbers 7. Authors' Addresses Linus Corin Telia International Carrier 4th Floor, 330 High Holborn WC1V 7QY London, United Kingdom linus(a)telia.net Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany sanz(a)denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria gerhard.winkler(a)univie.ac.at -- Gerhard Winkler | E-Mail: gerhard.winkler(a)univie.ac.at Vienna University Computer Center | Universitaetsstrasse 7 | Tel: +43 1 4277 14035 A-1010 Vienna, Austria | Fax: +43 1 4277 9140

1 0

Re: Re: New draft charter for the RIPE DNS WG
by Marcos Sanz/Denic 15 Jul '02

15 Jul '02

On 12.07.2002 15:36 Brad Knowles <brad.knowles(a)skynet.be> wrote: > > > The aspect of topological diversity > > is approached by the ``shared secondary servers(?)'' project, which I think > > is led by DE-NIC under the umbrella of CENTR. So, should we try to learn > > more about these efforts? > > That would be something we should learn more about, and perhaps > provide any additional support or assistance that we can. The charter of the project can be found under http://www.centr.org/groups/sss-wg/ There is also a mailing list, which has been very quiet since its establishment (euphemism for no messages at all). Questions, suggestions and support to the project are really welcome. Regards, Marcos Sanz DENIC eG

1 0