Ignore bogus DNS results.

We've had a problem for the past few weeks (?) where we see
false DNS errors when making http/https requests with `curb`/`libcurl`.

To resolve these issues properly we're going to have to rewrite
the code to avoid the current gem.  However that is considerable work
because of the hole we've back ourself into - wanting to test both
IPv4 and IPv6 "properly".  We'll have to duplicate that work if
we use `net/http`, or even mroe so if we use `open3` and exec
`curl -4|-6 ..`

For the moment this commit changes how things are handled to deal
with the issue we see - which doesn't solve the problem but will
mask it.

When custodian runs a test it will return a status-code:

* Custodian::TestResult::TEST_FAILED
  * The test failed, such that an alert should be raised.
* Custodian::TestResult::TEST_PASSED
  * The test succeeded, such that any previous alert should be cleared.
* Custodian::TestResult::TEST_SKIPPED
  * Nothing should be done.

As the failure we see is very very specific - an exception is thrown
of the type `Curl::Err::HostResolutionError` - we can catch that
and return `TEST_SKIPPED`.  That means that there will be no
(urgent) alert.

Obviously the potential risk of swallowing all DNS-failures is that
a domain might expire and we'd never know.  So we'll do a little
better than merely skipping the test if there are DNS failures:

* If we see a DNS failure.
  * Then we try to lookup the host as an A & AAAA record.
    * If that succeeds we decide the issue was bogus.
    * If that fails then the host legitimately doesn't resolve so we raise an alert.

To recap:

* If a host fails normally - bogus status-code, or missing text - we behave as we did in the past.
* Only in the case of a DNS-error from curb/curl do we go down this horrid path.
   * Where we try to confirm the error, and swallow it if false.

This closes #13.

0 files changed, 0 insertions, 0 deletions