Maintained by: NLnet Labs

How to force resolution failure of an unsigned domain

W.C.A. Wijngaards
Tue Apr 4 14:54:05 CEST 2017


Hi Sen Dion,

On 04/04/17 14:47, Sen Dion wrote:
>    Hi Wouter,
> 
> 
> Thank you for taking time to provide clarification.
> 
> I went step-by-step through [2].  The following spot:

Unfortunately that document is about an old version of DNSSEC, with KEY
and SIG types.  The new version of DNSSEC has DNSKEY and RRSIG rrs.  It
works differently.  But can also find verifiable insecure points, by
disproving the existance of DS records.  This is done with NSEC (or
NSEC3) records signed by the parent domain.

Unbound does not have a way to prevent access to insecure names.  Or
make resolution failure.  Because I think it is not needed.

Best regards, Wouter

>   "Next the resolvers checks the contents of the
>    example.com key. If the key is empty (a so called
>    null key) example.com is considered verifiable
>    insecure.  The lookup will then proceed as a
>    normal DNS lookup."
> sounds suspiciously weak from the integrity point of view. 
> 
> 
> On the next recursion (to resolve www.example.com), unbound
> may cache the bogus response, as shown in [3].  In turn,
> this will allow unsuspecting visitors to happily
> supply their deepest banking secrets to the fake site.
> 
> The above scenario motivates me to ask the following
> questions:
> 
> - How to prevent accesses to an unsigned name from 
> 
>   applications which are not 'ad' flag aware?
> - Is there a way to force resolution failure (in unbound)
>   for an unsignedname?
> 
> Refernces
> ---------
> 
> [1] Chain of Trust, by R. Gieben
> 
>     https://www.nlnetlabs.nl/downloads/publications/CSI-report.pdf[2] See section 3.5 "DNSSEC lookups" in [1].
> [3] See section 2.3 "Security" in [1].
> 
>    Thanks,
>    - Sen Dion
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20170404/b2885526/attachment.sig>