Am I correct that Unbound cannot require DNSSEC validation for its resolution?
The general DNS use case would call for security of validated insecurity, but other situations are possible too.
* You do not want to trust TLSA / CERT / … records that have not been validated
* Kerberos5 tends to mistrust DNS, but inasfar as records are signed that coudl be corrected
* An application at a CA might have a policy to only trust signed portions of DNS
So, if I am correct and there is no way to enforce DNSSEC validation on everything returned, then could such an option be added in future versions?
Am I correct that Unbound cannot require DNSSEC validation for its
resolution?
Not sure what you are asking here. If unbound is configured with the
root trust anchor, it will validate everything it can. Of course, if a
zone is not signed, then there's nothing to validate. Additionally, a
user can send a query with the CD flag set, and then unbound will send
results, even if validation failed.
Are you suggesting that unbound ignore the CD flag? Or are you asking
for something else?
Am I correct that Unbound cannot require DNSSEC validation for its
resolution?
[…] Of course, if a
zone is not signed, then there's nothing to validate.
In that case, I would prefer not delivering the records. This is different from everyday use of DNS. However, for the applications I mentioned this could make good sense.
I can imagine having different resolvers in a network, or perhaps different views on one resolver, where the hardcore security apps receive NXDOMAIN or Bogus or something similar if DNSSEC is not present while your everyday silly app (browser, gopher, ping6) do receive their answers. It is likely that the hardcore security apps would want to have a local Unbound instance running to avoid influence when the LAN is crossed.
Additionally, a
user can send a query with the CD flag set, and then unbound will send
results, even if validation failed.
Quite the opposite direction of where I’d like to move ;-
Are you suggesting that unbound ignore the CD flag? Or are you asking
for something else?
I *think* I am asking for something new — namely, to insist on presence of DNSSEC and proper validation on it. In other words, to be able to neglect anything that is not properly signed.
If an application wants to insist on DNSSEC, they simple need to query
and check for the AD bit being set. It's not up to the resolver to
set application policy.
If an application wants to insist on DNSSEC, they simple need to query
and check for the AD bit being set. It's not up to the resolver to
set application policy.
Two reasons make this technically correct, but untractable:
1. The person wanting to enforce this policy may be a sysadmin, rather than a developer. He’d end up doing nasty things with firewalls and experience delay times.
2. I think the recursive resolver is the ultimate place to implement insisting on DNSSEC; using an overloaded bit to do it elsewhere somewhat scares me.
So I, ehm, insist, that this is a useful feature to add to Unbound
I think the question is whether it's possible to configure an unbound validator to treat verifiably insecure data the same as bogus data when deciding how to respond to a query from a client.
> If an application wants to insist on DNSSEC, they simple need to query
> and check for the AD bit being set. It's not up to the resolver to
> set application policy.
Two reasons make this technically correct, but untractable:
1. The person wanting to enforce this policy may be a sysadmin, rather than a developer. He’d end up doing nasty things with firewalls and experience delay times.
2. I think the recursive resolver is the ultimate place to implement insisting on DNSSEC; using an overloaded bit to do it elsewhere somewhat scares me.
Why does this scare you? If you don't trust the AD bit from your
DNSSEC validating resolver - why trust the response at all?
Perhaps DNS is not the right thing for your application.
So I, ehm, insist, that this is a useful feature to add to Unbound
Unbound has been released unter the BSD license which means you are
free to svn checkout the sources and hack, hack, hack.
Strictly speaking you are asking unbound do something that RFC4035 out-laws, i.e. see section 4.3,
Insecure is always returned.
I understand what you want and agree with you it would be nice to have this functionality.
One way to do this is to run a local resolver behind a proxy that translates all answers w/o AD bit to an
empty answer with RCODE>0, not sure what RCODE
A better way might be to propose an EDNS0 option that expresses to the resolver:
only answer if AD==1
and defines a new RCODE to express only insecure answer exists.
This way applications that want this functionality get it and all others that use the resolver
are not affected.
I understand what you want and agree with you it would be nice to have this functionality.
One way to do this is to run a local resolver behind a proxy that translates all answers w/o AD bit to an
empty answer with RCODE>0, not sure what RCODE
Scary stuff. Very, very hacky.
A better way might be to propose an EDNS0 option that expresses to the resolver:
only answer if AD==1
and defines a new RCODE to express only insecure answer exists.
At the protocol level, that would be the proper resolution. But I doubt anyone is going to find that acceptable — I think the full force of the IETF is going to tell us that this is to be arranged in the resolver. And I would agree with them.
This way applications that want this functionality get it and all others that use the resolver
are not affected.
It’s always possible to make this view-dependent, and/or to run multiple resolver instances. I don’t think I’d ever combine this functionality with the default resolver on a network, but rather run it on a machine that requires this facility — so as to bypass LAN dangers (such as its users).
2. I think the recursive resolver is the ultimate place to implement insisting on DNSSEC; using an overloaded bit to do it elsewhere somewhat scares me.
Why does this scare you? If you don't trust the AD bit from your
DNSSEC validating resolver - why trust the response at all?
Agreed, so this is not why I said it.
The AD bit has changed meaning over time, and is therefore more dynamic than I’d care to let any an admin encode in firewall rules. Also, the firewall would have to produce a DNS response (if it is not to cause a slowing-down timeout) and that’s always tricky in firewalls. Keep in mind that I’m trying to avoid that apps need to be reprogrammed — so it’s all up to filtering as far as I can tell.
My conclusion is that doing this at the protocol level is tricky and hairy. This is due to the fact that DNS has rather… evolved… ways of coding information. In a resolver on the other hand, the information is present in very, very clear form. So this is the best possible place for filtering.
Perhaps DNS is not the right thing for your application.
Neither are /etc/hosts and /etc/krb5.conf I fear
I’d like to trust the signed portion of DNS, and build security systems on top of that. So the _old_ DNS isn’t the right thing for the applications I have in mind.
Unbound has been released unter the BSD license which means you are
free to svn checkout the sources and hack, hack, hack.
That’d only help me, but make it pretty hard to reproduce procedures on other platforms. So no, I’d love this to be on the mainstream agenda. This is why I’m proposing it here — to see if there’s traction.
I mentioned one way this could be done in protocol, another way is to do it in resolver library,
if an application can tell resolver library ONLY AD=1 then that works as long as the application knows.
Olafur
ps: I hope libc DNS library be retired, adding this functionality to libunbound or libldns should not be that hard,
I’d like to trust the signed portion of DNS, and build security systems on top of that. So the _old_ DNS isn’t the right thing for the applications I have in mind.
Could you expand a bit on the kind of applications you have in mind?
Anything that bases security on DNS info, really; just a few that spring to mind:
- public key info such as TLSA and CERT records
- in some cases, perhaps, references to services (to avoid MITM scenarios based on DNS)
- Kerberos currently mistrusts DNS for non-configured domain lookups, and must therefore be configured manually, which is a shame if DNSSEC can help
DNSSEC offers an opportunity to secure DNS; the current assumption is that the provider of the information chooses whether or not to secure it; but in some cases the user of the information wants to be able to constrain the information to be trusted to only information that is certainly correct.
