Hi,
Without DNSSec, forwarding is working fine. With DNSSec enabled (I am using DLV), forwarding fails when I forward my querries to a server that isn’t dnssec enabled.
The output from the log looks like this:
[1246456813] unbound[7919:0] info: validator operate: query <dlv.isc.org. DNSKEY IN>
[1246456813] unbound[7919:0] debug: validator: nextmodule returned
[1246456813] unbound[7919:0] debug: not validating response due to CD bit
[1246456813] unbound[7919:0] debug: mesh_run: validator module exit state is module_finished
[1246456813] unbound[7919:0] info: validator: inform_super, sub is <dlv.isc.org. DNSKEY IN>
[1246456813] unbound[7919:0] info: super is <mail.google.com.dlv.isc.org. DLV IN>
[1246456813] unbound[7919:0] info: verify rrset <dlv.isc.org.. DNSKEY IN>
[1246456813] unbound[7919:0] debug: rrset failed to verify due to a lack of signatures
[1246456813] unbound[7919:0] debug: verify result: sec_status_bogus
[1246456813] unbound[7919:0] info: validate keys with anchor(DNSKEY): sec_status_bogus
[1246456813] unbound[7919:0] info: failed to prime trust anchor – could not fetch secure DNSKEY rrset <dlv.isc.org. DNSKEY IN>
[1246456813] unbound[7919:0] debug: validator[module 0] operate: extstate:module_wait_subquery event:module_event_pass
[1246456813] unbound[7919:0] info: validator operate: query <mail.google.com.dlv.isc.org. DLV IN>
[1246456813] unbound[7919:0] debug: val handle processing q with state VAL_VALIDATE_STATE
[1246456813] unbound[7919:0] info: processValidate: state has no signer name <mail.google.com.dlv.isc.org. DLV IN>
[1246456813] unbound[7919:0] info: Could not establish validation of INSECURE status of unsigned response.
[1246456813] unbound[7919:0] debug: val handle processing q with state VAL_FINISHED_STATE
The failure appears because of a signature mismatch. But why is validation taking place when the actual resolver can’t talk dnssec? My config file looks like this:
server:
verbosity: 5
interface: 0.0.0.0
port: 53
do-ip4: yes
do-ip6: yes
do-udp: yes
do-tcp: yes
do-daemonize: yes
access-control: 0.0.0.0/0 allow
chroot: /etc/unbound
username: “”
directory: /etc/unbound/
use-syslog: no
pidfile: /var/run/unbound.pid
root-hints: /etc/unbound/named.cache
logfile: /etc/unbound/unbound.log
dlv-anchor-file: dlv.isc.org.key
forward-zone:
name: “.”
forward-addr: 68.87.68.170
Is this the expected behaviour? or am I missing something here? Why can’t the resolution proceed when the forwarder (unbound) can talk dnssec and the actual resolver can’t?
thanks,
Harish
|
Without DNSSec, forwarding is working fine. With DNSSec enabled (I am
using DLV), forwarding fails when I forward my querries to a server that
isn't dnssec enabled.
The output from the log looks like this:
[1246456813] unbound[7919:0] info: verify rrset <dlv.isc.org.. DNSKEY IN>
[1246456813] unbound[7919:0] debug: rrset failed to verify due to a lack
of signatures
Are you running trunk? There is a bug upto 1.3.0 that caused DLV to
fail.
The failure appears because of a signature mismatch. But why is
validation taking place when the actual resolver can't talk dnssec? My
config file looks like this:
It should fall back to non-secure. If your forwarder changes again to one
that does relay dnssec information, unbound drops the cache and uses the
validator again (If I understood Wouter correctly, I have not verified
this myself)
Paul
Hi,
Without DNSSec, forwarding is working fine. With DNSSec enabled (I am
using DLV), forwarding fails when I forward my querries to a server that
isn't dnssec enabled.
The output from the log looks like this:[1246456813] unbound[7919:0] info: verify rrset <dlv.isc.org.. DNSKEY IN>
[1246456813] unbound[7919:0] debug: rrset failed to verify due to a lack
of signaturesAre you running trunk? There is a bug upto 1.3.0 that caused DLV to
fail.
No the actual resolver he is running, the upstream that unbound is
forwarding to, is not dnssec enabled. That means it is not transmitting
RRSIGs with the responses. Without signatures unbound can only conclude
that signatures have been removed (and that could possibly be
malicious). Therefore the queries are failed for security.
Harish is correct that it would be fine if, say the upstream is also
running unbound without trust anchors, and the forwarder downstream has
trust anchors. In that case the downstream does the validation.
But here, it is not about trust anchors, it is about getting signatures.
So, the solution here is to make the upstream actual resolver
transmit signatures in replies. dnssec-enable:yes for BIND.
Or deploy unbound there, which does it by default.
The failure appears because of a signature mismatch. But why is
validation taking place when the actual resolver can't talk dnssec? My
config file looks like this:It should fall back to non-secure. If your forwarder changes again to one
that does relay dnssec information, unbound drops the cache and uses the
validator again (If I understood Wouter correctly, I have not verified
this myself)
It does not do that! That would be a downgrade attack!
However, this idea is significantly popular, and there is even an option
for unbound: harden-dnssec-stripped that you can turn off.
You are then susceptible to the downgrade attack, but it does the above.
Best regards,
Wouter
The failure appears because of a signature mismatch. But why is
validation taking place when the actual resolver can't talk dnssec? My
config file looks like this:It should fall back to non-secure. If your forwarder changes again to one
that does relay dnssec information, unbound drops the cache and uses the
validator again (If I understood Wouter correctly, I have not verified
this myself)It does not do that! That would be a downgrade attack!
However, this idea is significantly popular, and there is even an option
for unbound: harden-dnssec-stripped that you can turn off.
You are then susceptible to the downgrade attack, but it does the above.Best regards,
Wouter
Hi Wouter,
Usually I just lurk on this mailinglist, but this time I have a question about DNSSEC.
I'm not familair with all details of DNSSEC, but I thought it doesn't really matter all that much where
you get the DNSSEC information from, as long as you have a copy of the public root key or maybe
something from a DLV-system. You would be able to verify it all the way from the top down to the record
that you want to verify.
A forwarded would then just be a cache, you could ask that forwarded to retrieve the right RR and you'd
be able to verify it.
This is what I always assumed, let's say the root is signed ( I assume with DLV it's kind of similair ):
1. you know the root is signed, you have the public key (or whatever key material you need), you get
the right records and you verify these records. They can't be changed, otherwise the signatures wouldn't
match.
2. It has a record that says .org is signed and it has to match with this key.
3. you ask for .org information and it HAS to be signed, if it isn't signed or doesn't match, it's invalid.
and so on.
So where can the records be stripped ?
Hi Leen,
Hi Wouter,
Usually I just lurk on this mailinglist, but this time I have a question about DNSSEC.
I'm not familair with all details of DNSSEC, but I thought it doesn't really matter all that much where
you get the DNSSEC information from, as long as you have a copy of the public root key or maybe
something from a DLV-system. You would be able to verify it all the way from the top down to the record
that you want to verify.
Yes, but you have to get the data from the server.
DNSSEC does not conjure information out of thin air.
A forwarded would then just be a cache, you could ask that forwarded to retrieve the right RR and you'd
be able to verify it.
Yes, if that forwarder gives along the signature with the data.
If the forwarder takes away all the signatures, then with
DNSSEC you detect that and the response is a security failure.
This is what I always assumed, let's say the root is signed ( I assume with DLV it's kind of similair ):
1. you know the root is signed, you have the public key (or whatever key material you need), you get
the right records and you verify these records. They can't be changed, otherwise the signatures wouldn't
match.
Yes. And there is an expiration to tell you this was not
a delayed repeat of old information.
2. It has a record that says .org is signed and it has to match with this key.
Yes
3. you ask for .org information and it HAS to be signed, if it isn't signed or doesn't match, it's invalid.
and so on.
Yes
So where can the records be stripped ?
It looked like Harish was running a setup where the forwarder was
stripping the records. Because it did not have dnssec enabled, it
did not pass along the information that was necessary.
Noticing that information was stripped off, unbound then decided this
was a security failure.
Does this information help?
Best regards,
Wouter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi Leen,
> Hi Wouter,
>
> Usually I just lurk on this mailinglist, but this time I have a question about DNSSEC.
>
> I'm not familair with all details of DNSSEC, but I thought it doesn't really matter all that much where
> you get the DNSSEC information from, as long as you have a copy of the public root key or maybe
> something from a DLV-system. You would be able to verify it all the way from the top down to the record
> that you want to verify.Yes, but you have to get the data from the server.
DNSSEC does not conjure information out of thin air.> A forwarded would then just be a cache, you could ask that forwarded to retrieve the right RR and you'd
> be able to verify it.Yes, if that forwarder gives along the signature with the data.
If the forwarder takes away all the signatures, then with
DNSSEC you detect that and the response is a security failure.> This is what I always assumed, let's say the root is signed ( I assume with DLV it's kind of similair ):
>
> 1. you know the root is signed, you have the public key (or whatever key material you need), you get
> the right records and you verify these records. They can't be changed, otherwise the signatures wouldn't
> match.Yes. And there is an expiration to tell you this was not
a delayed repeat of old information.> 2. It has a record that says .org is signed and it has to match with this key.
Yes
> 3. you ask for .org information and it HAS to be signed, if it isn't signed or doesn't match, it's invalid.
>
> and so on.Yes
> So where can the records be stripped ?
It looked like Harish was running a setup where the forwarder was
stripping the records. Because it did not have dnssec enabled, it
did not pass along the information that was necessary.Noticing that information was stripped off, unbound then decided this
was a security failure.Does this information help?
Yes, it does take away my uncertainty about if I understand correctly how DNSSEC works.
It's not possible for Unbound to ask the forwarded for the specific record (I think it's something like KEY) ?
Or would a forwarder strip that also ?
Or would all these extra requests delay the whole thing far to much and is that a good reason not do it ?
The problem is that the signature should be kept with the data. If you
ask for the signature and data separately you do not know if they match.
In fact they may very well be from different versions of the zone,
therefore in DNSSEC the signatures are sent together with the data.
It would also be slower, yeah.
Best regards,
Wouter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1> Does this information help?
>
>> Yes, it does take away my uncertainty about if I understand correctly how DNSSEC works.
>> It's not possible for Unbound to ask the forwarded for the specific record (I think it's something like KEY) ?
>> Or would a forwarder strip that also ?
>> Or would all these extra requests delay the whole thing far to much and is that a good reason not do it ?The problem is that the signature should be kept with the data. If you
ask for the signature and data separately you do not know if they match.
In fact they may very well be from different versions of the zone,
therefore in DNSSEC the signatures are sent together with the data.
Ohh, ofcourse, now I understand they could otherwis be from different
nameservers with different versions of the zone or from the same
nameserver but the zone was recently changed.
Thank you for your time, that makes things a lot clearer.