Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Jan Komissar (jkomissa) via Unbound-users]

It does seem that the CD bit is the key to this: RFC4035 3.2.2 talks about
it (https://tools.ietf.org/html/rfc4035#section-3.2.2), mainly:


The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest
of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side.  If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.  That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.



Just FYI,

Jan.




On 3/3/16, 6:43 AM, "Unbound-users on behalf of unbound-users@unbound.net"

wrote:

>Havard Eidnes  wrote:
>>
>> > CD=1 is the wrong thing when querying a forwarder. When a
>> > domain is partly broken, queries that work with CD=0 can be
>> > forced to fail with CD=1.
>>
>> Relly?  I interpreted the use of CD=1 as "I want to do my own
>> DNSSEC validation, and therefore don't want or need the
>> validation service which could be provided by the forwarder",
>> especially as noted above when the communication isn't secured.
>> It should not make much of a difference wrt. the validity of the
>> end result whether the forwarder or the unbound resolver does the
>> DNSSEC validation?
>
>This current case is a perfect example: unbound works when it queries
>upstream with CD=0 but not with CD=1.
>
>If a domain is a bit broken then you can get bogus data into the upstream
>cache using CD=1 and subsequent CD=1 queries will receive the bogus data.
>If the downstream validator doesn't have an alternative resolution path it
>is now stuck. But if it queries with CD=0 it can get unstuck.
>
>You need to suppress bogus data at every point in the resolution path.
>
>https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html
>
>Tony.
>-- 
>f.anthony.n.finch    http://dotat.at/
>Southeast Iceland: Easterly or northeasterly, 4 or 5, occasionally 6,
>becoming
>variable 4 later in west. Moderate or rough, occasionally very rough
>later in
>south. Mainly fair. Good.

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Casey Deccio via Unbound-users]

On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users <
unbound-users@unbound.net> wrote:

> Havard Eidnes  wrote:
> >
> > > CD=1 is the wrong thing when querying a forwarder. When a
> > > domain is partly broken, queries that work with CD=0 can be
> > > forced to fail with CD=1.
> >
> > Relly?  I interpreted the use of CD=1 as "I want to do my own
> > DNSSEC validation, and therefore don't want or need the
> > validation service which could be provided by the forwarder",
> > especially as noted above when the communication isn't secured.
> > It should not make much of a difference wrt. the validity of the
> > end result whether the forwarder or the unbound resolver does the
> > DNSSEC validation?
>
> This current case is a perfect example: unbound works when it queries
> upstream with CD=0 but not with CD=1.
>
> If a domain is a bit broken then you can get bogus data into the upstream
> cache using CD=1 and subsequent CD=1 queries will receive the bogus data.
> If the downstream validator doesn't have an alternative resolution path it
> is now stuck. But if it queries with CD=0 it can get unstuck.
>
> You need to suppress bogus data at every point in the resolution path.
>
> https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html
>

This is one viewpoint, but there's more to it than suppressing bogus data.
There might be, for example, local policy or different/older implementation
for which data does not validate at the upstream forwarder, but for which
it might, if given the chance, by the downstream resolver.

About a year ago I reported a bug in BIND in which glue--rather than
authoritative--data was being returned from the cache in response to a
query for a name if 1) the glue data differed from the authoritative data
and 2) CD=1 was set.  If the zone was signed, it also sent an RRSIG along
with the glue data--the RRSIG for the authoritative data, which of course,
didn't cryptographically validate!  I don't know if this has been fixed,
but this seems very similar to the bug being discussed here: if CD=1, then
RFC 2181 priorities are being discarded.  Note that this is DNSSEC
independent, but DNSSEC validation is affected by it, as demonstrated in
the case I reported as well (glue instead of authoritative) as well as the
case at hand (delegation instead of authoritative NS).

Casey

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Tony Finch via Unbound-users]

Havard Eidnes  wrote:
>
> > CD=1 is the wrong thing when querying a forwarder. When a
> > domain is partly broken, queries that work with CD=0 can be
> > forced to fail with CD=1.
>
> Relly?  I interpreted the use of CD=1 as "I want to do my own
> DNSSEC validation, and therefore don't want or need the
> validation service which could be provided by the forwarder",
> especially as noted above when the communication isn't secured.
> It should not make much of a difference wrt. the validity of the
> end result whether the forwarder or the unbound resolver does the
> DNSSEC validation?

This current case is a perfect example: unbound works when it queries
upstream with CD=0 but not with CD=1.

If a domain is a bit broken then you can get bogus data into the upstream
cache using CD=1 and subsequent CD=1 queries will receive the bogus data.
If the downstream validator doesn't have an alternative resolution path it
is now stuck. But if it queries with CD=0 it can get unstuck.

You need to suppress bogus data at every point in the resolution path.

https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Southeast Iceland: Easterly or northeasterly, 4 or 5, occasionally 6, becoming
variable 4 later in west. Moderate or rough, occasionally very rough later in
south. Mainly fair. Good.

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Havard Eidnes via Unbound-users]

>>   info: validate(cname): sec_status_secure
>>   info: validate(positive): sec_status_secure
>>   info: message is bogus, non secure rrset uninett.no. NS IN
>>
>> As far as I can tell, the problem here is caused by extra NS-records in
>> the authority-section that do not include the RRSIG element for the
>> NS-records, but I can't really say that for certain.
>
> This sounds a lot like a problem we discussed last year. See
> https://unbound.net/pipermail/unbound-users/2015-February/003757.html

Yep, indeed, this does appear to be exactly the same root cause,
although DLV isn't really relevant to the problem.  Unbound appears to
enforce compliance to section 3.1.1 of RFC 4035 even when it's
querying a forwarder, which is a non-authoritative recursive resolver.
In fact, the entire 3.1 section only talks about the behaviour of
authoritative name servers, while section 3.2 talks about recursive
name servers.  Thus, unbound enforcing 3.1.1 on responses to forwarded
queries is just Wrong, and a bug in unbound.

> As I said back then, I think it's wrong to discard the entire response if
> parts of it are bogus. Unbound should keep the valid parts because it
> knows there is nothing wrong with them.

Come to think of it, anything you get from a recursive resolver are
possibly cached hints, including what you get in the Answer section.
If a validating resolver needs other RRsets than those supplied in the
answer (all sections) or what it has in the cache, it should
explicitly ask for them.

Granted, modern recursive name servers used for forwarding will set
"DNSSEC OK" in outgoing queries (as mandated by RFC 3225), and will
supply any cached related DNSSEC material in the reply when queried
with the "DNSSEC OK" flag set.  However, it does not have to comply to
section 3.1 of RFC 4035 when composing the reply.

> Does Unbound use CD=1 when forwarding? If so, it should expect to receive
> partially bogus answers and should handle them gracefully.

Yep, as Olav replied, and the pcaps I capture on the BIND recursor
agrees: CD=1 is set in the forwarded queries.

Regards,

- Håvard

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[W.C.A. Wijngaards via Unbound-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Havard,

On 03/03/16 09:30, Havard Eidnes wrote:
>>> A couple of responses to an 'a' query for this name follows 
>>> attached below.  In both cases you'll see the Authority section
>>> contains the NS RRSET but not the RRSIG covering the NS RRSET,
>>> something we're not quite sure is "right" (but have not yet
>>> found the scripture on), and which Olav suspects is triggering
>>> Unbound to be unhappy about the response.
>> 
>> The "right" thing is to have RRSIGs for all elements of the 
>> answer and authority sections.  This is mandated by RFC4034, 
>> 4035.
> 
> Following the "not a bug" response from the BIND maintainers 
> yesterday evening, can you please point to chapter and verse 
> mandating this behaviour for non-authoritative recursive 
> resolvers?

RFC4035 3.2.3 for validators, all RRsets in answer and authority
sections should be authentic ...

https://tools.ietf.org/html/rfc4035#section-3.2.3

> 
> The closest I've been able to find is section 3.1.1 in RFC 4035, 
> and that section only applies to authoritative name servers.

Yes and I had not counted on getting a partial referral mixed into
another reply from a forwarder.

Best regards, Wouter

> 
> In the absence of any forwarding configuration, unbound always 
> expects to speak with authoritative name servers, and then it makes
> sense to enforce the text from 3.1.1.  However, when it uses
> forwarding it will send all its requests via one or more 
> non-authoritative recursive resolvers, and then insisting on RRSig
> on all RRsets in the authoritative section no longer makes sense.
> Instead, unbound should adhere to the rule "if you need a specific
> RRset (that you've not already been given) to proceed, you had
> better ask for it explicitly".
> 
> Therefore, in the absence of any contradictory quote from the 
> standards, I conclude that the current behaviour of unbound in a 
> forwarding setup is a bug in unbound.
> 
> Best regards,
> 
> - Håvard
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW1/lAAAoJEJ9vHC1+BF+NRUwP/A35eRI+/FxrXGJZUwfyx4QC
Ozt8pDiQ3h1ik5YLXoU85JeKOTyj7lhmdzCNvw/yzfFLSmon3F5URHor8KKGnbWn
k2mZU9Rgh+JlR1k3Dcwl9ayOtBr/1VF/lJh4tXXxgEWgUxLT7jacAGdDq0fZKlGz
42t3l+biIbUKK2oQq15/ytfZSQD6yBGndqgJjDDhEP11Kfv0QazPKGDGRyPcWe9R
XbqToc5qm7F7bl4Q8dXscGt4kQvHz6vCNAtikZHUAd1gHduQ8Bz9sKJv5LunjRFl
NXOCgRZpH81LbGzcMdzzt4tN9kEbwwxzFo1lb9s9ocsVpxs0j4AKa1D5DMU747zN
y8V0lekSz4SEu6++krdmykWIyvLc94lHudbWwvdxqqWkTuFE/g9mhMjvdQbISl9n
xlJEOP/5mFoEIZXH9x2tfH6uM/JQzQxQ1mbbQQoxY3rvy3yfDYx20iGPThmjjfnt
jIjmaGGQR0OXI5M9bSbGC1J99OLO/xNgjw5QvCAij1Y8Go870N/eyxw81cfyFZvV
QCU6lLUJKGIrexFQAGf6GxeexMFte2ZeSUyy1SR2ufP0+7pYUeUpMN01Bxswjglh
IdftX+PrPjsAChTmwZFm3r/OPPKv9ByVZKYlZQNwDujvgHdlPzQbj8KKHLlyyiGu
AEJYnq60g0PUmi+W6e3B
=1MWD
-END PGP SIGNATURE-

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Olav Morken via Unbound-users]

On Wed, Mar 02, 2016 at 21:14:56 +0100, W.C.A. Wijngaards via Unbound-users 
wrote:
> However, I think it is not unreasonable to extend the compatibility
> code in Unbound for this.  The error that Olav quotes is simply
> Unbound enforcing that 'all RRsets MUST validate' rule, telling you
> which one failed.  The NS set is gratuitous though, in the answer,
> hence perhaps compatibility is an option.  Not so, for, say, NSEC or
> SOA RRs.

If the compatibility code can be extended, that would be great! The 
alternative at the moment seems to be to use less diversity in the 
upstream resolvers, but that is unfortunate from a reliability point of 
view.

Best regards,
Olav Morken
UNINETT

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Olav Morken via Unbound-users]

On Thu, Mar 03, 2016 at 08:58:02 +0100, Olav Morken wrote:
> On Wed, Mar 02, 2016 at 16:58:38 +, Tony Finch wrote:
> > Does Unbound use CD=1 when forwarding? If so, it should expect to receive
> > partially bogus answers and should handle them gracefully.
> 
> I checked, and it does set the CD-flag.

I forgot to mention this, but I also did a quick test where I patched[1] 
of Unbound to not set the CD-flag in its queries, and at that point DNS 
resolution worked. Checking packet captures shows that BIND does not 
include the NS-records in that case.

[1] https://gist.github.com/olavmrk/f9e9c68ec2932e026b4e

Best regards,
Olav Morken
UNINETT

Re: message is bogus, non secure rrset with Unbound as local caching resolver

[Olav Morken via Unbound-users]

On Wed, Mar 02, 2016 at 16:42:01 +0100, Olav Morken wrote:
> On Wed, Mar 02, 2016 at 08:45:11 -0500, Casey Deccio wrote:
> > On Wed, Mar 2, 2016 at 6:39 AM, Olav Morken via Unbound-users <
> > unbound-users@unbound.net> wrote:
> > 
> > > sorry for the rather longwinded email. In the interest of saving some
> > > time, here is a short summary:
> > >
> > >
> > Hi Olav,
> > 
> > Would mind trying the DNSViz command-line tool [1] against the resolvers to
> > see if anything shows up?  After install, run:
> > 
> > dnsviz probe -s x.x.x.x pingapi.paas.uninett.no | dnsviz grok -plwarning
> > dnsviz probe -s x.x.x.x pingapi.paas.uninett.no | dnsviz graph -Thtml -O
> > 
> > (substitute x.x.x.x for the BIND and unbound resolvers, in turn)
> > 
> > I'm curious if anything shows up there.
[...]
> I have grabbed a capture from the Unbound resolver that I have attached 
> to this email. If I ever happen to catch the BIND resolver having this 
> behavior, I'll try to catch the output from it as well, but I won't 
> make any promises.

I managed to check yesterday evening, and the output between the two 
upstream resolvers is identical.

Best regards,
Olav Morken
UNINETT