Re: [dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
Dear colleagues, There were some questions on the list in response to my earlier message (see below). Therefore, I'd like to add some clarification. With regard to the RfP process: we have of course followed due process, as documented in the RfP document, available to all contenders. We kept the RIPE NCC Executive Board informed throughout the entire process and would be happy to share further information with board members should the need arise. The final contract text was reached after negotiation on contract details to make sure the agreement was fully in line with our principals and detailed requirements. One request on the list was, in the interest of full transparency, to share the contractual details with the working group. However, legal restrictions prevent us from doing so. I hope this addresses the questions raised and clarifies the situation. We're happy to hear more questions and feedback from the working group. Kind regards, Romeo On 16/10/18 10:54 , Romeo Zwart wrote: > Dear colleagues, > > In July we published a Request for Proposals (RfP) for a trusted third > party to provide secondary DNS services for the RIPE NCC's zones: > https://www.ripe.net/ripe/mail/archives/dns-wg/2016-July/003303.html > > Following our announcement, we received three final proposals by the > conclusion of the process. We selected the best fitting proposal based > on the technical and non-technical requirements in the RfP document. > > The proposal submitted by VeriSign Sàrl (“Verisign”) was the best fit. > We subsequently signed a contract with Verisign, which comes into effect > before the end of this year. The contract is for the period of one year, > with the intention to renew yearly. Prior to renewal, we will look at > the benefits of the service and actual market situation at that time to > decide on renewing the service. > > We'd like to express our gratitude to all parties who submitted > proposals. We look forward to working with Verisign in the future. > > Regards, > Romeo Zwart > RIPE NCC > >
[dns-wg] Verisign to provide secondary DNS services for the RIPE NCC’s zones
Dear colleagues, In July we published a Request for Proposals (RfP) for a trusted third party to provide secondary DNS services for the RIPE NCC's zones: https://www.ripe.net/ripe/mail/archives/dns-wg/2016-July/003303.html Following our announcement, we received three final proposals by the conclusion of the process. We selected the best fitting proposal based on the technical and non-technical requirements in the RfP document. The proposal submitted by VeriSign Sàrl (“Verisign”) was the best fit. We subsequently signed a contract with Verisign, which comes into effect before the end of this year. The contract is for the period of one year, with the intention to renew yearly. Prior to renewal, we will look at the benefits of the service and actual market situation at that time to decide on renewing the service. We'd like to express our gratitude to all parties who submitted proposals. We look forward to working with Verisign in the future. Regards, Romeo Zwart RIPE NCC
Re: [dns-wg] Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
Hi Jim, On 16/07/25 18:49 , Jim Reid wrote: > >> On 25 Jul 2016, at 16:56, Romeo Zwart <romeo.zw...@ripe.net> wrote: [..] >> We have tried to make these requirements as clear as possible, including >> distinctions between mandatory and optional elements, and we have >> documented those in the document that will be sent on request. > > Great! It’s a pity this isn’t mentioned in the announcement. > >> It would indeed be unrealistic to expect detailed responses based on the >> limited information that is on the mentioned web page. That is clearly >> not our expectation. > > I’m glad to hear that Romeo. Though until your recent clarification email, I > fear you may well have given prospective bidders that impression. Thanks for those comments! We will add some clarifying text to the web page. Cheers, Romeo
Re: [dns-wg] Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
Hi Jim, Thanks for the quick response. On 16/07/25 17:42 , Jim Reid wrote: > >> On 25 Jul 2016, at 15:59, Romeo Zwart <romeo.zw...@ripe.net> wrote: >> >> The RIPE NCC requests proposals for service from a DNS service provider >> in order to improve the resiliency of the RIPE NCC's zones, especially >> ripe.net. >> >> The submission deadline is Sunday, 14 August 2016. >> >> For more details please see: >> >> >> https://www.ripe.net/publications/news/announcements/request-for-trusted-party-to-provide-secondary-dns-services > > Thanks for this Romeo. > > The above URL doesn’t say very much. Could you please provide some more > details? As expressed on the page mentioned above, the intention of the process is that interested parties respond to the email address quoted to be sent the detailed RfP document. I'd invite you to do so if you are interested to provide services. :) > Are you expecting fully-baked and costed proposals by the mid-August deadline > or just expressions of interest by then? The mid-August deadline is for full proposals. > What sort of service levels and commitments are the NCC looking for from > potential suppliers? eg: a 24x7 NOC, SLAs, minimum/maximum query rates, > anycast/unicast provision, server location(s), diversity of DNS software, > statistics/logging, incident handling & escalation, mandatory/optional > protocol requirements, support for DNS features like RRL, etc, etc. Which > things on this sort of shopping list are essential/desirable/optional? We have tried to make these requirements as clear as possible, including distinctions between mandatory and optional elements, and we have documented those in the document that will be sent on request. > It seems unrealistic/unreasonable to ask for responses when there’s so little > information on what bidders are expected to be quoting on. Or what the "small > number of additional zones” might be. [Do they include “.” or subdomains of > .arpa? :-)] Or what is meant by a small number. It would indeed be unrealistic to expect detailed responses based on the limited information that is on the mentioned web page. That is clearly not our expectation. > I also think it’s a bit optimistic to give bidders just three weeks to > prepare their responses. More so during peak holiday season. Why the rush? We are expecting experienced and professional service providers to respond, who have the required infrastructure and service machinery in place and for whom three weeks will be a suitable period to respond. Kind regards, Romeo
[dns-wg] Request for trusted party to provide secondary DNS services for the RIPE NCC’s zones
Dear colleagues, The RIPE NCC requests proposals for service from a DNS service provider in order to improve the resiliency of the RIPE NCC's zones, especially ripe.net. The submission deadline is Sunday, 14 August 2016. For more details please see: https://www.ripe.net/publications/news/announcements/request-for-trusted-party-to-provide-secondary-dns-services Kind regards, Romeo Zwart RIPE NCC
Re: [dns-wg] RIPE Authoritative DNS services degraded
Dear colleagues, The traffic that we reported about yesterday, Thursday 14 January, (see below message) came to an end shortly after the announcement was sent. The attack traffic was overwhelming our incoming links. As this was impacting other services, we had started to ask our upstream peers to filter traffic to the specific address we use for the .ps ccTLD service. However, the traffic load returned to normal fairly quickly. Later in the afternoon we have removed any upstream filtering. As mentioned in an earlier message to this list, the frequency of incidents we see with our DNS services seems to be part of a more general trend, which leads us to further investigate necessary improvements to our DNS infrastructure. Kind regards, Romeo Zwart On 16/01/14 13:08 , Romeo Zwart wrote: > Dear colleagues, > > As of approximately 11:20 UTC this morning, Thursday 14 January, we are > seeing an unusually large amount of incoming traffic on the servers for > the RIPE Authoritative DNS services. The traffic is specifically aimed > at the ccTLD secondary service that we host for .ps and is of such a > high volume that it is impacting other DNS services. > > We are contacting the domain owners and are investigating mitigation > capabilities at the moment. We will inform you further when we have more > information. > > Kind regards, > Romeo Zwart >
Re: [dns-wg] RIPE NCC Authoritative and Secondary DNS services on Monday 14 December
Dear Jaap and colleagues, On 29 December you wrote to the list: > Stephane's message was on the centr security list which archives > seem to be sealed (contrary to what I thought). It was refering to > the attack on the .tr name servers about which you reported in > <https://www.ripe.net/ripe/mail/archives/dns-wg/2015-December/003184.html> > that it had impacted RIPE's DNS service. Apparently Stephan wanted > to know why RIPE NCC dropped serving the .tr zone. (My guess, since > de RIPE NCC dropped out of the root zone as well, it was done in > coordination with the tr people). > > So I was just curious wat happened on RIPE's end. In the incident report you reference above, I did not mention the .TR zone explicitly, which apparently led to unnecessary confusion and an undesired atmosphere of secrecy around the incident. I did mention in the same message that, after applying various mitigation measures during the day, we turned to our upstreams to assist us with mitigation in the late afternoon of Monday 14th. In practice this meant we asked for upstream blackholing of the attack traffic, which effectively meant we were no longer serving the .TR zone. While the event was ongoing, we were of course communicating with the .TR staff frequently. On Tuesday morning, 15 December, the .TR staff informed us that they removed the RIPE NCC secondary server from the .TR zone altogether. I hope this clarifies matters sufficiently. If you have more questions please feel free to ask. I should add, however, that we do not intend to share more details about the attack itself, or the mitigation applied, on this list. An observation that we have made during the past months is that the impact of attacks upon our DNS infrastructure is increasing. This seems to be a more general trend that readers on this list are likely to be aware of, but this may not be the case for the community at large. For the RIPE NCC this means that we are investigating the options to increase the capacity and robustness of our DNS services further. Kind regards, Romeo Zwart
Re: [dns-wg] RIPE NCC Authoritative and Secondary DNS services on Monday 14 December
Hi Jaap, On 15/12/29 13:08 , Jaap Akkerhuis wrote: > Romeo Zwart writes: > > > Yesterday, Monday 14 December 2015, RIPE NCC Authoritative DNS services > > were functioning in a severely degraded state during parts of the day. > > > > etc. > > According a message from Stephane Bortzmeyer > >"The RIPE name server was retired on 16 december, for unknown > reasons (as far as I know, the RIPE-NCC did not communicate on > that)." > > Can you comment on that? With this limited amount of information, that would be hard. Which zones are we talking about and what does 'retired' mean in this context? I haven't seen Stephane's message (yet). Was that a private message or sent to a mailing list? Can you forward the whole message or have Stephane provide more detail about his observations directly to me? Thanks, Romeo > > Thanks, > > jaap >
Re: [dns-wg] RIPE NCC Authoritative and Secondary DNS services on Monday 14 December
Hi Jaap, > On 29 dec. 2015, at 19:58, Jaap Akkerhuis <j...@nlnetlabs.nl> wrote: > > Romeo Zwart writes: > >> Hi Jaap, >> >>> On 15/12/29 13:08 , Jaap Akkerhuis wrote: >>> Romeo Zwart writes: >>> >>>> Yesterday, Monday 14 December 2015, RIPE NCC Authoritative DNS services >>>> were functioning in a severely degraded state during parts of the day. >>>> >>>> etc. >>> >>> According a message from Stephane Bortzmeyer >>> >>> "The RIPE name server was retired on 16 december, for unknown >>>reasons (as far as I know, the RIPE-NCC did not communicate on >>>that)." >>> >>> Can you comment on that? >> >> With this limited amount of information, that would be hard. Which zones >> are we talking about and what does 'retired' mean in this context? >> >> I haven't seen Stephane's message (yet). Was that a private message or >> sent to a mailing list? Can you forward the whole message or have >> Stephane provide more detail about his observations directly to me? > > It seems that I have indeed removed to much of the context. > > Stephane's message was on the centr security list which archives > seem to be sealed (contrary to what I thought). It was refering to > the attack on the .tr name servers about which you reported in > <https://www.ripe.net/ripe/mail/archives/dns-wg/2015-December/003184.html> > that it had impacted RIPE's DNS service. Ah ok, some context helps. :) > Apparently Stephan wanted > to know why RIPE NCC dropped serving the .tr zone. (My guess, since > de RIPE NCC dropped out of the root zone as well, it was done in > coordination with the tr people). Indeed it was. > So I was just curious wat happened on RIPE's end. We can share some more detail next week. Kind regards, Romeo > >jaap >
[dns-wg] RIPE Labs article: K-root expansion plans
Dear colleagues, The RIPE NCC is getting ready to expand the K-root network. We'd like to share more details about our expansion plans at this stage and look forward to hearing your feedback: https://labs.ripe.net/Members/romeo_zwart/k-root-expansion-plan We will start accepting requests for new K-root hosted nodes in mid-May. There will be a separate announcement about this during RIPE 70, which will have all details about the process for becoming a host. Best regards, Romeo Zwart RIPE NCC
Re: [dns-wg] New on RIPE Labs: New Architecture Model for K-root Local Instances
Hi Randy, all, Thanks for your questions. On 15/03/12 03:40 , Randy Bush wrote: hi mirjam, romeo, et alia, this looke cool, and lighter weight. but a few questions as usual. In the new model, the K-root hosted node will only peer with one party, the local host, and the local host is responsible for further propagation of the K-root prefix[1] does this add an as hop, or are you hiding in the host's asn, or using a private (and thus stripped) asn? There is no hiding or stripping of the prefix, so yes, this will add a hop. The global or core nodes will of course be connected as currently to major IXP's, announcing the prefix directly. It is possible that there is an impact on routing for some of the clients currently behind local/hosted nodes, however this currently adds up to about 10% of the query load. Also, we do expect a substantial uptake of new hosts, so this will result in a more finer grained distribution of K-root. and can you explain the motivation for radically reducing the bgp out-degree? There are two drivers for that. We receive many requests from prospective new K-root hosts. We have considered how to respond to this demand from the community. This made us propose this smaller footprint server, enabling a wider variety of hosts at a lower cost. So, one driver for changing the BGP routing model, is in the simplified hardware. We prefer the single server to spend it's time on answering DNS queries, rather than spend its cycles on routing BGP. The second driver is that we spend a relatively large amount of engineering time on peering management for each instance. In the new model that factor is obviously reduced a lot, which allows us to scale the number of instances and achieve a finer grained distribution without a large increase in management and engineering effort. 1/ For an old-style local node, the anycast prefix was advertised with the no-export community string set, in order to limit the scope of the prefix propagation. This is no longer the case in the new design. are you intending the node actually propagate globally, or hoping the one bgp peer adds NO_EXPORT? We will discuss with hosts how they propagate the K-root prefix on a case by case basis. Some may prefer to distribute only locally, others may propagate globally. We expect of course that they tune this according to local capacity. We will monitor, using for example RIPE Atlas and DNSMON, the actual impact on K-root reachability for end users and work with the local hosts to optimize routing where needed. Thanks, Romeo randy
