From romeo.zwart at ripe.net Mon Jul 7 13:06:06 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Mon, 07 Jul 2014 13:06:06 +0200 Subject: [dns-wg] Closure of Test Traffic Measurements Service and Changes to the DNS Monitoring Service In-Reply-To: <53B3E031.3080502@ripe.net> References: <53B2D429.9030109@ripe.net> <84D9982D-EF0C-479D-8067-B7B50201AACD@ripe.net> <53B3E031.3080502@ripe.net> Message-ID: <53BA7F1E.2080508@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, As of 1 July 2014, the old DNS Monitoring Service (DNSMON), based on the Test Traffic Measurements Service (TTM), has stopped receiving updates to its data. The new DNSMON interface is available at: https://atlas.ripe.net/dnsmon All historic DNSMON visualisations will remain available at: http://dnsmon-old.ripe.net We will keep these visualisations of the historic data available until at least the end of 2014. Existing URLs that point to specific periods or zones in the old DNSMON (for example http://dnsmon.ripe.net/dns-servmon/server/) will be redirected and will continue to work for as long as the old DNSMON visualisation servers are maintained. As discussed at the RIPE 68 DNS Working Group session in Warsaw, the RIPE NCC will provide some statistics on usage of the old visualisations at RIPE 69 in London. The DNS Working Group will be consulted regarding the further maintenance or possible decommissioning of these visualisations. Background The RIPE NCC announced a new version of DNSMON in March 2014 and informed the community that the old DNSMON would be phased out. The old DNSMON was dependent upon measurements run as part of TTM, which was in the last phase of its existence. TTM has been decommissioned, as announced previously, on 1 July 2014. In line with the closure of TTM, data collection in the old DNSMON has also been terminated from that same date. These changes are in line with our previous communications, notably the RIPE Labs article "Timeline for Phasing Out the Old TTM-Based DNSMON": https://labs.ripe.net/Members/romeo_zwart/copy_of_proposed-time-lines-for-phasing-out-the-old-ttm-based-dnsmon Romeo Zwart RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO6fx4ACgkQGRL9suBV+eos8ACfUMImGvgAV9rJ1bxzLbt4hLmv HewAni2DYCGSLAWOAhYREtCsprGj8jKR =gI+O -----END PGP SIGNATURE----- From shane at time-travellers.org Tue Jul 8 18:20:41 2014 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 8 Jul 2014 18:20:41 +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: <20140708182041.0968e296@vulcan> Robert, Replying to an old mail, but I suppose that's okay. :-P On Tue, 10 Jun 2014 22:11:54 +0200 Robert Kisteleki wrote: > === 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 Yes please. As far as using DNSMON as a tool to measure the effectiveness of attack, anyone able to create a DDoS can use their attack hosts to measure the success of their attack as well, in real time, so that doesn't make much sense to me. (I admit that other types of DoS might benefit from this telemetry - for example someone probing the effectiveness of a newly-minted 0-day exploit.) Operationally any kind of sign-on requirement is a hassle. It means that half the people that get an internal e-mail with a link to a DNSMON graph aren't going to be able to see it, and many of the others are going to have to dig around in wiki's and old e-mail to find credentials. It means I can't paste a link into a chat with someone who doesn't have DNSMON access but could help me with the problem. Bah, humbug. Cheers, -- Shane From robert at ripe.net Mon Jul 14 17:37:24 2014 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 14 Jul 2014 17:37:24 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements Message-ID: <53C3F934.6030207@ripe.net> Dear DNSMON users, Due to the growth of numbers in active RIPE Atlas anchors, we started involving more anchors from outside our service region in DNSMON measurements. This has a natural effect on the visualisations: the newly involved anchors don't have a measurement history yet, so they show up as "no data" before the addition. We're introducing these changes gradually for the monitored zones so the changes are not yet visible everywhere. Regards, Robert Kisteleki From pk at DENIC.DE Tue Jul 15 10:12:51 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 15 Jul 2014 10:12:51 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements In-Reply-To: <53C3F934.6030207@ripe.net> References: <53C3F934.6030207@ripe.net> Message-ID: <20140715081251.GM27563@x28.adm.denic.de> Hi Robert, > Due to the growth of numbers in active RIPE Atlas anchors, we started > involving more anchors from outside our service region in DNSMON > measurements. This has a natural effect on the visualisations: the newly > involved anchors don't have a measurement history yet, so they show up as > "no data" before the addition. thanks for the heads up and good to see the measurement network is growing! Could you please elaborate a bit on how you select the anchors per TLD/domain monitored and what your thoughts re stability (of the anchor set over time) and comparability (of the sets used for one domain vs another) are? I wonder whether it would scale to run all measurements from all the anchors and then only "customize" the covering set for the display. -Peter From robert at ripe.net Tue Jul 15 14:01:47 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 15 Jul 2014 14:01:47 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements In-Reply-To: <20140715081251.GM27563@x28.adm.denic.de> References: <53C3F934.6030207@ripe.net> <20140715081251.GM27563@x28.adm.denic.de> Message-ID: <53C5182B.2010609@ripe.net> On 2014.07.15. 10:12, Peter Koch wrote: > Hi Robert, > >> Due to the growth of numbers in active RIPE Atlas anchors, we started >> involving more anchors from outside our service region in DNSMON >> measurements. This has a natural effect on the visualisations: the newly >> involved anchors don't have a measurement history yet, so they show up as >> "no data" before the addition. > > thanks for the heads up and good to see the measurement network is growing! > Could you please elaborate a bit on how you select the anchors per TLD/domain > monitored and what your thoughts re stability (of the anchor set over time) > and comparability (of the sets used for one domain vs another) are? > I wonder whether it would scale to run all measurements from all the > anchors and then only "customize" the covering set for the display. > > -Peter Hi Peter, all, For consistency reasons we're trying to involve the same set of anchors for monitoring each zone. This will probably not scale forever, but we'll try to do this as long as we can. Earlier we've heard from operators that they'd appreciate if we used a wider set of anchors, eg. add more from outside the EU. So this time we added the following: 1) us-sea-as2914, Seattle, ID 6065 2) us-dal-as7366, Dallas, ID 6067 3) us-atl-as2914, Atlanta, ID 6066 4) us-mia-as2914, Miami, ID 6062 5) uy-mvd-as28000, Montevideo, ID 6054 6) za-jnb-as10474, Johannesburg, ID 6053 7) tn-tun-as5438, Tunis, ID 6051 8) au-mel-as38796, Melbourne, ID 6044 9) au-bne-as4608, Brisbane, ID 6055 10) ru-mow-as47764, Moscow, ID 6046 The number of anchors is expected to grow to an unknown (but hopefully high) number, meaning there has to be a cutoff at some reasonable point. Indeed some anchors are more stable than others. That's not a new phenomenon, I believe it happened to TTM boxes as well. As for what to do with anchors that consistently fail or are down for along time: we don't have a policy defined yet. I'd expect that if a particular anchor proves to be useless for this purpose, then we'll remove it from the pool. (But, after how long? 3-6-12 months, 1 year? We're happy to receive advice from the community about this.) Hope this helps, Robert From daniel.karrenberg at ripe.net Tue Jul 15 14:15:33 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 15 Jul 2014 14:15:33 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements In-Reply-To: <53C5182B.2010609@ripe.net> References: <53C3F934.6030207@ripe.net> <20140715081251.GM27563@x28.adm.denic.de> <53C5182B.2010609@ripe.net> Message-ID: <53C51B65.3050904@ripe.net> On 15.07.14 14:01 , Robert Kisteleki wrote: > ... > Indeed some anchors are more stable than others. That's not a new > phenomenon, I believe it happened to TTM boxes as well. As for what to do > with anchors that consistently fail or are down for along time: we don't > have a policy defined yet. I'd expect that if a particular anchor proves to > be useless for this purpose, then we'll remove it from the pool. (But, after > how long? 3-6-12 months, 1 year? We're happy to receive advice from the > community about this.) This discussion shows that RIPE Atlas has reached a scale that makes it necessary to devise quite dynamic ways of "calibrating" measurements. The number of anchors will soon grow such that this is also necessary for anchors. Personally I believe that in the long run it will be necessary to provide calibration data that can be used to interpret the results of measurements and to dynamically change the pools of probes used for specific measurements. For instance, if a probe/anchor suddenly shows an increase in the variance of all its results this may be a network phenomenon or a measurement artefact. In any case it *may* be reason to disregard or scale the results when using them in specific measurements and studies. I am currently working on this. This is slow work because it is not straightforward and also because I have had some unexpected other duties in the governance area. Daniel From pk at DENIC.DE Tue Jul 15 15:09:15 2014 From: pk at DENIC.DE (Peter Koch) Date: Tue, 15 Jul 2014 15:09:15 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements In-Reply-To: <53C5182B.2010609@ripe.net> References: <53C3F934.6030207@ripe.net> <20140715081251.GM27563@x28.adm.denic.de> <53C5182B.2010609@ripe.net> Message-ID: <20140715130915.GT27563@x28.adm.denic.de> Hi Robert, > For consistency reasons we're trying to involve the same set of anchors for > monitoring each zone. This will probably not scale forever, but we'll try to > do this as long as we can. sounds good. > Earlier we've heard from operators that they'd appreciate if we used a wider > set of anchors, eg. add more from outside the EU. So this time we added the > following: [...] indeed, making the measurements less Euro centric is appreciated. > Indeed some anchors are more stable than others. That's not a new > phenomenon, I believe it happened to TTM boxes as well. As for what to do > with anchors that consistently fail or are down for along time: we don't > have a policy defined yet. I'd expect that if a particular anchor proves to > be useless for this purpose, then we'll remove it from the pool. (But, after Well, if an anchor becomes unstable in some sense, it's probably useless for the whole project? My question was more aiming at the stability of the set of anchors as such rather than the operational stability of individual anchors. Thanks for the clarifications. -Peter From Woeber at CC.UniVie.ac.at Wed Jul 16 14:13:53 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 16 Jul 2014 14:13:53 +0200 Subject: [dns-wg] More anchors involved in DNSMON measurements In-Reply-To: <20140715130915.GT27563@x28.adm.denic.de> References: <53C3F934.6030207@ripe.net> <20140715081251.GM27563@x28.adm.denic.de> <53C5182B.2010609@ripe.net> <20140715130915.GT27563@x28.adm.denic.de> Message-ID: <53C66C81.8040705@CC.UniVie.ac.at> Peter Koch wrote: [...] > Well, if an anchor becomes unstable in some sense, Which reminds me that I should follow up on the individual probes' stability aspect, both the small ones as well as anchor ones. But I presume this discussion is better placed in the general list? Wilfried > [...] > > -Peter >