From pk at DENIC.DE Tue Jun 3 00:57:27 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 3 Jun 2014 00:57:27 +0200 Subject: [dns-wg] indulgence satiated In-Reply-To: References: Message-ID: <20140602225727.GN3706@x28.adm.denic.de> On Wed, May 28, 2014 at 07:35:48AM -0700, manning bill wrote: > Thanks All for taking the time to prod 2001:500:84::b > > Looks like it is reachable from many places? enough that we will proceed to > augment the ?B? root server with perhaps the last in a long line of IPv6 > addresses that it has had over the last 15 years. with b.root-servers.net. 518400 IN AAAA 2001:500:84:0:0:0:0:b available in the root zone as of 2014060201 (and probably earlier in root-servers.net), is there any query rate data for the new address that could be shared demonstrating the incoming traffic to that new address increasing over time? Thanks, Peter From bmanning at isi.edu Tue Jun 3 02:47:21 2014 From: bmanning at isi.edu (manning bill) Date: Mon, 2 Jun 2014 17:47:21 -0700 Subject: [dns-wg] indulgence satiated In-Reply-To: <20140602225727.GN3706@x28.adm.denic.de> References: <20140602225727.GN3706@x28.adm.denic.de> Message-ID: <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> lets give it a few hours, ok? /bill Neca eos omnes. Deus suos agnoscet. On 2June2014Monday, at 15:57, Peter Koch wrote: > On Wed, May 28, 2014 at 07:35:48AM -0700, manning bill wrote: >> Thanks All for taking the time to prod 2001:500:84::b >> >> Looks like it is reachable from many places? enough that we will proceed to >> augment the ?B? root server with perhaps the last in a long line of IPv6 >> addresses that it has had over the last 15 years. > > with > > b.root-servers.net. 518400 IN AAAA 2001:500:84:0:0:0:0:b > > available in the root zone as of 2014060201 (and probably earlier > in root-servers.net), is there any query rate data for the new > address that could be shared demonstrating the incoming traffic > to that new address increasing over time? > > Thanks, > Peter From pk at DENIC.DE Tue Jun 3 07:25:49 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 3 Jun 2014 07:25:49 +0200 Subject: [dns-wg] indulgence satiated In-Reply-To: <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> References: <20140602225727.GN3706@x28.adm.denic.de> <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> Message-ID: <20140603052549.GO3706@x28.adm.denic.de> On Mon, Jun 02, 2014 at 05:47:21PM -0700, manning bill wrote: > lets give it a few hours, ok? sure, apologies for present tense in the question. Thanks, Peter From pk at DENIC.DE Tue Jun 3 08:46:52 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 3 Jun 2014 08:46:52 +0200 Subject: [dns-wg] WG comment on DNSMON changes In-Reply-To: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> References: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> Message-ID: <20140603064652.GP3706@x28.adm.denic.de> Colleagues, (* hat off *) On Mon, May 19, 2014 at 04:04:34PM +0100, Jim Reid wrote: > I would be grateful if you could express your approval or rejection of the NCC's approach and proposed time-line. Details are at https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-phasing-out-the-old-ttm-based-dnsmon. [...] > I'd appreciate it if you can comment on the list to indicate that you approve (or disapprove) of the current proposal and/or time-line. I've taken the liberty to copy the timeline here, so we can actually discuss it (could have discussed it) on the list. Labs is a nice idea, but content/external maybe not so. > Old and new DNSMON will be available in parallel until end of June 2014. > Configuration updates for existing zones will only be applied to the new DNSMON. > Data collection in the old DNSMON service will be terminated by 1 July 2014. Given the increasingly painful dependency on the old TTM system, and taking into account the warning time given to us customers, this transition deadline appears reasonable to me: "no objection". > Data visualisation of (historic) measurement data provided by the old DNSMON will be available until the end of 2014. > Raw data from the old DNSMON measurements will be kept available for a longer period. We are investigating ways to keep the old data available indefinitely. As I said at the microphone in Warsaw, I think it would be a plus not only to maintain the old data, but also some way to visualize it, so some trends over the years can be looked up (literally, not only dug in the raw data) in comparison. That does not imply running an unmaintained or unmaintainable system indefinitely, neither does it postpone the shutdown date for said system. Getting the viz back in some "reasonable" time would be great. The other point I want to submit "in writing" is that I am not convinced by the reasoning that led to giving up the two hour delay. The fact that "measurements are public" or "anybody could set up their own measurements" neglects the very value added by the (new) visualisation: not only is there an instant feedback channel, but that channel is _the_ well reputed source. In 1980s' words: the revolutionary army not only has a transmitter, but it has direct write access to the 20:00 main news. Doesn't give me sleepless nights, but I question the unilateral decision based on that fatalistic reasoning. Regards, Peter (* still hatless *) From Brett.Carr at nominet.org.uk Tue Jun 3 09:43:21 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Tue, 3 Jun 2014 07:43:21 +0000 Subject: [dns-wg] WG comment on DNSMON changes In-Reply-To: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> References: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> Message-ID: I had been meaning to reply to this but (as usual) time ran away with me. I?m fully in support of the approach the NCC is taking to DNSMON and the phasing our of the old system. I strongly support keeping historic data available indefinitley and would prefer if this was both raw data and visualisation if I?m honest, this is because if I do want to look at past performance of something in DNSMON this is usually something I want to do quickly and easily without having to process data. With regard to new zones in DNSMON, I strongly support this, Nominet would like to monitor the GTLD?s it will be serving over the coming months/years. Brett On 19 May 2014, at 16:04, Jim Reid wrote: > Colleagues, you might recall that last month the NCC announced a time-line for some changes to the DNSMON service. This was discussed when the WG met in Warsaw last week. > > In outline, the old service is based on TTM boxes which are due to be retired at the end of June. These are already beyond their anticipated life-span. The new version of DNSMON uses the Atlas probes and is already operational. It is possible some users of DNSMON may need to change their internal tools and processes when transitioning to the new platform if these depend on the data gathering done by the soon-to-die TTM boxes. If this affects you, please speak up now! > > I would be grateful if you could express your approval or rejection of the NCC's approach and proposed time-line. Details are at https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-phasing-out-the-old-ttm-based-dnsmon. > > There was little to no response by the WG to the earlier announcement. This makes both your WG Co-chairs and the NCC staff uncomfortable. After the WG co-chairs and NCC's DNSMON team discussed this last week, we agreed to set the end of this month as the final date for comments. Although we can work on the operating principle that silence implies consent, it would be better for all concerned if there were positive messages of support (or even ones of objection) on the list. Please respond. > > I'd appreciate it if you can comment on the list to indicate that you approve (or disapprove) of the current proposal and/or time-line. > > thanks in advance > > > From kranjbar at ripe.net Tue Jun 3 09:55:16 2014 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Tue, 3 Jun 2014 09:55:16 +0200 Subject: [dns-wg] WG comment on DNSMON changes In-Reply-To: <20140603064652.GP3706@x28.adm.denic.de> References: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> <20140603064652.GP3706@x28.adm.denic.de> Message-ID: Hello Peter, Please find my reply inline: On 03 Jun 2014, at 08:46, Peter Koch wrote: >> Old and new DNSMON will be available in parallel until end of June 2014. >> Configuration updates for existing zones will only be applied to the new DNSMON. >> Data collection in the old DNSMON service will be terminated by 1 July 2014. > > Given the increasingly painful dependency on the old TTM system, and taking > into account the warning time given to us customers, this transition deadline appears > reasonable to me: "no objection?. Thank you. > >> Data visualisation of (historic) measurement data provided by the old DNSMON will be available until the end of 2014. >> Raw data from the old DNSMON measurements will be kept available for a longer period. We are investigating ways to keep the old data available indefinitely. > > As I said at the microphone in Warsaw, I think it would be a plus not only to > maintain the old data, but also some way to visualize it, so some trends over > the years can be looked up (literally, not only dug in the raw data) in comparison. > That does not imply running an unmaintained or unmaintainable system indefinitely, > neither does it postpone the shutdown date for said system. Getting the viz back > in some "reasonable" time would be great. I fully agree. As suggested in Warsaw, we will keep running the old visualisations until RIPE 69 in London and will present the WG with real usage numbers and a few suggestions on how to move forward for a discussion and decision by the community. > > The other point I want to submit "in writing" is that I am not convinced by the > reasoning that led to giving up the two hour delay. The fact that "measurements > are public" or "anybody could set up their own measurements" neglects the very > value added by the (new) visualisation: not only is there an instant feedback > channel, but that channel is _the_ well reputed source. In 1980s' words: > the revolutionary army not only has a transmitter, but it has direct write > access to the 20:00 main news. > Doesn't give me sleepless nights, but I question the unilateral decision > based on that fatalistic reasoning. Yes and we are fully committed to implement what is proposed by the WG. Regardless of old TTM decommissioning timeline, we can always introduce a delay in the new DNSMON results. As a matter of fact, Robert has prepared an email explaining possible scenarios to kick off that discussion, we are just waiting to hear from the WG on the status of the timeline in order to be able to commit to implement any possible change to the new DNSMON. All the best, Kaveh. ? Kaveh Ranjbar, Chief Information Officer, RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Tue Jun 3 10:08:39 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 03 Jun 2014 10:08:39 +0200 Subject: [dns-wg] WG comment on DNSMON changes In-Reply-To: <20140603064652.GP3706@x28.adm.denic.de> References: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> <20140603064652.GP3706@x28.adm.denic.de> Message-ID: <538D8287.4000903@ripe.net> [RIPE NCC *Advisor* hat firmly on. Note this hat no longer bestows responsibility for the services under discussion] On 3.06.14 8:46 , Peter Koch wrote: > ... > As I said at the microphone in Warsaw, I think it would be a plus not only to > maintain the old data, but also some way to visualize it, so some trends over > the years can be looked up (literally, not only dug in the raw data) in comparison. > That does not imply running an unmaintained or unmaintainable system indefinitely, > neither does it postpone the shutdown date for said system. Getting the viz back > in some "reasonable" time would be great. Maintaining the old data available is easy and should be done. Continuing to visualise it will need resources out of a limited pool. It is up to the community to indicate relative priorities for the use of these resources. We use roadmaps http://roadmap.ripe.net/ to help with this. So I suggest to put this under "Requested" on the roadmap. Then we can discuss it in the context of other things we want to see. > > The other point I want to submit "in writing" is that I am not convinced by the > reasoning that led to giving up the two hour delay. The fact that "measurements > are public" or "anybody could set up their own measurements" neglects the very > value added by the (new) visualisation: not only is there an instant feedback > channel, but that channel is _the_ well reputed source. In 1980s' words: > the revolutionary army not only has a transmitter, but it has direct write > access to the 20:00 main news. > Doesn't give me sleepless nights, but I question the unilateral decision > based on that fatalistic reasoning. >From a distance I see four possibilities in order of increasing implementation cost: 1) Do nothing and visualise data in real time. 2) Add a blanket 2h delay to the dnsmon visualisation affecting all users. 3) Add a 2h delay to the dnsmon visualisation to all users that are not logged in as a RIPE NCC member. 4) Add a delay to publication of any RIPE Atlas measurement result in some form. In my humble opinion option 4 is unrealistic because of the complexities involved. If the community wants that it will add a lot of pain to current Atlas users and, more importantly, draw a lot of resources away from adding useful capabilities to RIPE Atlas. Option 2 makes dnsmon much less useful for operational folk to follow a "situation" in real time. I have found this capability invaluable several times in the past to judge the extent and impact of service deteriorations. I would not want to miss it. Therefore the real choice is between 1 and 3. I would be OK with 3 if that makes people like Peter sleep better. We just have to realise that the authorised group is rather large and therefore this is just a deterrent, a fig leaf if you will. If we agree that option 3 is what we want, let us put it on the roadmap too. Daniel [still wearing a hat without responsibility for this service] From dot at dotat.at Tue Jun 3 10:49:09 2014 From: dot at dotat.at (Tony Finch) Date: Tue, 3 Jun 2014 09:49:09 +0100 Subject: [dns-wg] b.root-servers.net AAAA, was Re: indulgence satiated In-Reply-To: <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> References: <20140602225727.GN3706@x28.adm.denic.de> <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> Message-ID: Bill, could you please fix the reverse DNS for 2001:500:84::/48 ? 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS DOT.RS.NET. 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS NS.ISI.EDU. 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS FORK.STH.DNSNODE.NET. $ dig +noall +authority ns 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. @z.arin.net. | sort | while read owner ttl class type ns; do for ip in 4 6; do echo IPv$ip $ns; dig -$ip -x 2001:500:84::b @$ns | egrep 'status|server'; done; done IPv4 DOT.RS.NET. ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19543 IPv6 DOT.RS.NET. ;; connection timed out; no servers could be reached IPv4 FORK.STH.DNSNODE.NET. ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46556 IPv6 FORK.STH.DNSNODE.NET. ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49477 IPv4 NS.ISI.EDU. ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52907 IPv6 NS.ISI.EDU. dig: couldn't get address for 'NS.ISI.EDU.': not found Tony. -- f.anthony.n.finch http://dotat.at/ West FitzRoy: Cyclonic becoming northwesterly 4 or 5, occasionally 6. Moderate, occasionally rough. Occasional rain at first. Moderate or good. From bmanning at isi.edu Tue Jun 3 11:12:51 2014 From: bmanning at isi.edu (manning bill) Date: Tue, 3 Jun 2014 02:12:51 -0700 Subject: [dns-wg] b.root-servers.net AAAA, was Re: indulgence satiated In-Reply-To: References: <20140602225727.GN3706@x28.adm.denic.de> <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> Message-ID: yes. /bill Neca eos omnes. Deus suos agnoscet. On 3June2014Tuesday, at 1:49, Tony Finch wrote: > Bill, could you please fix the reverse DNS for 2001:500:84::/48 ? > > 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS DOT.RS.NET. > 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS NS.ISI.EDU. > 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS FORK.STH.DNSNODE.NET. > > $ dig +noall +authority ns 4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. @z.arin.net. | > sort | > while read owner ttl class type ns; do > for ip in 4 6; do > echo IPv$ip $ns; > dig -$ip -x 2001:500:84::b @$ns | > egrep 'status|server'; > done; > done > IPv4 DOT.RS.NET. > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19543 > IPv6 DOT.RS.NET. > ;; connection timed out; no servers could be reached > IPv4 FORK.STH.DNSNODE.NET. > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 46556 > IPv6 FORK.STH.DNSNODE.NET. > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 49477 > IPv4 NS.ISI.EDU. > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52907 > IPv6 NS.ISI.EDU. > dig: couldn't get address for 'NS.ISI.EDU.': not found > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > West FitzRoy: Cyclonic becoming northwesterly 4 or 5, occasionally 6. > Moderate, occasionally rough. Occasional rain at first. Moderate or good. From Woeber at CC.UniVie.ac.at Tue Jun 3 12:41:39 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 03 Jun 2014 12:41:39 +0200 Subject: [dns-wg] WG comment on DNSMON changes In-Reply-To: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> References: <605F90ED-5A94-4475-B720-FA5B3878AEDC@rfc1035.com> Message-ID: <538DA663.5050609@CC.UniVie.ac.at> [wearing the hat of manager of an already decommissioned TTM Box] Jim Reid wrote: [...] > I would be grateful if you could express your approval or rejection of the > NCC's approach and proposed time-line. Full support, and fwiw, our box has already been decommissioned. Also, I do have he srong suspicion, that others have already been taken off-line too, or have not talked to mother ship for a while. So, be done with this asap is the best approach, imho. Regards, Wilfried From cet1 at cam.ac.uk Wed Jun 4 15:43:22 2014 From: cet1 at cam.ac.uk (Chris Thompson) Date: 04 Jun 2014 14:43:22 +0100 Subject: [dns-wg] b.root-servers.net AAAA, was Re: indulgence satiated In-Reply-To: References: <20140602225727.GN3706@x28.adm.denic.de> <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> Message-ID: On Jun 3 2014, Tony Finch wrote: >Bill, could you please fix the reverse DNS for 2001:500:84::/48 ? > >4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS DOT.RS.NET. >4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS NS.ISI.EDU. >4.8.0.0.0.0.5.0.1.0.0.2.ip6.arpa. 10800 IN NS FORK.STH.DNSNODE.NET. [which variously give REFUSED or SERVFAIL for the domain] This prompted me to wonder whether reverse lookups of other #.root-servers.net addresses work correctly. Alas, 2001:500:1::803f:235 for h.root-servers.net also gives SERVFAIL, but for a different reason. There is a DNSKEY/DS mismatch between 1.0.0.0.0.0.5.0.1.0.0.2.ip6.arpa and 5.0.1.0.0.2.ip6.arpa. See http://dnssec-debugger.verisignlabs.com/1.0.0.0.0.0.5.0.1.0.0.2.ip6.arpa -- Chris Thompson University of Cambridge Information Services, Email: cet1 at uis.cam.ac.uk Roger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. From jim at rfc1035.com Wed Jun 4 18:17:48 2014 From: jim at rfc1035.com (Jim Reid) Date: Wed, 4 Jun 2014 17:17:48 +0100 Subject: [dns-wg] DNSMON changes Message-ID: <4EC7B2F9-F473-442E-A00E-EB9901D11B54@rfc1035.com> Although the WG's response to the NCC's proposal has been disappointing, there have been three statements of support (one with qualifications) and none against. It had been stated that silence implied consent. Since no objections have been raised, the WG has reached a decision that has lightweight consensus. Though not a formal consensus as would be understood in the context of the PDP. Which is OK as this issue is not in PDP territory anyway. Therefore the NCC should proceed as planned and published at: https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-phasing-out-the-old-ttm-based-dnsmon The points made by Peter and Daniel are worth further discussion and I encourage you all to do that. On one hand, there could be some benefit in providing "backwards compatibility" for visualising old data. OTOH, this may put an unreasonable burden on the NCC by creating an open-ended commitment to support legacy cruft and result in users who can't/won't migrate to the current platform. It would be good for WG members to express their opinions about this. My personal view is somewhere inbetween: provide some way of visualising the old data if that can be done with minimal effort/resources from the NCC on a best efforts, unsupported basis. If that facility later dies, it dies and that's the end of the matter. YMMV. From jabley at hopcount.ca Wed Jun 4 18:32:30 2014 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 4 Jun 2014 12:32:30 -0400 Subject: [dns-wg] DNSMON changes In-Reply-To: <4EC7B2F9-F473-442E-A00E-EB9901D11B54@rfc1035.com> References: <4EC7B2F9-F473-442E-A00E-EB9901D11B54@rfc1035.com> Message-ID: <9A164180-E718-4623-AA14-4CD1C6A3C153@hopcount.ca> On 4 Jun 2014, at 12:17, Jim Reid wrote: > The points made by Peter and Daniel are worth further discussion and I encourage you all to do that. On one hand, there could be some benefit in providing "backwards compatibility" for visualising old data. OTOH, this may put an unreasonable burden on the NCC by creating an open-ended commitment to support legacy cruft and result in users who can't/won't migrate to the current platform. It would be good for WG members to express their opinions about this. On that particular point, the important thing is for the data behind the old dnsmon to be available, together with a clear description of how it was collected and how it is stored (file formats, directory structure, filenames, etc). I don't think it's necessary for the NCC to burn devops cycles on making visualisations of the old data available, either in exact old-DNSMON form or in any other form. If anybody really needs a visualisation of existing data, they can make their own so long as the data is available. I don't think there's a practical difference between the RIPE NCC making data available directly or providing it to DNS-OARC (say) for storage and visualisation. Either way would work for me. > My personal view is somewhere inbetween: provide some way of visualising the old data if that can be done with minimal effort/resources from the NCC on a best efforts, unsupported basis. If that facility later dies, it dies and that's the end of the matter. YMMV. I would like to see a commitment to the data being made available indefinitely. I don't like throwing away historical data. Joe From cet1 at cam.ac.uk Thu Jun 5 13:42:43 2014 From: cet1 at cam.ac.uk (Chris Thompson) Date: 05 Jun 2014 12:42:43 +0100 Subject: [dns-wg] b.root-servers.net AAAA, was Re: indulgence satiated In-Reply-To: References: <20140602225727.GN3706@x28.adm.denic.de> <5DF6D86E-9B35-4306-A61C-B98424845952@isi.edu> Message-ID: On Jun 4 2014, I wrote: [...] >This prompted me to wonder whether reverse lookups of other #.root-servers.net >addresses work correctly. Alas, 2001:500:1::803f:235 for h.root-servers.net >also gives SERVFAIL, but for a different reason. There is a DNSKEY/DS mismatch >between 1.0.0.0.0.0.5.0.1.0.0.2.ip6.arpa and 5.0.1.0.0.2.ip6.arpa. See > >http://dnssec-debugger.verisignlabs.com/1.0.0.0.0.0.5.0.1.0.0.2.ip6.arpa Now fixed (by update of DS record in parent zone). E-mail to the SOA.rname address got a quick and accurate response. Back to waiting for reverse lookup of 2001:500:84::b to work... -- Chris Thompson University of Cambridge Information Services, Email: cet1 at uis.cam.ac.uk Roger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. From jacques.latour at cira.ca Fri Jun 6 15:27:19 2014 From: jacques.latour at cira.ca (Jacques Latour) Date: Fri, 6 Jun 2014 13:27:19 +0000 Subject: [dns-wg] DNSMON changes In-Reply-To: <9A164180-E718-4623-AA14-4CD1C6A3C153@hopcount.ca> References: <4EC7B2F9-F473-442E-A00E-EB9901D11B54@rfc1035.com> <9A164180-E718-4623-AA14-4CD1C6A3C153@hopcount.ca> Message-ID: +1 turning over historical to DNS-OARC. >From .ca point of view, we don't need "backwards compatibility" in the new DNSMON tool, which is pretty good BTW. Before DNSMON was just a monitoring tool, now it's a platform for innovation :-) Jack > -----Original Message----- > From: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] On Behalf > Of Joe Abley > Sent: June-04-14 12:33 PM > To: Jim Reid > Cc: RIPE DNS WG > Subject: Re: [dns-wg] DNSMON changes > > > On 4 Jun 2014, at 12:17, Jim Reid wrote: > > > The points made by Peter and Daniel are worth further discussion and I > encourage you all to do that. On one hand, there could be some benefit in > providing "backwards compatibility" for visualising old data. OTOH, this may put > an unreasonable burden on the NCC by creating an open-ended commitment to > support legacy cruft and result in users who can't/won't migrate to the current > platform. It would be good for WG members to express their opinions about > this. > > On that particular point, the important thing is for the data behind the old > dnsmon to be available, together with a clear description of how it was collected > and how it is stored (file formats, directory structure, filenames, etc). > > I don't think it's necessary for the NCC to burn devops cycles on making > visualisations of the old data available, either in exact old-DNSMON form or in > any other form. If anybody really needs a visualisation of existing data, they can > make their own so long as the data is available. > > I don't think there's a practical difference between the RIPE NCC making data > available directly or providing it to DNS-OARC (say) for storage and visualisation. > Either way would work for me. > > > My personal view is somewhere inbetween: provide some way of visualising > the old data if that can be done with minimal effort/resources from the NCC on > a best efforts, unsupported basis. If that facility later dies, it dies and that's the > end of the matter. YMMV. > > I would like to see a commitment to the data being made available indefinitely. I > don't like throwing away historical data. > > > Joe From robert at ripe.net Tue Jun 10 22:11:54 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 10 Jun 2014 22:11:54 +0200 Subject: [dns-wg] DNSMON visualisation delay In-Reply-To: <537C9076.9080808@ripe.net> References: <537C9076.9080808@ripe.net> Message-ID: <5397668A.3070204@ripe.net> Dear DNS Working Group, At RIPE68 we were asked to "send an email to the mailing-list about advantages and disadvantages of delayed and non-delayed versions of DNSMON [visualisation], specifically related to the management of the software and the ongoing maintenance of the legacy systems that you want to retire". As many of you know, the old DNSMON service had an artificial delay of a couple of hours for visualising the incoming data, for everyone except a specific "DNSMON customers" group. With the changes to the service model as of 2013 there is no good definition of "DNSMON customers" any more. Also, the current DNSMON implementation does not apply any artificial delays, which in practice means all data points show up in the graphs within 10-15 minutes. As Daniel projected a few days ago, we see some realistic options regarding this visualisation delay: === 1. No changes to what the service offers now; ie. graphs will show results with minimum delay Development effort: none Pro: simplest solution Con: this is perceived by some to be "helping potential attackers" by making it easy to observe the effects of an attack on the DNS infrastructure === 2. Introduction of an artificial delay to *all* users, regardless of NCC member/non-member, or login status (known an anonymous users) Development effort: minimal (est. couple of developer days) Pro: not helping potential bad guys monitoring the zones/servers in real time Con: not helping the good guys monitoring the zones/servers in real time either === 3. Introduction of an artificial delay to users in general, except for RIPE NCC members. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by the existing LIR portal mechanism. Development effort: minimal (est. couple of developer days) Pro: RIPE NCC members have early access to visualisations, others don't Note: the current number of SSO account belonging to RIPE NCC members is ~24000 Note: we may or may not help the attacker, depending on whether (s)he is a member of the RIPE NCC or not === 4. Introduction of an artificial delay to users in general, except for a specially designated DNSMON customers (zone operators) group. Authentication is done by RIPE NCC Access (Single Sign-On), authorization is controlled by a vetting process managed by the RIPE NCC. Development effort: moderate (est. more than a couple of developer days) Con: administration overhead is non-trivial -- we'll have to establish and keep tracking who is in the privileged group and who isn't; with people joining/leaving organisations this could be tricky and diverge from reality. Pro: members of the special group have early access to visualisations, others don't Note: people in this special group can come from organisations which may or may not be RIPE NCC members. Note: we may or may not help the attacker, depending on whether (s)he is a member of this group or not Please give us guidance about your your preferred solution by replying to this mail to the list. Regards, Robert Kisteleki RIPE NCC From daniel.karrenberg at ripe.net Wed Jun 11 08:49:46 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 11 Jun 2014 08:49:46 +0200 Subject: [dns-wg] DNSMON visualisation delay In-Reply-To: <5397668A.3070204@ripe.net> References: <537C9076.9080808@ripe.net> <5397668A.3070204@ripe.net> Message-ID: <5397FC0A.2030208@ripe.net> [With no hat on my personal head] I prefer option 1. I could live with option 3 if a large number of people consider it necessary. Option 2 should not be chosen because it makes the dnsmon visualisations much less useful in dealing with incidents. Option 4 has obviously been invented by the "complications department". It will do nothing but waste considerable effort by both the RIPE NCC and the community. Daniel From ripe-dnswg at johnbond.org Wed Jun 11 13:27:30 2014 From: ripe-dnswg at johnbond.org (John) Date: Wed, 11 Jun 2014 13:27:30 +0200 Subject: [dns-wg] DNSMON visualisation delay In-Reply-To: <5397668A.3070204@ripe.net> References: <537C9076.9080808@ripe.net> <5397668A.3070204@ripe.net> Message-ID: <53983D22.40302@johnbond.org> My Preference is for option 1. I think option 2 would do more damage then good. Option 3 and 4 both seem like a waste of time and effort. The perceived threat is from a technical audience, as the underlining measurement data would still be available, in real time, it would be trivial for such an audience to make use of it. Furthermore as the visualization is all client side they could mirror the web page and run it locally with more recent data (something i would consider doing if option 2 was implemented) John From tsinha at umd.edu Wed Jun 18 21:17:26 2014 From: tsinha at umd.edu (Tripti Sinha) Date: Wed, 18 Jun 2014 19:17:26 +0000 Subject: [dns-wg] Call for joining RSSAC Caucus Message-ID: <0EE30C07F283B54F9C30C8697E9FD12E710D7388@OITMX1001.AD.UMD.EDU> Greetings, If you are interested in participating at ICANN's Root Server System Advisory Committee (https://www.icann.org/resources/pages/charter-2013-07-14-en) as a Caucus member, please kindly read the relevant information and Caucus document published at https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en and submit your statement of interest to rssac-membership at icann.org. The RSSAC executive is working on publishing the final version of "Procedures documents" and at the moment is establishing the Caucus with a few work items ready to be discussed by the Caucus. If you would like to volunteer please kindly indicate those intentions known by sending an email to rssac-membership at icann.org. Kind Regards, Kaveh Ranjbar, RSSAC Membership Committee Chair Tripti Sinha, RSSAC Membership Committee Member Paul Vixie, RSSAC Membership Committee Member -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsinha at umd.edu Wed Jun 25 01:09:11 2014 From: tsinha at umd.edu (Tripti Sinha) Date: Tue, 24 Jun 2014 23:09:11 +0000 Subject: [dns-wg] Call for joining RSSAC Caucus Message-ID: Dear colleagues, This is a friendly reminder to apply for RSSAC Caucus membership. The cut-off date for first round of membership is end of June, so please kindly submit your statement of interest before 1st of July to rssac-membership at icann.org. On Monday 23rd of June RSSAC had its public session at ICANN 50 and it was announced that the first face to face caucus meeting will be held during IETF 90 in Toronto. Kind regards, Tripti Sinha on behalf of RSSAC Caucus membership committee -------------- next part -------------- An HTML attachment was scrubbed... URL: