I see - yeah, I can definitely see the case for not including every bit of
fully parsed data from the response. I would, however, posit that besides
success and RTT, the actual response content itself (especially for simple
A/ records, perhaps not necessarily any query) should be considered
On 7/25/23 00:56, Stephane Bortzmeyer wrote:
The "abuf" is always in there, so consumers of the results can parse
that (as you already know, and as Seth does below). There are abuf
parsers out there, and if you're using Python then I'd recommend
using Sagan
Or use Blaeu
On Tue, Jul 25, 2023 at 09:40:34AM +0200,
Robert Kisteleki wrote
a message of 88 lines which said:
> We're not parsing and inserting all the bits from the raw response
> into the JSON mostly because it would inflate the size of the
> results enormously, while users are generally only
Hello,
We're not parsing and inserting all the bits from the raw response into
the JSON mostly because it would inflate the size of the results
enormously, while users are generally only interested in specific bits.
The UI gives the basics (success, RTT) to show the big picture but
exposing
On 25. 07. 23 7:31, Seth David Schoen wrote:
I don't know why there isn't a parsed version of the reply included in
the JSON, but perhaps the idea is that the literal details are of
interest to some researchers. One example that I happened to notice
in trying to answer your question: in parsing
Micha Bailey writes:
> Hi, I’m wondering if I’m missing something - I ran a DNS measurement with
> 110 probes, and the results are in, but the site UI seems to only show the
> result status and time elapsed until response, but not the results
> themselves. Looking at the JSON from the result
Hi, I’m wondering if I’m missing something - I ran a DNS measurement with
110 probes, and the results are in, but the site UI seems to only show the
result status and time elapsed until response, but not the results
themselves. Looking at the JSON from the result endpoint I’m seeing that it
seems
