Split validation

[ohnorobo]

This splits answer:not_validated into answer:unvalidated_http_connection and answer:no_tcp_connection (when we were not able to connect to the answer ip at all.

I'd like suggestions about:

• the clearest (short) names to use for these outcome
• thoughts on this approach overall. I think trying to break out not_validated further is useful, since it's 60% of our unexpected outcomes. But I don't have a full theory of how this new information is actionable.
• Do we want to break out answer:no_tcp_connection further, by splitting along different types of connection errors? (timeout, no route, etc)

dashboard with this data: here

Here's the new outcome breakdown

[ohnorobo]

So @fortuna the overall thought here is:

• drop HTTP page fetches. We know the domain is capable of HTTPS, so what happens with port 80 on a random dubiously-received IP is not helpful.
• this will also drop HTTP blockpages, which by now are very small fraction of outcomes. (0.14% of unexpected)
• Any IP where we received a response on port 443 is split out into one of the cert in/valid outcomes.
• Any IP where we did not get a response on 443 (currently marked as not_validated) gets split out by error type (timeout, unreachable, refused, etc)

I also looked some into the remaining cases of http blockpages here which makes me think they still have some value

[ohnorobo]

I made a sample dashboard that does something like this here

I'm not yet convinced that having the errors allows you to make any better analysis decisions, but it's interesting to be able to see.