Re: Validation failure signature crypto failed

[Casey Deccio via Unbound-users]

> On Jan 25, 2017, at 1:57 PM, Jac Backus  wrote:
> 
> I wondered if it was, because the zone was only signed partially. So it shows 
> only the A record, because that is all that is signed. And the TXT record is 
> not signed. 
> But I suppose that may not even be possible.

There certainly are cases (with various causes) where RRSIGs are not returned 
with some RRsets although they are returned with others in the same zone.  In 
this case, however, RRSIGs are returned for both--if they are queried--but the 
RRSIG covering the TXT RRset does not validate.

Casey

Re: Validation failure signature crypto failed

[Casey Deccio via Unbound-users]

> On Jan 25, 2017, at 3:35 AM, Jac Backus via Unbound-users 
>  wrote:
> 
> Why does dnsviz not show the TXT record without selecting it in Advanced?

It was simply a choice of efficiency.  By default queries for MX, TXT, NS, and 
SOA are only issued if the name is a zone apex because it is more common to see 
those records at a zone apex.  It would be a bit slower and require more 
storage to keep track of the less common case.  The option of specifying TXT 
(and others) allows some flexibility beyond the defaults.

Casey

Re: DNSSEC validaion fail for _25._tcp.eldinhadzic.com

[Casey Deccio via Unbound-users]

On Fri, Jul 15, 2016 at 4:13 AM, A. Schulze via Unbound-users <
unbound-users@unbound.net> wrote:

>
> DNSVIZ say it's valid:
> http://dnsviz.net/d/_25._tcp.eldinhadzic.com/dnssec/
> how can I check my unbound could validate such data at all?
>
>
I've added some checks to DNSViz to flag problems with ancestor names:

http://dnsviz.net/d/_25._tcp.eldinhadzic.com/V4iWzQ/dnssec/

Hope that helps for future troubleshooting.

Casey

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: SOLVED: postbank.de / dslbank.de and DNSSEC and DANE

[Casey Deccio via Unbound-users]

On Tue, Feb 2, 2016 at 11:59 AM, A. Schulze via Unbound-users <
unbound-users@unbound.net> wrote:

>
> if I disable "use-caps-for-id" I get NXDOMAIN from unbound.
> so "caps-whitelist: postbank.de" solved the issue for me.
>
>
Looks like the postbank.de servers aren't performing a proper NSEC3 hash of
the mixed-case query name, so the provided closest encloser proof fails:

$ dig +noall +authority +dnssec @ns1.postbank.de foobar.pOstbank.de | grep
'IN NSEC3'
8opkcg718inciqib0r7f67m9g4o4gh71.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 8OPKCG718INCIQIB0R7F67M9G4O4GH73
v7ec9togm33vtn1pqin295lhh5tufuir.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 V7EC9TOGM33VTN1PQIN295LHH5TUFUIS
kt61b6gn579tvif3qsltnjg3f1f8umc6.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 KT61B6GN579TVIF3QSLTNJG3F1F8UMC8
$ nsec3hash E80EE91FDC6B4795 1 1 pOstbank.de
RIN3S92AN87PLVF22QR8PDRD0SA7KI5G (salt=E80EE91FDC6B4795, hash=1,
iterations=1)

But:

$ dig +noall +authority +dnssec @ns1.postbank.de foobar.postbank.de | grep
'IN NSEC3'
rin3s92an87plvf22qr8pdrd0sa7ki5g.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 RIN3S92AN87PLVF22QR8PDRD0SA7KI5H
33okvta5htf2hmv16mrerpavmogho4ug.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 33OKVTA5HTF2HMV16MRERPAVMOGHO4UI
262b532h7r3gsgleslnb9f9fmumi3qb1.postbank.de. 86400 IN NSEC3 1 0 1
E80EE91FDC6B4795 262B532H7R3GSGLESLNB9F9FMUMI3QB3
$ nsec3hash E80EE91FDC6B4795 1 1 postbank.de
RIN3S92AN87PLVF22QR8PDRD0SA7KI5G (salt=E80EE91FDC6B4795, hash=1,
iterations=1)

Cheers,
Casey

Re: Unbound and DNSSEC - different answers from 1.4.22 and 1.5.6

[Casey Deccio via Unbound-users]

On Wed, Nov 25, 2015 at 10:19 AM, Aleš Rygl 
wrote:

> I am running Unbound 1.4.22 on Debian 7.9 for production and  have also
> installed  Unbound 1.5.6-1 on Debian 8.2. Both are validating with nearly
> identical config.
>

In the 1.5.5 release, the following default behavior changed:

- Change default of harden-algo-downgrade to off. This is lenient for
  algorithm rollover.

(https://www.unbound.net/pipermail/unbound-users/2015-October/004055.html)

>From the unbound.conf man page:

harden-algo-downgrade - Harden  against algorithm downgrade when multiple
algorithms are advertised in the DS record.  If no, allows  the  weakest
 algorithm  to validate the zone.  Default is no.  Zone signers must
produce zones that allow this feature  to  work,  but  sometimes they  do
not, and turning this option off avoids that validation failure.

(https://www.unbound.net/documentation/unbound.conf.html)

> According to the dnsviz.net  the domain seems to be DNSSEC broken.
>

Well, "broken" might be strong, but it has errors on the signer side
because the RRsets are signed by only one of the algorithms that appear in
the DS RRset:

http://dnsviz.net/d/mikulasske.cz/VlXMmQ/dnssec/

There is a validation path using one of the algorithms, but because it is
not signed with both, unbound will only validate it if
harden-algo-downgrade is off.  Again, the default behavior changed between
versions, which explains why validation works for one and not for the other.

Cheers,
Casey