[Request] System tags for DNS resolution
[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?] It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance, system-dns-works (modeled on IPv6's system tag) would be fine. Or may be system-dns-resolver-works (longer but more accurate). For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL. [Is the maintainer of the probe automatically notified when there is such an issue?]
On 11 Nov 2015, at 17:36, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?]
It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance,
system-dns-works (modeled on IPv6's system tag) would be fine. Or may be system-dns-resolver-works (longer but more accurate).
For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL.
I would like to support this request. I will use it. Additionally would also be nice if we can identify whether the used resolver is a local / open resolver. Latency measurements that rely on DNS resolution may get affected depending on what is used. Perhaps, easiest would be to just report what resolver is used and let the identification be left for the data analysis phase.
[Is the maintainer of the probe automatically notified when there is such an issue?]
Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================
Hi Stephane, On 11/11/2015 17:36, Stephane Bortzmeyer wrote:
[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?]
You can also send requests to atlas@ripe.net, where they will be automatically added to our issue queue. There's nothing intrinsically wrong with sending things to the list though, especially because it allows other users to chime in and say that they've noticed similar things before/they have an explanation/a workaround/etc.
It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance,
system-dns-works (modeled on IPv6's system tag) would be fine. Or may be system-dns-resolver-works (longer but more accurate).
For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL.
You may have noticed that we apply "system-resolves-a[aaa]-correctly" to probes. This happens when we find that at least one of their DNS resolvers correctly resolves one of a few specific records at least partially over a 4 hour period. We decided to be specific and shy away from claims like "DNS works" because that could be considered a rather strong claim. The above probes are mostly tagged as "resolves-a[aaa]-correctly" because they managed to resolve certain A records (e.g. MSM ID 1698856). Can you provide the measurement ID(s) where you see the REFUSED and SERVFAIL responses?
[Is the maintainer of the probe automatically notified when there is such an issue?]
If there is a tagging change, then we send an in-site RIPE Atlas message to the user. We don't currently provide the option of emailing users on such changes, but it's something that we would consider if there is support for such an idea. Regards, Chris
On Thu, Nov 12, 2015 at 10:41:03AM +0100, Chris Amin <camin@ripe.net> wrote a message of 75 lines which said:
For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL. ... The above probes are mostly tagged as "resolves-a[aaa]-correctly" because they managed to resolve certain A records (e.g. MSM ID 1698856). Can you provide the measurement ID(s) where you see the REFUSED and SERVFAIL responses?
Probes 19948, 20065 now seems OK. But 16659, 17072, 17620, 17854 still return REFUSED: measurements #2928193 and #2928199.
On 12/11/2015 22:45, Stephane Bortzmeyer wrote:
For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL. ... The above probes are mostly tagged as "resolves-a[aaa]-correctly" because they managed to resolve certain A records (e.g. MSM ID 1698856). Can you provide the measurement ID(s) where you see the REFUSED and SERVFAIL responses?
Probes 19948, 20065 now seems OK. But 16659, 17072, 17620, 17854 still return REFUSED: measurements #2928193 and #2928199.
I think what is happening here is that all of those probes except for 17854 have at least *one* resolver which does respond to queries. 17854 seems to have no resolvers responding successfully, which is why it has the tag "Doesn't Resolve A". This is because the "Resolves A Correctly" tag is really "Resolves A Correctly (for at least one resolver) (for at least one pre-designated stable target)". We have discussed internally creating another set of tags which say something about the reliability and stability of DNS resolution, rather than our current liberal tags which basically claim something like "you will probably get *some* usable results from this probe". I would be interested to hear your (or anybody else's) thoughts on whether you would use such a reliable/stable DNS resolution tag, and what kind of criteria you would expect for it to be applied. Cheers, Chris
On Sun, Nov 15, 2015 at 09:32:09AM +0200, Chris Amin <camin@ripe.net> wrote a message of 64 lines which said:
I think what is happening here is that all of those probes except for 17854 have at least *one* resolver which does respond to queries.
OK, I get it. I modified resolve-name <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/master/resolve-name.py> to continue if the fist resolver returns REFUSED or SERVFAIL <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/commit/d67a24f28db00cccca432731915b5811e16619c4> Thanks for the explanations.
why it has the tag "Doesn't Resolve A".
Do note that many tags documented in <https://atlas.ripe.net/docs/probe-tags/#system-tags> do not work (reported as [ripe.net #1195138]).
I would be interested to hear your (or anybody else's) thoughts on whether you would use such a reliable/stable DNS resolution tag, and what kind of criteria you would expect for it to be applied.
The current system is not bad, once it is explained and the above bug fixed.
Hi Stephane, all, On 11-nov.-15 17:36, Stephane Bortzmeyer wrote:
[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?]
You are correct, to some extent -- there is a manual processing involved in the middle ;-) It's good that you ask for features on the list, where people can comment on your feature request & add their own use cases (just like Vaibhav just did); then I collect them, we discuss them internally & prioritize them, and they end up on the roadmap: https://atlas.ripe.net/docs/roadmap/ (notice the new URL & new formatting - we are in the process of migrating the roadmap from the old URL to the new one...)
[Is the maintainer of the probe automatically notified when there is such an issue?]
There is something similar already on the roadmap: "Provide additional information to the probe owner about the probe: After analysis of measurements, results will be added to a comments page for the specified probe. This helps the hosts to identify issues and fix them." I will add your additional request to this one. Keep them coming :) Regards, Vesna and thanks for tagging it with [Request] -- good practice :)
participants (4)
-
Bajpai, Vaibhav -
Chris Amin -
Stephane Bortzmeyer -
Vesna Manojlovic