[reSIProcate] RE: Dns Caching/Blacklisting
Where this component fits in is between DnsInterface and DnsResult; it will
greatly simplify DnsResult. See inline for other comments.
> > Implementation has started on Dns caching, here?s the latest design +
> > open issues.
> >
> > Cache Approach:
> >
> > There is a set of cached RR lists for each supported RR type; adding
> > new supported RR types will be easy. Each RRList has a
> > absoluteExpiryTime based on the min TTL encountered in the RRs.
> > Absolute cache size will be maintained using an LRU list.
> >
> > The DnsStub object will follow CNAME to a maximum depth of 5(or
> > configurable). The user of the DnsStub api never has to deal w/ CNAME
> > directly.
> >
> > BlackListing:
> >
> > There is a list of elements for each target (RR + FQDN), which is the
> > RRList class. Blacklisting an element will be accomplished by pushing
> > it to the back of the list and marking it with a generation/marker to
> > avoid constantly looping through the list. When all elements have
> > failed, the TTL for that RRList will be adjusted to expire in magic
> > amount of time which may involve querying the user. This magic time
> > will not apply if the real expiry time was sooner. This assumes that
> > you never want to re-use an element that has been marked as bad until
> > you have exhausted all the alternatives. While the re-query may not
> > strictly be necessary, it only happens when all alternatives fail and
> > it has the nice property of picking up desirable dns changes before
> > the ttl expires.
> >
> >
>
> Can we back up one step and talk only about the operation / design and
> not implementation. I fearing that we are missing the appropriate place
> to insert this. Are we saying that this system will only affect and/or
> impact the DNS RR's that we feed the existing, unmodified
> TransactionState FSM?
> >
[Derek] The blacklisting approach can easily be tweaked later, and we do
need to think about blacklisting some more. This will have no impact to the
TransactionState FSM as DnsResult will be re-written to use this layer.
This is a stab at desirable blacklisting behaviour.
> > Implementation Tradeoffs:
> > 1. The current implementation approach has a set rather than a map to
> > avoid keeping a back pointer/duplicate key but will require caching
> > CNAME, although only the last step of the CNAME ?path? will need to be
> > cached. I suspect this will be cheaper overall.
> >
> > 2. David proposed just using an LRU list and not greedily invalidating
> > elements with an expired TTL. If the cache has hit it?s maximum size
> > the LRU object will always be removed. Also, whenever the cache gets
> > cycles it will do N amount of cleanup work. The proposed algorithm
> > for each pass is:
> > 1. look at the oldest element in the cache
> > 2. If it TTL expired remove it, over wise mark it a youngest.
> >
>
> Perhaps, but let's not even consider that until we get it working 1st.
> Then let's make it work fast. :-)
[Derek] We need LRU and this saves coding.
>
> >
> >
> > Dns Questions:
> >
> > A couple of questions that affect the implementation: from page 4 of
> > 2782, it states that name compression is not permitted for the Target
> > field, unless permitted by future standards. Should we support name
> > compression for that field?
> >
> > 3.2.1 ff rfc1035 says the following about the NAME portion of an RR:
> > NAME an owner name, i.e., the name of the node to which this resource
> > record pertains.
> >
> > Is the NAME of each RR the same across all RRs in a result, and always
> > the same as a containing node?
> >
>
> Again -- this is sounding like it might be implementation uncertainty
> because the design isn't interfacing well with the concepts? I might be
> wrong, but can we have a more requirements leading to design-focused
> discussion? (Or did I miss it?)
[Derek] We never hit this level of detail earlier because we weren't
implementing; but be reassured that the answer to these particular questions
affects optimization not semantics.
>
> >
>
> Thanks, sounds interesting so far....
>
> a l a n a t j a s o m i d o t c o m