From 3f59c08e31bbed5cb9005e09e062c2add0090e26 Mon Sep 17 00:00:00 2001 From: bert hubert Date: Mon, 20 Oct 2014 15:51:42 +0200 Subject: [PATCH] clarify -1 semantics --- pdns/docs/security-poll.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/pdns/docs/security-poll.md b/pdns/docs/security-poll.md index edb73e92e6..cf0f734c23 100644 --- a/pdns/docs/security-poll.md +++ b/pdns/docs/security-poll.md @@ -22,16 +22,23 @@ PowerDNS software periodically tries to resolve The data returned is in one of the following forms: - * NXDOMAIN or resolution failure - * "0 Ok" - * "1 Upgrade recommended for security reasons, see http://powerdns.com/..." - * "2 Upgrade mandatory for security reasons, see http://powerdns.com/..." + * NXDOMAIN or resolution failure -> -1 + * "0 Ok" -> 0 + * "1 Upgrade recommended for security reasons, see http://powerdns.com/..." -> 1 + * "2 Upgrade mandatory for security reasons, see http://powerdns.com/..." -> 2 In cases 1 or 2, periodic logging commences. The metric security-status is set to 1 or 2 respectively. If at a later date, resolution fails, the security-status is not reset to 0. It could be lowered however if we discover the security status is less urgent than we thought. +If resolution fails, and the previous security-status was 0, the new +security-status becomes -1 ('no data'). If the security-status was higher +than 0, it will remain that way, and not get set to -1. + +In this way, security-status of -1 really means 'no data', and can not mask +a known problem. + ## Distributions Distributions frequently backport security fixes to the PowerDNS versions they ship. This might lead to a version number that is known to us to be -- 2.47.2