Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. As announced last year by Kaveh Ranjbar in the RIPE Labs article, "Future of RIPE NCC Technical Services", we are in the process of integrating DNSMON within RIPE Atlas, using RIPE Atlas anchors as vantage points. The beta version of the new DNSMON will be available next week, when we will invite you all to try the new service and provide your feedback. In the meantime, we wanted to let you know about some of the changes in the new DNSMON service: New interactive graphs that will allow you to zoom in on interesting details, such as servers, vantage points, and time intervals. Support of TCP queries. Data delay for non-DNSMON users will not be replicated because the measurements performed by RIPE Atlas anchors for the new DNSMON are public measurements. Therefore, the results will also be publicly available. Server-side generated RRD graphs will not be migrated, as the client-side visualisations provide a comparable replacement. However, the existing service will keep working in parallel and decommissioning plans will be discussed with the community. In the meantime, the graphs and data from the old system will still be available. We will publish a RIPE Labs article with more details when the new service becomes available next week. We’re confident the new DNSMON will continue to meet your needs and hope you'll be pleased with the new features. Please stay tuned for more information. Kind regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC
Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. We are in the process of integrating DNSMON within RIPE Atlas and the beta version of the new DNSMON is now publicly available: https://atlas.ripe.net/dnsmon We have also published a RIPE Labs article detailing what’s changed in the new DNSMON: https://labs.ripe.net/Members/fatemah_mafi/an-updated-dns-monitoring-service We invite you all to try the new service and provide your feedback. We’re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. Please send your comments and questions to the DNS Working Group Mailing List at dns-wg@ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC
We invite you all to try the new service and provide your feedback. Were confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. It doesn't come anywhere close to the old service. E.g., the functionality of <http://dnsmon.ripe.net/dns-servmon/server/> is missing. The UI page <https://atlas.ripe.net/dnsmon/doc/ui> is garbled. All in all this is pretty bad. jaap
Jaap,
-----Original Message----- From: dnsmon-contact-bounces@ripe.net [mailto:dnsmon-contact- bounces@ripe.net] On Behalf Of Jaap Akkerhuis Sent: Wednesday, March 19, 2014 10:50 AM To: Vesna Manojlovic Cc: ncc-services-wg@ripe.net; dns-wg@ripe.net; RIPE Atlas People; dnsmon-contact@ripe.net; dnsmon-user@ripe.net; Measurement Analysis and Tools Working Group Subject: Re: [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available
We invite you all to try the new service and provide your feedback. We're confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features.
It doesn't come anywhere close to the old service. E.g., the functionality of <http://dnsmon.ripe.net/dns-servmon/server/> is missing.
That's what I thought at first but actually it is there it just takes a little finding. Click on the TLD and you will get a list of servers down the left, if you then click on a server you will get something that looks very similar to the old server view. There are two things that I would really like to see: 1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers. 2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions. Brett Nominet UK.
-----Original Message----- From: dns-wg-bounces@ripe.net [mailto:dns-wg-bounces@ripe.net] On Behalf Of Brett Carr Sent: Wednesday, March 19, 2014 10:58 AM To: Jaap Akkerhuis; Vesna Manojlovic Cc: ncc-services-wg@ripe.net; dns-wg@ripe.net; RIPE Atlas People; dnsmon-contact@ripe.net; dnsmon-user@ripe.net; Measurement Analysis and Tools Working Group Subject: Re: [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available {Sender Address Possibly Forged}
2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions.
To be slightly more specific, https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-s... Something more DNS specific but similar to the above would be very useful. Brett
Brett, On 2014.03.19. 12:02, Brett Carr wrote:
There are two things that I would really like to see:
1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers.
All the data for DNSMON are collected by RIPE Atlas as ongoing, public DNS measurements. The measurement IDs are exposed in the DNSMON interface ("Show RIPE Atlas measurements" button). There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time.
2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions.
To be slightly more specific,
https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-s...
Something more DNS specific but similar to the above would be very useful.
This is entirely possible. In order to implement it, we'd like to keep the mechanism described in the article, but extend it to support DNS. Still, because determining success/failure of DNS measurements is a bit more tricky than pings, the details need some discussion. I invite all to have that discussion on the MAT-WG mailing list (also on cc now). Regards, Robert
Brett
On 20 Mar 2014, at 08:49, Robert Kisteleki <robert@ripe.net> wrote:
There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time.
It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. Perhaps we can have the WG discuss this in Warsaw.
On 20 Mar 2014, at 10:21, Jim Reid <jim@rfc1035.com> wrote:
On 20 Mar 2014, at 08:49, Robert Kisteleki <robert@ripe.net> wrote:
There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time.
It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API.
It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding.
Perhaps we can have the WG discuss this in Warsaw.
I think that this would be an excellent use of some time in Warsaw. Brett
On 2014.03.20. 11:21, Jim Reid wrote:
On 20 Mar 2014, at 08:49, Robert Kisteleki <robert@ripe.net> wrote:
There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time.
It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API.
It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding.
Perhaps we can have the WG discuss this in Warsaw.
Jim, I don't really mind where the discussion happens, I'm more interested in making sure that it does happen, with that the interested parties are involved. And I was trying to avoid having multiple discussions on multiple mailing lists so named one: Atlas, because it will be an Atlas feature at the end of the process. Regards, Robert
Robert Kisteleki wrote:
On 2014.03.20. 11:21, Jim Reid wrote:
On 20 Mar 2014, at 08:49, Robert Kisteleki <robert@ripe.net> wrote:
There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time.
It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API.
It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding.
Perhaps we can have the WG discuss this in Warsaw.
Perhaps a prep discussion from the DNS pov and then a follow-up in MAT on Thursday? Wilfried
Jim,
I don't really mind where the discussion happens, I'm more interested in making sure that it does happen, with that the interested parties are involved. And I was trying to avoid having multiple discussions on multiple mailing lists so named one: Atlas, because it will be an Atlas feature at the end of the process.
Regards, Robert
Dear Jaap, Brett, I will restrict the reply to the dns-wg list. On 19-mrt.-14 11:57, Brett Carr wrote:
Jaap,
-----Original Message----- Sent: Wednesday, March 19, 2014 10:50 AM To: Vesna Manojlovic Subject: Re: [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available
We invite you all to try the new service and provide your feedback. We're confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features.
It doesn't come anywhere close to the old service. E.g., the functionality of <http://dnsmon.ripe.net/dns-servmon/server/> is missing.
That's what I thought at first but actually it is there it just takes a little finding.
Thank you for your feedback - I will take this as a feature request to improve navigation.
There are two things that I would really like to see:
1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers.
For RIPE Atlas, we have developed "status checks" based on pings: https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-s... I will take your comment as a feature request to develop ""Atlas DNS status checks", and I am inviting you and other DNS experts to tell us the details of how these alters should be generated.
2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions.
Thanks again, I will add it to the list of feature requests. Regards, Vesna
I will restrict the reply to the dns-wg list. OK. >> It doesn't come anywhere close to the old service. E.g., the >> functionality of <http://dnsmon.ripe.net/dns-servmon/server/> is >> missing. >> > > That's what I thought at first but actually it is there it just takes a little finding. Thank you for your feedback - I will take this as a feature request to improve navigation. And document things clearly. I'm tired of second guessing what things are supposed to do. The broken UI page didn't help either (although it currently seems fixed). It would be nice to have "server view" and "zone view" being explicitly explained just like "probe view". It'll help novice users. jaap
Dear Jaap, On 2014.03.19. 11:49, Jaap Akkerhuis wrote:
We invite you all to try the new service and provide your feedback. We’re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features.
It doesn't come anywhere close to the old service. E.g., the functionality of <http://dnsmon.ripe.net/dns-servmon/server/> is missing.
This server view exists in the new implementation too. One can reach it from the zone view, by clicking on the name on a particular server. We prepared for this use case since people are mostly interested in the servers of a (their) particular zone, not an alphabetical list. That said, we can make such a listing page if there's a need for it.
The UI page <https://atlas.ripe.net/dnsmon/doc/ui> is garbled.
That was an oops, but it is fixed already. Regards, Robert
All in all this is pretty bad.
jaap
Anything that can be done about the bad AS48294 probe, that doesn’t actually have IPv6 connectivity? Can you have it stop reporting its lack of IPv6 connectivity, or exclude it from results, or something? It makes it hard to see what’s going on in overview results, if it’s constantly adding to the floor of measurements it contributes to. Obviously, I’d prefer a generalized solution that applied to all such non-functional probes. Thanks. -Bill
On 2014.09.08. 15:17, Bill Woodcock wrote:
Anything that can be done about the bad AS48294 probe, that doesn’t actually have IPv6 connectivity? Can you have it stop reporting its lack of IPv6 connectivity, or exclude it from results, or something? It makes it hard to see what’s going on in overview results, if it’s constantly adding to the floor of measurements it contributes to. Obviously, I’d prefer a generalized solution that applied to all such non-functional probes.
Thanks.
-Bill
Hello, (keeping only the DNS-WG in the address list) Even though we ask for stable IPv4+IPv6 connectivity from all Anchor hosts, reality is that some are more flaky than others. At the moment we don't have a clear policy on whether to remove these from DNSMON measurements, and if so, when. (Is an hour of non-working a good trigger? A day, a week, a month, a year? Should it be put back if it behaves again? Should the historic results be changed for the affected period by this removal?) In virtually all such cases we're in contact with the host to resolve the issue. As you can imagine, sometimes it takes time. What you can do now is exclude particular anchor from the visualisation (press shift in the server view). This only affects that view in the UI, and does not exclude that probe from the aggregate results. Regards, Robert
participants (8)
-
Bill Woodcock -
Brett Carr -
Jaap Akkerhuis -
Jim Reid -
Robert Kisteleki -
Vesna Manojlovic -
Vesna Manojlovic
-
Wilfried Woeber