some probes not returning NSID
Hi all, it appears that some probes never return NSID, when requested, while others do, for the same query. For example: https://atlas.ripe.net/measurements/1875836/#!general As you can see NSID is set to True. These are the raw results from the two probes, for a one-off DNS UDM: results = { u'6012': [{u'lts': 230, u'proto': u'UDP', u'from': u'193.0.19.108', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384037, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 6012, u'result': {u'abuf': u'OQGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACUAAwAhbnMwMDBiLmFwcDcubnJ0MS5hZmlsaWFzLW5zdC5pbmZv', u'rt': 312.971, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 900, u'SERIAL': 2011382635, u'TYPE': u'SOA'}], u'ID': 14593, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 132}, u'src_addr': u'193.0.19.108', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}], u'10039': [{u'lts': 166, u'proto': u'UDP', u'from': u'96.237.232.254', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384040, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 10039, u'result': {u'abuf': u'qxGAgAABAAEAAAABA29yZwAABgABwAwABgABAAAB3QAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2UAAAcIAAADhAAJOoAAAVGAAAApD6AAAAAAAAA=', u'rt': 8.299, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 477, u'SERIAL': 2011382629, u'TYPE': u'SOA'}], u'ID': 43793, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 95}, u'src_addr': u'192.168.13.40', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}] } Sagan tells me, for probe 6012, responses[0].abuf.raw_data is: {'HEADER': {'AA': True, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': False, 'Z': 0, 'ID': 14593}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 900, 'Serial': 2011382635, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [{'OptionCode': 3, 'OptionName': 'NSID', 'NSID': u'ns000b.app7.nrt1.afilias-nst.info', 'OptionLength': 33}], 'UDPsize': 4096, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is present. And for 10039: {'HEADER': {'AA': False, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': True, 'Z': 0, 'ID': 43793}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 477, 'Serial': 2011382629, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [], 'UDPsize': 4000, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is missing. Why is this? I've tried increasing the payload size, this makes no difference. I get the same when I try for SOA . @ k.root-servers.net: Compare these outcomes: https://atlas.ripe.net/measurements/1875933/ https://atlas.ripe.net/measurements/1875926/ It appears to me that probe 10039 (or its network) has a problem of sorts, causing this. It would be great if faulty probes can be weeded out, if this is really the case. BTW, I am always getting "null" on the NSID field in the web interface, regardless of whether it lives in abuf, or not. This seems to be a bug. ~paul
On Fri, Feb 20, 2015 at 12:12:20AM +0100, Paul Vlaar <pvlaar@afilias.info> wrote a message of 88 lines which said:
It appears to me that probe 10039 (or its network) has a problem of sorts, causing this. It would be great if faulty probes can be weeded out, if this is really the case.
Zealous middlebox, dropping the EDNS options it doesn't know? This is far more probable than a faulty probe.
On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote:
Zealous middlebox, dropping the EDNS options it doesn't know? This is far more probable than a faulty probe.
Which would be an interesting test result, too. BR Daniel AJ
On 23Feb15, Daniel AJ Sokolov allegedly wrote:
On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote:
Zealous middlebox, dropping the EDNS options it doesn't know? This is far more probable than a faulty probe.
Which would be an interesting test result, too.
Yes. This is an excellent thought for a feature request. Being able to add EDNS options to the query and test whether they make it there and back. MarkA@ISC has a similar set of tests which might be a useful guide. They also include the ability to send an "unknown" EDNS option and an "unknown" version I believe. Mark.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/23 17:23 , Mark Delany wrote:
On 23Feb15, Daniel AJ Sokolov allegedly wrote:
On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote:
Zealous middlebox, dropping the EDNS options it doesn't know? This is far more probable than a faulty probe.
Which would be an interesting test result, too.
Yes. This is an excellent thought for a feature request.
Being able to add EDNS options to the query and test whether they make it there and back. MarkA@ISC has a similar set of tests which might be a useful guide. They also include the ability to send an "unknown" EDNS option and an "unknown" version I believe.
Except for unknown EDNS options and unknown version, this is already possible. There is however no way to just include the EDNS option. Setting any parameter that requires the option pulls it in. So the easiest way to get the option included is to change the USB buffer size. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsTR0ACgkQ23LKRM64egKIxQCfXEuz/2eXm3zUHsv8H4/naAj1 qSgAn2piu24acy38NfyY4OUInQhqRYPw =UrBM -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 11:06 , Philip Homburg wrote:
So the easiest way to get the option included is to change the USB buffer size.
Of course I meant UDP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsTqIACgkQ23LKRM64egIK1gCgubV63hDcL2Dh7odFPENR8tlR ujYAn1P037xhI1GUyi6UwiUCSRcik3dT =KSzw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 16:56 , Mark Delany wrote:
So the easiest way to get the option included is to change the USB buffer size.
Well, to get packet size option sure, but what about the others? For example when edns-client-subnet standardizes?
When there is interest from the community then we can just add that option. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsosYACgkQ23LKRM64egJpMwCfU3iZ5EJWBds2eRydE2XtQ4JV ExQAoLTLAX1gRZZEZ8/NVY085iwHfO8s =6z/f -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/24/15 11:14 AM, Mark Delany wrote:
Well, to get packet size option sure, but what about the others? For example when edns-client-subnet standardizes?
When there is interest from the community then we can just add that option.
Color me intersted.
I'm interested as well. (is there a better way to show interest than to spam the mailing list?) AlanC -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7LOOAAoJEOW2o5eiJADbPqYH/RCOz8aRHZeHp/eDWkp+FWTo NvDE5kDX8XGxMoTcw/vfWkleGbTVBimp3ryuZ0xn6fa9/0krFqFes3Gdxa5pJVgE ma1rxUmsNeeXIRI7Gdq137W8s23BHSQN8NU8NYs06QOkv4H+NL+2KamCzOmoRJPp EEZGRCJZR6+FKJKJDrscrxpv6++UBOC3DtzzLVfKsS7v/LsT1sjlV+fNiQR37aut /sL1f8izsxS/uY7GSSlghEPIWIyHHOnVPiCeTlc9ciDEk0UtDb4TcRMc5HZGi4ZP XPZdfvTedggNcKLtslHjcyZENCFxhxay9QbNYNXf+R4sJgCg4QZz9Mke1TcvluU= =YM43 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 18:23 , Alan Clegg wrote:
On 2/24/15 11:14 AM, Mark Delany wrote:
Well, to get packet size option sure, but what about the others? For example when edns-client-subnet standardizes?
When there is interest from the community then we can just add that option.
Color me intersted.
I'm interested as well. (is there a better way to show interest than to spam the mailing list?)
Mailing MCB(Vesna). I'm curious what the measurement should do. Just measure propagation or does the contents matter as well? And how should in that case the prefix be set? And why Atlas? I assumed that this was an option between big resolvers, like Google's, and authoritative nameservers. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTtB4wACgkQ23LKRM64egIZMQCeLeFaMnDb2M911ETCNWcKEFhr sVMAnRU9Yn5RXK81g/Fh8ue2S+TsYUsC =OC3T -----END PGP SIGNATURE-----
Dear Alan, all, On 24-feb.-15 18:23, Alan Clegg wrote:
(is there a better way to show interest than to spam the mailing list?)
Yes and no ;-) I am listening (as a Community Builder) - on my private email address, twitter, Jabber, conferences... and the collected feature requests are published on the roadmap, every few months. However, the advantages of the public mailing list are: transparency and encouraging participation of others. We are considering introducing the public-facing "bug tracker", however, there are no concrete plans for that yet. This request is noted, and will be weighted against all the other ones, and prioritized compared with our general plans and available people. Thanks for your interest! Vesna https://atlas.ripe.net/get-involved/feedback/ http://roadmap.ripe.net/ripe-atlas/
On Mon, Feb 23, 2015 at 04:23:02PM +0000, Mark Delany <f4w@echo.emu.st> wrote a message of 36 lines which said:
They also include the ability to send an "unknown" EDNS option and an "unknown" version I believe.
Breaking the Internet with Atlas probes, "attribute 99"-style :-)
On 24Feb15, Stephane Bortzmeyer allegedly wrote:
On Mon, Feb 23, 2015 at 04:23:02PM +0000, Mark Delany <f4w@echo.emu.st> wrote a message of 36 lines which said:
They also include the ability to send an "unknown" EDNS option and an "unknown" version I believe.
Breaking the Internet with Atlas probes, "attribute 99"-style :-)
Well, to be fair, the standards do define behavior in such cricumstances. The point of such tests is to determine non-compliance, not break the internet. Mark.
On 20/02/15 00:12, Paul Vlaar wrote:
BTW, I am always getting "null" on the NSID field in the web interface, regardless of whether it lives in abuf, or not. This seems to be a bug.
Hi all, I just thought that I'd mention that with Paul's help, I've managed to find and fix this issue and the changes were pushed out earlier today.
On 25/2/15 9:42 AM, Daniel Quinn wrote:
Hi all, I just thought that I'd mention that with Paul's help, I've managed to find and fix this issue and the changes were pushed out earlier today.
I can confirm that I see NSID results in the web interface now. Thanks Daniel, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar@afilias.info phone: +1-416-673-4078
participants (9)
-
Alan Clegg -
Daniel AJ Sokolov -
Daniel Quinn -
Mark Delany -
Mark Delany -
Paul Vlaar -
Philip Homburg -
Stephane Bortzmeyer -
Vesna Manojlovic