Wrong IP prefix values accepted?
It seems there is no protection against wrong prefixes? See measurement #1897909, which started with JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix foobar', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 3, 'type': 'prefix', 'value': 'foobar'}]}
On Tue, Mar 17, 2015 at 04:15:08PM +0100, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 4 lines which said:
It seems there is no protection against wrong prefixes? See measurement #1897909, which started with JSON:
Also, I do not understand the algorithm used to reject prefixes with the message "Your selected prefix is not covered by our network." I tried to ask probes in the prefix 88.0.0.0/8 (with the Web interface) and it was rejected with the above message despite the fact that probes 88.186.234.47, 88.179.43.37, etc do exist.
On Tue, Mar 17, 2015 at 04:15:08PM +0100, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 4 lines which said:
It seems there is no protection against wrong prefixes?
Last (I promise) remark about prefix selection. I cannot do it from the API. From the Web interface, I can select the prefix 88.176.0.0/12 and it works. But from the API, while it is accepted (I get a number, #1897919), he measurement later fails. My JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix 88.176.0.0/12', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 5, 'type': 'prefix', 'value': '88.176.0.0/12'}]} The status when querying: {u'id': 7, u'name': u'Failed'}
I've just gone over your cases here and wanted to let you know that at least one of these was the unfortunate result of a typo on my part :-( I've since fixed it, and that fix will go out tomorrow as it's coming up on 1900h here in Amsterdam. Unfortunately, the issue of rejecting should-be-valid prefixes was not as simple a problem and that's going to take a little longer to fix. We have a few people tasked now with fixing this. It's a known problem with how we handle comparing IPs to prefixes in our database and we hope to have that working in production tomorrow as well -- though it may take a smidge longer than that. Thanks for finding these, and for reporting it. Though next time, please report bugs to atlas-bugs@ripe.net :-)
On Tue, Mar 17, 2015 at 06:48:14PM +0100, Daniel Quinn <dquinn@ripe.net> wrote a message of 14 lines which said:
Though next time, please report bugs to atlas-bugs@ripe.net :-)
OK but I wasn't sure it was a bug, I thought it may be worth a discussion. Good luck for the fix and don't worry, it's not an emergency.
On Tue, Mar 17, 2015 at 06:48:14PM +0100, Daniel Quinn <dquinn@ripe.net> wrote a message of 14 lines which said:
Unfortunately, the issue of rejecting should-be-valid prefixes was not as simple a problem and that's going to take a little longer to fix. We have a few people tasked now with fixing this. It's a known problem with how we handle comparing IPs to prefixes in our database and we hope to have that working in production tomorrow as well -- though it may take a smidge longer than that.
Apparently, it is not yet fixed? For: {'definitions': [{'target': '2001:4b98:dc2:45:216:3eff:fe4b:8c5b', 'af': 6, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'description': 'Ping 2001:4b98:dc2:45:216:3eff:fe4b:8c5b from prefix 2000::/3'}], 'probes': [{'requested': 10, 'type': 'prefix', 'value': '2000::/3'}]} I get: Status 400, reason "{"error":{"message":"__all__: Your selected prefix is not covered by our network.","code":104}}" But 2000::/3 is the entire IPv6 space currently allocated, all the Atlas probes are certainly in it.
participants (2)
-
Daniel Quinn -
Stephane Bortzmeyer