[reSIProcate] Re: Dns Caching/Blacklisting

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On Mar 4, 2005, at 16.57, derek wrote:

> 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?
> 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. :-)

> 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?)

>

Thanks, sounds interesting so far....

a l a n a t j a s o m i d o t c o m