Time is a pain in the neck. Conversations over the meaning of timers
and time fields have gone on for a long time.
Keep in mind the difference between absolute (or wall clock) time and
relative time. The latter is even stickier because the time may be
relative to an event that is local and not even zone-wide.
What timers are used to do is to govern different, often orthogonal
operations and events in the DNS system. The TTL is there to govern
freshness of cached records in a server. The SOA timers are there to
govern the freshness of a copy of a zone in a slave server.
Authority (only) servers have no notion of time and we've made
strides to keep it that way. (At least in the protocol.)
DNSSEC came along with absolute time. That is a novelty of the
extensions. The time was used to do two things - protect the
cryptographic relevance of the signature and to limit the impact of
replay attempts.
Along the way many have confused the meaning of the timers. TTL
trimming to the signature expiration is one abuse, arguably one that
makes sense. In the purity of the protocol it doesn't but given
operational realities that there may be a forced downstream validator
that needs this trimming to be done.
At 11:43 -0400 6/2/11, Olafur Gudmundsson wrote:
Strictly speaking from a protocol point of view any signature that expires
before (zone expiry + RR TTL) is a potential validation failure.
The signature expiration is in absolute time. Zone expiry (and
refresh/retry) is a relative time. TTL is also a relative time.
Whether the signature expiration time will arrive before the
expiration of the zone or the cache entry is a question relative to
the time you ask.
The base time for, say zone expiry, is relative to the slave server
and is not revealed via the protocol. And it is server specific, not
zone specific!
So - there's no way to determine if "any signature ... expires
before" zone expiry or RR TTL.
Any Signature that expires before corresponding TTL is a likely validation
failure if there is a non DNSSEC validating cache in the path.
What do you mean by "in the path"?
There's no protocol error in shipping an expired signature. It's up
to the receiver to decide if that matters. We stopped requiring zone
loading to check signatures like 10 years ago.
Any Signature that has expired is bad.
http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02
says differently.
The issue is that many zone owners do not
a) Do not know how long it takes to distribute their modified zone to all
the servers in the NS set. (frequent assumption is 0 seconds)
b) Forget about the possible impact of zone expiry when secondary server
can not reach distribution server.
c) Forget about maximum TTL in zone
I'm not sure where you are going here - but C isn't a problem in
caches that do TTL trimming. A & B aren't limited to being DNSSEC
issues.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
