I have a case here where RRSIGs expired, yet Unbound still sets the "AD"
flag in responses. The records have a TTL of 2 days, so I think the
signatures expired while in the cache and Unbound did not revalidate
them before handing out the answer.
I'm not too deep into the details of all DNSSEC RFCs. Is this behaviour
permitted by the standard or is it a bug in Unbound?
The Signature Expiration and Inception fields specify a validity
period for the signature. The RRSIG record MUST NOT be used for
authentication prior to the inception date and MUST NOT be used for
authentication after the expiration date.
I read that as: if the record is authenticated, put it in the cache and
use it until the TTL has expired.
What is your value of val-sig-skew-min and val-sig-skew-max? By
default, Unbound allows expired signatures for 10 % of their validity
period.
They're still at their default values:
# The signature inception and expiration dates are allowed to be off
# by 10% of the signature lifetime (expir-incep) from our local clock.
# This leeway is capped with a minimum and a maximum. In seconds.
# val-sig-skew-min: 3600
# val-sig-skew-max: 86400
val-sig-skew-max should have limited the allowed skew anyway, as the
signatures already expired two days ago.
After flushing the cache, Unbound returns SERVFAIL, as expected:
unbound: info: Could not establish a chain of trust to keys for <mixmin.net. DNSKEY IN>
unbound: info: validation failure <fleegle.mixmin.net. A IN>: signature expired from 86.59.118.153 for key mixmin.net. while building chain of trust
# unbound-host -C /etc/unbound/unbound.conf -v mixmaster.mixmin.net.
mixmaster.mixmin.net. mail is handled by 10 snorky.mixmin.net. (insecure)
# unbound-host -C /etc/unbound/unbound.conf -v nic.cz
nic.cz mail is handled by 10 mail.nic.cz. (secure)
nic.cz mail is handled by 15 mail4.nic.cz. (secure)
nic.cz mail is handled by 20 mx.cznic.org. (secure)
nic.cz mail is handled by 30 bh.nic.cz. (secure)
You're right. mixmin.net isn't chained from .net anymore (it used to
be). It's still listed in dlv.isc.org, that's where my resolver got the
trust chain from. I notified the domain owner. He'll fix it soon.
I was just curious why mail to that domain still got delivered, even
though the BIND resolver logged lots of validation failures.
I increased the maximum cache TTL from the default 1 day to 1 week.
Could that be a factor here?
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl: 604800
In a discussion on IRC, a question came up whether "an attacker can
tamper with TTLs on the wire and cause data to never ever expire, even
long after their signature has expired" and have an application like
OpenSSH still believe in the AD flag.
I haven't quite wrapped my head around how that could work, yet. It
seems like a lot of effort for little gain. I'm thinking of dynamic
address records or SSHFP here. Is the original TTL in the RRSIG data
taken into account anywhere?
I guess, I'll have to read up on some more DNSSSEC details now.
Actually unbound caps the TTL so it does not extend beyond the
expiration time. Or, it should, and there is a bug.
I increased the maximum cache TTL from the default 1 day to 1 week.
Could that be a factor here?
yes. But unbound should still stop the TTL at the expiration time. But
maybe the TTL was very large and the 10% skew, with the higher max-ttl,
gave a larger extra-lenience.
# the time to live (TTL) value cap for RRsets and messages in the
# cache. Items are not cached for longer. In seconds.
cache-max-ttl: 604800
In a discussion on IRC, a question came up whether "an attacker can
tamper with TTLs on the wire and cause data to never ever expire, even
long after their signature has expired" and have an application like
OpenSSH still believe in the AD flag.
not for unbound, because of the max-ttl.
I haven't quite wrapped my head around how that could work, yet. It
seems like a lot of effort for little gain. I'm thinking of dynamic
address records or SSHFP here. Is the original TTL in the RRSIG data
taken into account anywhere?
Yes the TTL can not be larger than that original TTL. Unbound adjusts
it lower if so.
I guess, I'll have to read up on some more DNSSSEC details now.
The section to read is 5.3.3 last paragraph:
If the resolver accepts the RRset as authentic, the validator MUST
set the TTL of the RRSIG RR and each RR in the authenticated RRset to
a value no greater than the minimum of:
o the RRset's TTL as received in the response;
o the RRSIG RR's TTL as received in the response;
o the value in the RRSIG RR's Original TTL field; and
o the difference of the RRSIG RR's Signature Expiration time and the
current time.