Hello Everybody,
It looks like there is an assumption that it is an application
responsibility to get user consent before accessing an unsigned domain
(whenever 'ad' flag is not set). AFAIK, that is not the case: majority
of applications is not 'ad' flag aware.
How to prevent accesses to unsigned domains from these applications? Is
there a way to force resolution failure (in unbound) for an unsigned
domain?
Regards,
Sen Dion
Hi Sen Dion,
This is not needed. Unbound can keep apart unsigned domains and domains
where the crypto fails or is missing. This is a feature of DNSSEC,
where there is a signature over data that says the domain is unsigned.
So the user can trust the absence of the ad flag (and the data is then
insecure, but we know securely that it could arrive without signatures).
Best regards, Wouter
Hi Wouter,
Thank you for taking time to provide clarification.
I went step-by-step through [2]. The following spot:
"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
Hi Sen Dion,
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
My mail client messed with the new line character
which rendered the previous post less readable.
Please, ignore the previous post, and use this one instead.
Hi Wouter,
Thank you for taking time to provide clarification.
I went step-by-step through [2]. The following spot:
"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
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
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
Hi Sen,
Python scripting for Unbound may enable your desired function.
http://unbound.net/documentation/pythonmod/index.html
For your information you can configure BIND9 to accept
secure (DNSSEC validated) response only:
options {
dnssec-must-be-secure . yes;
};
managed-keys { .... };
With this configuration you can resolve signed (secure) domain only:
$ dig @::1 unbound.net +short
185.49.140.10
$ dig @::1 isc.org +short
149.20.64.69
But you won't be able to reach all unsigned (insecure) domain, as
Wouter pointed out:
$ dig @::1 yahoo.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46417
$ dig @::1 google.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63482
$ dig @::1 twitter.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7986
Daisuke HIGASHI via Unbound-users skrev den 2017-04-05 15:23:
For your information you can configure BIND9 to accept
secure (DNSSEC validated) response only:options {
dnssec-must-be-secure . yes;
};
managed-keys { .... };With this configuration you can resolve signed (secure) domain only:
$ dig @::1 unbound.net +short
185.49.140.10
$ dig @::1 isc.org +short
149.20.64.69
works as designed then, it protect you from using these ips blindly
But you won't be able to reach all unsigned (insecure) domain, as
Wouter pointed out:
when domains is not dnssec, you cant enforce dnssec without any risk of not see results as expected
$ dig @::1 yahoo.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46417
https://dane.sys4.de/smtp/yahoo.com
$ dig @::1 google.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63482
https://dane.sys4.de/smtp/google.com
$ dig @::1 twitter.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7986
https://dane.sys4.de/smtp/twitter.com
i know dane is not meant to be used here, it just good source to confirm that its not your unbound not working :=)
funny enough yahoo google twitter are all using dkim signed mails, whats there point with it 