Maintained by: NLnet Labs

How to force resolution failure of an unsigned domain

W.C.A. Wijngaards
Wed Apr 5 08:38:23 CEST 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Sen,

Yes that document is very recent, but does not explain insecure zones.

Unbound can verify that the zone is supposed to not have signatures,
because the parent zone signs the NSEC (or NSEC3 if they are using
NSEC3) that says so.  Unbound then passes the normal results to the
application (without the AD flag), so that it can connect.

Your administrator wants unbound to somehow secure non-DNSSEC signed
zones using DNSSEC?  If we stop resolution of all zones that have not
deployed DNSSEC, then you won't be able to connect to a large fraction
of sites?

What I think is happening is that you are confusing a zone that has
not deployed DNSSEC with a zone that is bogus.

Best regards, Wouter

On 05/04/17 06:22, Sen Dion wrote:
>> 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.
> 
> 
> I went step-by-step through [4].  Is it good enough to describe the
> new version DNSSEC?  If not, please point me to the relevant
> document.
> 
> 
> Unfortunately, this document doesn't reveal the result of
> resolving an unsigned name.
> 
>> 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.
> 
> Please, help me to understand how things will play out in case 
> insecure point is verifiable found.  Will 'unbound' resolve name
> 
> below this point?  Will an application get the resolved name and 
> attempt to connect to it?
> 
> 
> 
>> Unbound does not have a way to prevent access to insecure names.
>> Or make resolution failure.  Because I think it is not needed.
> 
> 
> Correct me if I am wrong.  In case the answer returned to unbound
> 
> is retrieved from records located below insecure point (in the
> hierarchy), the unbound will pass it to an application.  In turn,
> the application
> 
> will be able to connect to the IP without suspecting that the IP
> is bogus.
> 
> 
> I am trying to present to our administrator the benefits of running
> 
> 
> 'unbound'.  I am confident that the above revelation will not fly
> by
> 
> him.  Will you help me to make a convincing argument?
> 
> 
> 
> References ----------
> 
> [4] "How DNSSEC Works" 
> https://www.cloudflare.com/dns/dnssec/how-dnssec-works
> 
> 
> 
> Thanks, - Sen Dion
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJY5JDZAAoJEJ9vHC1+BF+N3BMQAK4mx/bLmJgGZ5j0fcCj5Yd/
2eGzJ9+b9Mpfg2xTNdWftEAZmQ1mVdInml6aWA/qPKUHAulVuja/uaGiypnGkxyp
eu9WAEMHq3Z9g7x/4wHJYU2fndFeSQl+4zjMmjzj1JErQ9CuqwTlTqoOEKTNfGnQ
c9mRNFoRdldpLyaq03K12eVSdxwKwOkdbD2dLG6tG57oiRIdCS1HWJwvbKf0CRqr
FcjdXNk9z3FL6aY1VdjW7nr3mxW91RxMK12excdzRsl/J1R59kFj0I8lMGma+xxR
jLGHbW1SYpD+GKGdCokojGr9oKPwh8MtSyPHw92P3GxnRh8tDnIDFPIKsKpRbknv
2SJy9DxSqwUS5CVl5I83bkWfe1hzB4GW4BF6GYR4n9ufuFPgImaXIlxg0ER3Zxmk
Z1FPM4ftjPEpJmH8hp8OqA/DxSMSKF7SSHDyxtJdPbTUaNDFxiXcyE+NcC3XpIK9
ZA05vT4HDPa+0fWlI4Z8uyHJfxORSnz064ZHYmYMVYlt2WtA2I/ley0rScFB2dIP
+Z93dVq9dfZfk8QFCqtDMWjo8yVgzSSbULUhwaLJQwDza2UGzt3LWE25uLpodsEW
yuC+ZAaDqXuY8ZKIvc9Am2UDZI0QtZUsnZy0L8VgcYUJqYrgxWEPSjQVaW6SOpk1
IswD8FyHit1R78cN/8j1
=1Qg6
-----END PGP SIGNATURE-----