Flags?

Unbound
1

Hi,

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

When set | Then reset

2

Hi Rick,

Hi,

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
any more.

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

3

Hi Wouter,

Thanks for the additional info.

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.

Oh, it's an example of the format of a table that would be of use. The
names happy / extactic are just meant as meaningless dribble. I hadn't
assumed you would take me seriously :wink:

What I was trying to say is that a table of this kind is both easier to
keep complete in the documentation, and it gives developers a better
overview of how flags relate. I imagine this to lead to confusion and
misinterpretations due to the wordy form and the (sometimes confusing)
relations between the flags.

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.

Thanks!

I hope I didn't miss any of the documentation!

The comments in the unbound.h header file? The libunbound man page?

I didn't see the header file yet,

Thanks,
-Rick

4

Also SERVFAIL, FORMERR, NOTIMP, ... are neither secure not insecure.
DNSSEC Security status only applies to a response RRset or denial
of existence of that RRset.

The only response codes for which the secure/insecure distinction
applies are:

    NOERROR
    NXDOMAIN
    NODATA (NOERROR + ANCOUNT = 0)

All other error codes don't distinguish between signed and unsigned
zones, all we know is that the lookup failed (misconfiguration,
DoS, MiTM, ...).

This is important in opportunistic DANE TLS, see:

    https://tools.ietf.org/html/rfc7672#section-2.1

There I make the case that non-bogus NOERROR, NODATA and NXDOMAIN
are not errors, while bogus responses and all other response codes
are lookup errors.

5

Hi Viktor,

If secure and bogus are both not set, the message is 'insecure', i.e. it
was not dnssec signed.

Also SERVFAIL, FORMERR, NOTIMP, ... are neither secure not insecure.
DNSSEC Security status only applies to a response RRset or denial
of existence of that RRset.

The only response codes for which the secure/insecure distinction
applies are:

    NOERROR
    NXDOMAIN
    NODATA (NOERROR + ANCOUNT = 0)

Libunbound exports the 'rcode' field that can be used for this (rcode==0

rcode==3), it contains the RCODE of the return message. That could

also be SERVFAIL, i.e. lookup error of some sort.

Best regards, Wouter