Re: [atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

On Sun, Nov 15, 2015 at 09:32:09AM +0200,
 Chris Amin  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

to continue if the fist resolver returns REFUSED or SERVFAIL

Thanks for the explanations.

> why it has the tag "Doesn't Resolve A".

Do note that many tags documented in
 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.

Re: [atlas] [Request] System tags for DNS resolution

[Chris Amin]

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



signature.asc
Description: OpenPGP digital signature

Re: [atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

On Thu, Nov 12, 2015 at 10:41:03AM +0100,
 Chris Amin  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.

Re: [atlas] [Request] System tags for DNS resolution

[Bajpai, Vaibhav]

> On 11 Nov 2015, at 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?]
> 
> 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
=


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [atlas] [Request] System tags for DNS resolution

[Chris Amin]

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 at...@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



signature.asc
Description: OpenPGP digital signature

Re: [atlas] [Request] System tags for DNS resolution

[Vesna Manojlovic]

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 :)

[atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

[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?]