wouter at nlnetlabs.nl
Mon May 30 07:18:59 UTC 2016
On 27/05/16 11:19, Rick van Rein via Unbound-users wrote:
> Unbound sets a number of very useful flags after it has completed a
> query, to check the security status. But there are a few places where
> I'm unsure what to check, and in what order. For instance, the security
> of not having found any data or domain.
> Is there anywhere I can find something like
Secure is set when the message is secure (dnssec validated). This may
be secure data, secure nxdomain, secure no-data-at-all.
Bogus is set when the message is dnssec broken, (secure is then not
set). There is a why_bogus string with an error message what was wrong
(eg. signature expired, or key mismatch with parent).
If secure and bogus are both not set, the message is 'insecure', i.e. it
was not dnssec signed.
nxdomain is turned on when the rcode is NXDOMAIN. It can be on with
secure, with bogus, and with neither.
Note that it is also possible to have no data, then the 'havedata'
boolean is false.
> When set | Then reset
> Secure | Bogus, Nxdomain
> Bogus | Secure, Nxdomain
> Or, alternatively,
> Resultant state | Secure | Bogus | Nxdomain
> happy | 0 | 1 | 0
> extatic | 1 | 0 | 0
Adding nxdomain to the list is weird. Also the table misses the
secure=0, bogus=0 entry. You are happy with dnssec failure (bogus?),
i.e. dnssec is deployed but fails? I think the name is wrong.
> This could help us determine in what order to probe flags, and whether
> there may be flavours of Nxdomain, for instance.
I would recommend first looking at the bogus and secure flags.
Then see if there is data, nxdomain, havedata.
Then look at the data.
This order is assuming that if it is dnssec bogus, maybe you do not care
about the data (and nxdomain), because those indicators are not reliable
> I hope I didn't miss any of the documentation!
The comments in the unbound.h header file? The libunbound man page?
I think you need secure key material, like DANE? So, first check bogus
(if true; nothing you can do but fail it), then secure (if false - it
was insecure, domain not signed). If secure is true, check for nxdomain
or not havedata, (you can do the this-protocol-feature-not-enabled
action safely). If there is secure and data, you have the key material
(potentially multiple, with eg. different algorithms, usually check is
there is any that you support, if the number is zero treat as
not-enabled or so, otherwise use the supported entries).
Best regards, Wouter
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Unbound-users